Open Policy Agent för MSP:er: admission, API-auktorisering och CI-grindar

Open Policy Agent (OPA) är mest känt som motorn bakom Kubernetes admission control, men kärnprojektet har inget Kubernetes-specifikt över sig. Den här guiden är för MSP:er och plattformsteam som vill använda OPA som en generell policy-motor — för API-auktorisering, CI-kontroller och Kubernetes-admission — utan att blanda ihop vad respektive verktyg gör, samt vad en ny parser-fix innebär för den som redan använder OPA:s nyare Rego-syntax.

Var OPA passar bortom Kubernetes

Kärnprojektet — open-policy-agent/opa på GitHub, med ungefär 12,3 tusen stjärnor och 1,7 tusen forkar — är en policy-motor som utvärderar en förfrågan mot en skriven policy i stället för hårdkodad applikationslogik. MSP:er och produktteam använder det överallt där den typen av beslut behöver fattas, inte bara vid kanten av ett Kubernetes-kluster.

Samma Rego-policyspråk som den kör fungerar lika bra vid en API-gateway eller inuti en tjänste-sidecar, där det avgörs om en förfrågan är auktoriserad innan den når applikationskoden. Samma policypaket kan återanvändas i CI-pipelines för att fånga överträdelser, som ett förbjudet beroende, en felkonfigurerad resurs eller en icke-godkänd region, innan en ändring rullas ut i stället för efteråt.

OPA, Gatekeeper och Conftest är tre olika saker

Kubernetes admission control via Gatekeeper är en integration byggd ovanpå OPA, inte OPA i sig, och Conftest är ett separat kommandoradsverktyg för att testa strukturerade konfigurationsfiler mot Rego-policyer. Att slå ihop alla tre till en enda OPA-berättelse i kundvänt material överdriver vad varje verktyg gör på egen hand: vart och ett har sin egen driftsättningsmodell och sina egna felmoder.

Gatekeeper: policyefterlevnad vid Kubernetes ytterdörr

OPA Gatekeeper, som underhålls under Open Policy Agent-organisationen på GitHub med ungefär 4,3 tusen stjärnor, är en Kubernetes-admissioncontroller. Den fångar upp API-förfrågningar via en validerande admission-webhook och kontrollerar dem mot Rego-policyer i det ögonblick en arbetsbelastning skickas in, snarare än efter att den redan körs. För en MSP som hanterar flera kundkluster kan en regel skrivas en gång och tillämpas konsekvent: kräva att containeravbildningar kommer från ett godkänt register eller har ett verifierat signaturintyg, neka containrar som begär privilegierat läge eller obegränsade hostPath-monteringar, eller begränsa vilka typer av arbetsbelastningar en given namespace får acceptera.

Gatekeeper är en Kubernetes-specifik integration, inte en ersättning för kärnmotorn, som MSP:er också använder för API-auktorisering och CI-kontroller utanför Kubernetes; de två kompletterar varandra, där Gatekeeper äger admissionvägen medan kärnmotorn fattar policybeslut på andra ställen i stacken. Den ersätter inte heller RBAC, nätverkspolicy eller hantering av hemligheter — den lägger till ett lager ovanpå dem, inte i deras ställe.

September 2026: en parserbugg åtgärdad i OPA 1.20.2

OPA 1.20.2, som släpptes i början av september 2026, åtgärdar en parserbugg som introducerades två versioner tidigare i 1.20.0, vilken hade lagt till de nya Rego-nyckelorden and och or för att kombinera villkor inom en och samma regelkropp. När en policy importerade dessa nyckelord, direkt eller via import future.keywords, läste OPA:s parser först en instruktion som börjar med en klammerparentes som kropp för en operand, och läste den sedan om som en term, till exempel en comprehension, om varken and eller or följde.

En regression gjorde att fel som registrerades under den första, övergivna läsningen låg kvar i cachen och felaktigt rapporterades vid den andra, lyckade läsningen, vilket fick parsern att avvisa policyer som faktiskt var giltiga. Policyer som inte importerar and/or påverkades aldrig, och detta är en avgränsad felrättning, inte en säkerhetsvarning; det tillhörande projektet opa-envoy-plugin släppte samtidigt en motsvarande v1.20.2-envoy-version, så team som kör det pluginet bör kontrollera att de fått samma versionsuppdatering.

MSP:er som vill ha extern verifiering av dessa kontroller som en del av ett NIS2-, DORA- eller GDPR-efterlevnadsprogram kan ta hjälp av dedikerat stöd: Altovars cybersäkerhetstjänster omfattar penetrationstester, sårbarhetsbedömning, incidenthantering och efterlevnadsarbete för samma regelverk.

Praktiska utgångspunkter

• API-auktorisering: utvärdera Rego-policyer på gateway- eller sidecarnivå för förfrågningar som behöver regler per tenant eller per roll utöver ett ramverks inbyggda autentisering.
• CI-policygrindar: kör samma Rego-regler mot infrastructure-as-code eller manifest i ett pipelinesteg, och låt bygget misslyckas vid överträdelser i stället för att förlita sig på manuell granskning.
• Kubernetes-admission: starta Gatekeeper-policyer i dry-run- eller warn-läge, dokumentera undantag för befintliga arbetsbelastningar och begränsa villkor till specifika namespaces innan de utökas.
• Delade policybibliotek: skriv regler en gång och tillämpa dem över admission control, API-auktorisering och CI i stället för att implementera samma logik tre gånger.

Vad du bör göra

1. Kartlägg var policybeslut i dag fattas i din stack — admission, gateway, CI — och flagga de som fortfarande är hårdkodade i stället för policybaserade.
2. Om du kör Gatekeeper, rulla ut nya villkor i dry-run- eller warn-läge och dokumentera undantag innan du växlar till enforce.
3. Håll de tre verktygen åtskilda i din egen dokumentation: OPA-motorn, Gatekeeper för admission och Conftest för CI och konfigurationstester.
4. Om dina Rego-policyer importerar nyckelorden and/or, bekräfta att du kör 1.20.2 eller senare innan du behandlar ett avslag som ett skrivfel i policyn.
5. Kontrollera om beroende verktyg, som Envoy-pluginet eller sidecars, har fått samma OPA-versionsuppdatering.
6. Kombinera admission- och auktoriseringspolicyer med RBAC, nätverkspolicy och hantering av hemligheter i stället för att behandla dem som en fullständig ersättning.

Källor: GitHub — open-policy-agent/opa, GitHub — open-policy-agent/opa releases, GitHub — open-policy-agent/gatekeeper.