Open Policy Agent per gli MSP: ammissione, autorizzazione API e gate CI

Open Policy Agent (OPA) è noto soprattutto come motore alla base del controllo di ammissione Kubernetes, ma il progetto principale non ha nulla di specifico per Kubernetes. Questa guida è per gli MSP e i team platform che vogliono usare OPA come motore di policy generico — per l'autorizzazione API, i controlli CI e l'ammissione Kubernetes — senza confondere quale strumento fa cosa, più quello che è cambiato in una recente correzione del parser per chi usa già la nuova sintassi Rego di OPA.

Dove OPA serve oltre Kubernetes

Il progetto principale — open-policy-agent/opa su GitHub, con circa 12,3 mila stelle e 1,7 mila fork — è un motore di policy che valuta una richiesta rispetto a una policy scritta invece che a una logica applicativa hard-coded. Gli MSP e i team di prodotto lo usano ovunque serva questo tipo di decisione, non solo ai confini di un cluster Kubernetes.

Lo stesso linguaggio di policy Rego che esegue funziona altrettanto bene su un gateway API o dentro un sidecar di servizio, valutando se una richiesta è autorizzata prima che arrivi al codice dell'applicazione. Puoi riutilizzare gli stessi pacchetti di policy nelle pipeline CI per intercettare violazioni, come una dipendenza vietata, una risorsa mal configurata o una regione non approvata, prima che una modifica venga distribuita e non dopo.

OPA, Gatekeeper e Conftest sono tre cose diverse

Il controllo di ammissione Kubernetes tramite Gatekeeper è un'integrazione costruita sopra OPA, non OPA stesso, e Conftest è uno strumento a riga di comando separato per testare file di configurazione strutturati rispetto a policy Rego. Riunire tutti e tre in un'unica narrazione OPA nei materiali rivolti ai clienti sovrastima ciò che ogni singolo strumento fa da solo: ognuno ha il proprio modello di distribuzione e le proprie modalità di errore.

Gatekeeper: applica le policy all'ingresso di Kubernetes

OPA Gatekeeper, mantenuto sotto l'organizzazione Open Policy Agent su GitHub con circa 4,3 mila stelle, è un admission controller di Kubernetes. Intercetta le richieste API tramite un validating admission webhook e le verifica rispetto a policy Rego nel momento in cui un carico di lavoro viene inviato, anziché dopo che è già in esecuzione. Se gestisci più cluster di clienti come MSP, puoi scrivere una regola una sola volta e applicarla in modo coerente: richiedere immagini container da un registry approvato o con un'attestazione di firma verificata, negare i container che chiedono la modalità privilegiata o mount hostPath senza restrizioni, oppure limitare i tipi di carico di lavoro che un namespace può accettare.

Gatekeeper è un'integrazione specifica per Kubernetes, non un sostituto del motore principale, che gli MSP usano anche per l'autorizzazione API e i controlli CI fuori da Kubernetes; i due sono complementari, con Gatekeeper che gestisce il percorso di ammissione mentre il motore principale prende le decisioni di policy altrove nello stack. Non sostituisce nemmeno RBAC, network policy o l'igiene dei segreti: aggiunge un livello sopra di essi, non al loro posto.

Settembre 2026: un bug del parser corretto in OPA 1.20.2

OPA 1.20.2, rilasciata all'inizio di settembre 2026, corregge un bug del parser introdotto due release prima nella 1.20.0, che aveva aggiunto le nuove parole chiave Rego and e or per combinare condizioni in un singolo corpo di regola. Quando una policy importava quelle parole chiave, direttamente oppure tramite import future.keywords, il parser di OPA leggeva prima un'istruzione che inizia con una parentesi graffa come corpo di un operando, poi la rileggeva come termine, per esempio una comprensione, se non seguiva né and né or.

Una regressione faceva sì che gli errori registrati durante quella prima lettura abbandonata restassero in cache e venissero segnalati per errore sulla seconda lettura, quella riuscita, portando il parser a rifiutare policy in realtà valide. Le policy che non importano and/or non sono mai state interessate, e si tratta di una correzione mirata, non di un avviso di sicurezza; il progetto complementare opa-envoy-plugin ha pubblicato una release v1.20.2-envoy corrispondente, quindi se usi quel plugin verifica di aver ricevuto lo stesso aggiornamento di versione.

Se come MSP vuoi una verifica esterna di questi controlli nell'ambito di un programma di conformità NIS2, DORA o GDPR, puoi contare su supporto dedicato: i servizi di cybersecurity di Altovar coprono penetration test, vulnerability assessment, incident response e lavoro di conformità per gli stessi framework.

Punti di partenza pratici

• Autorizzazione API: valuta le policy Rego al livello del gateway o del sidecar per le richieste che richiedono regole per tenant o per ruolo oltre all'autenticazione integrata di un framework.
• Gate di policy in CI: esegui le stesse regole Rego su infrastructure-as-code o manifest in una fase della pipeline, fallendo la build in caso di violazioni invece di affidarti a revisioni manuali.
• Ammissione Kubernetes: avvia le policy di Gatekeeper in modalità dry-run o warn, documenta le eccezioni per i carichi di lavoro esistenti e limita i vincoli a namespace specifici prima di estenderli.
• Librerie di policy condivise: scrivi le regole una sola volta e applicale tra controllo di ammissione, autorizzazione API e CI invece di reimplementare la stessa logica tre volte.

Cosa fare

1. Mappa dove si trovano oggi le decisioni di policy nel tuo stack — ammissione, gateway, CI — e segnala quelle ancora hard-coded invece che basate su policy.
2. Se usi Gatekeeper, introduci i nuovi constraint in modalità dry-run o warn e documenta le eccezioni prima di passare a enforce.
3. Tieni distinti i tre strumenti nella tua documentazione: il motore OPA, Gatekeeper per l'ammissione e Conftest per CI e test di configurazione.
4. Se le tue policy Rego importano le parole chiave and/or, verifica di essere sulla versione 1.20.2 o successiva prima di considerare un rifiuto come un errore di scrittura.
5. Controlla se strumenti collegati, come il plugin Envoy o i sidecar, hanno ricevuto lo stesso aggiornamento di versione OPA.
6. Affianca le policy di ammissione e autorizzazione a RBAC, network policy e igiene dei segreti, invece di considerarle un sostituto completo.

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