Open Policy Agent voor MSP's: admission, API-autorisatie en CI-gates

Open Policy Agent (OPA) staat vooral bekend als de engine achter Kubernetes-admission control, maar het kernproject heeft niets Kubernetes-specifieks. Deze gids is voor MSP's en platformteams die OPA willen gebruiken als generieke policy-engine — voor API-autorisatie, CI-controles en Kubernetes-admission — zonder de tools door elkaar te halen, plus wat er is veranderd door een recente parserfix voor wie al de nieuwere Rego-syntax van OPA gebruikt.

Waar OPA van pas komt buiten Kubernetes

Het kernproject — open-policy-agent/opa op GitHub, met ongeveer 12,3 duizend sterren en 1,7 duizend forks — is een policy-engine die een verzoek toetst aan een geschreven policy in plaats van aan hardgecodeerde applicatielogica. MSP's en productteams gebruiken het overal waar dat soort beslissing nodig is, niet alleen aan de rand van een Kubernetes-cluster.

Dezelfde Rego-policytaal die het uitvoert, werkt net zo goed op een API-gateway of in een service-sidecar, waar wordt beoordeeld of een verzoek is geautoriseerd voordat het de applicatiecode bereikt. Dezelfde policypakketten kunnen worden hergebruikt in CI-pipelines om overtredingen op te sporen, zoals een verboden dependency, een verkeerd geconfigureerde resource of een niet-goedgekeurde regio, vóórdat een wijziging wordt uitgerold in plaats van erna.

OPA, Gatekeeper en Conftest zijn drie verschillende dingen

Kubernetes-admission control via Gatekeeper is een integratie bovenop OPA, niet OPA zelf, en Conftest is een apart command-line-hulpmiddel om gestructureerde configuratiebestanden te testen tegen Rego-policies. Door alle drie samen te vatten als één OPA-verhaal in klantgericht materiaal, overdrijf je wat elk hulpmiddel op zichzelf doet: elk heeft zijn eigen implementatiemodel en eigen faalmodi.

Gatekeeper: policy afdwingen aan de voordeur van Kubernetes

OPA Gatekeeper, onderhouden onder de Open Policy Agent-organisatie op GitHub met ongeveer 4,3 duizend sterren, is een Kubernetes-admissioncontroller. Het onderschept API-verzoeken via een validerende admission-webhook en toetst ze aan Rego-policies op het moment dat een workload wordt ingediend, in plaats van nadat die al draait. Voor een MSP die meerdere klantclusters beheert, kan een regel eenmaal worden geschreven en consistent worden afgedwongen: eisen dat containerimages afkomstig zijn van een goedgekeurd register of een geverifieerde handtekeningattestatie dragen, containers weigeren die geprivilegieerde modus of onbeperkte hostPath-mounts vragen, of beperken welke workloadtypen een bepaalde namespace mag accepteren.

Gatekeeper is een Kubernetes-specifieke integratie, geen vervanging voor de kern-engine, die MSP's ook gebruiken voor API-autorisatie en CI-controles buiten Kubernetes; de twee vullen elkaar aan, waarbij Gatekeeper het admissiepad beheert terwijl de kern-engine elders in de stack policybeslissingen neemt. Het vervangt ook geen RBAC, netwerkbeleid of secrets-hygiëne: het voegt er een laag bovenop toe, in plaats van ze te vervangen.

September 2026: een parserbug opgelost in OPA 1.20.2

OPA 1.20.2, uitgebracht begin september 2026, lost een parserbug op die twee releases eerder werd geïntroduceerd in 1.20.0, dat de nieuwe Rego-sleutelwoorden and en or toevoegde om voorwaarden binnen één regelbody te combineren. Als een policy die sleutelwoorden importeerde, direct of via import future.keywords, las de parser van OPA eerst een instructie die met een accolade begint als de body van een operand, en las die daarna opnieuw als term, zoals een comprehension, als geen and of or volgde.

Door een regressie bleven fouten die tijdens die eerste, verworpen lezing werden geregistreerd in de cache staan en werden ze ten onrechte gerapporteerd bij de tweede, geslaagde lezing, waardoor de parser policies afwees die in werkelijkheid geldig waren. Policies die and/or niet importeren, waren nooit getroffen, en dit is een gerichte bugfix, geen beveiligingsadvies; het bijbehorende project opa-envoy-plugin bracht tegelijkertijd een overeenkomstige v1.20.2-envoy-release uit, dus teams die die plugin gebruiken, moeten controleren of ze dezelfde versie-update hebben binnengehaald.

MSP's die deze controles extern willen laten verifiëren als onderdeel van een NIS2-, DORA- of AVG-complianceprogramma kunnen terugvallen op gerichte ondersteuning: de cybersecuritydiensten van Altovar omvatten penetratietesten, kwetsbaarheidsbeoordelingen, incident response en compliancewerk voor diezelfde kaders.

Praktische startpunten

• API-autorisatie: evalueer Rego-policies op gateway- of sidecarniveau voor verzoeken die per-tenant- of per-rolregels nodig hebben naast de ingebouwde authenticatie van een framework.
• CI-policygates: voer dezelfde Rego-regels uit tegen infrastructure-as-code of manifests in een pipelinestap, waarbij de build faalt bij overtredingen in plaats van te vertrouwen op handmatige review.
• Kubernetes-admissie: start Gatekeeper-policies in dry-run- of warn-modus, documenteer uitzonderingen voor bestaande workloads en beperk constraints eerst tot specifieke namespaces voordat je ze uitbreidt.
• Gedeelde policybibliotheken: schrijf regels één keer en pas ze toe op admission control, API-autorisatie en CI in plaats van dezelfde logica drie keer opnieuw te implementeren.

Wat te doen

1. Breng in kaart waar policybeslissingen nu in je stack liggen — admission, gateway, CI — en markeer welke daarvan nog hardgecodeerd zijn in plaats van policygebaseerd.
2. Als je Gatekeeper gebruikt, rol nieuwe constraints uit in dry-run- of warn-modus en documenteer uitzonderingen voordat je overschakelt naar enforce.
3. Houd de drie tools gescheiden in je eigen documentatie: de OPA-engine, Gatekeeper voor admission en Conftest voor CI en configuratietests.
4. Als je Rego-policies de sleutelwoorden and/or importeren, controleer dan of je op versie 1.20.2 of hoger zit voordat je een afwijzing als een schrijffout behandelt.
5. Controleer of afhankelijke tools, zoals de Envoy-plugin of sidecars, dezelfde OPA-versie-update hebben gekregen.
6. Combineer admission- en autorisatiepolicies met RBAC, netwerkbeleid en secrets-hygiëne, in plaats van ze als volledige vervanging te behandelen.

Bronnen: GitHub — open-policy-agent/opa, GitHub — open-policy-agent/opa releases, GitHub — open-policy-agent/gatekeeper.