OPA: un motore di policy per scopi generici per cloud-native

Man mano che la tua organizzazione adotta il cloud, potresti scoprire che il dinamismo e la scala dello stack nativo del cloud richiedono un panorama di sicurezza e conformità molto più complicato. Ad esempio, con le piattaforme di orchestrazione dei container come Kubernetes che stanno guadagnando terreno, sviluppatori e team di devops hanno nuove responsabilità su aree politiche come il controllo delle ammissioni e aree più tradizionali come elaborazione, archiviazione e rete. Nel frattempo, ogni applicazione, microservizio o mesh di servizi richiede il proprio set di criteri di autorizzazione, per i quali gli sviluppatori sono in agguato.

È per questi motivi che si è alla ricerca di un modo più semplice ed efficiente in termini di tempo per creare, applicare e gestire le policy nel cloud. Immettere Open Policy Agent (OPA). Creato quattro anni fa come motore di policy open source e indipendente dal dominio, OPA sta diventando lo standard de facto per policy cloud-native. In effetti, l'OPA è già impiegato nella produzione da aziende come Netflix, Pinterest e Goldman Sachs, per casi d'uso come il controllo di ammissione di Kubernetes e l'autorizzazione API dei microservizi. OPA supporta anche molti degli strumenti nativi del cloud che già conosci e ami, tra cui la suite Atlassian e Chef Automate.

[Anche su: Dove l'ingegneria dell'affidabilità del sito incontra devops]

OPA fornisce alle organizzazioni cloud-native un linguaggio di policy unificato, in modo che le decisioni di autorizzazione possano essere espresse in modo comune, tra app, API, infrastruttura e altro, senza dover codificare individualmente policy personalizzate in ciascuno di questi vari linguaggi e strumenti . Inoltre, poiché OPA è concepito appositamente per l'autorizzazione, offre una raccolta crescente di ottimizzazioni delle prestazioni in modo che gli autori di policy possano dedicare la maggior parte del loro tempo a scrivere policy corrette e gestibili e lasciare le prestazioni a OPA.

La politica di autorizzazione OPA ha molti, molti casi d'uso in tutto lo stack, dall'inserimento di guardrail attorno all'orchestrazione dei container, al controllo dell'accesso SSH o alla fornitura di autorizzazioni mesh di servizi basate sul contesto. Tuttavia, ci sono tre casi d'uso popolari che forniscono un buon trampolino di lancio per molti utenti OPA: autorizzazione dell'applicazione, controllo di ammissione Kubernetes e microservizi. 

OPA per l'autorizzazione dell'applicazione

La politica di autorizzazione è onnipresente, perché praticamente ogni applicazione lo richiede. Tuttavia, gli sviluppatori in genere "eseguono il rollio del proprio" codice, il che non solo richiede tempo, ma si traduce in un insieme di strumenti e politiche difficili da mantenere. Sebbene l'autorizzazione sia fondamentale per ogni app, il tempo dedicato alla creazione di criteri significa meno tempo per concentrarsi sulle funzionalità rivolte all'utente.

OPA utilizza un linguaggio di policy dichiarativo appositamente creato che semplifica lo sviluppo di policy di autorizzazione. Ad esempio, puoi creare e applicare criteri in modo semplice come "Non puoi leggere PII se sei un appaltatore" o "Jane può accedere a questo account". Ma questo è solo l'inizio. Poiché l'OPA è sensibile al contesto, puoi anche creare policy che considerino qualsiasi cosa sul pianeta, ad esempio "Le negoziazioni di azioni richieste nell'ultima ora del giorno di negoziazione, che si tradurranno in una transazione di oltre un milione di dollari, possono essere eseguite solo su servizi specifici in un determinato spazio dei nomi. "

Naturalmente, molte organizzazioni dispongono già di un'autorizzazione su misura. Tuttavia, se si spera di scomporre le applicazioni e scalare i microservizi nel cloud mantenendo l'efficienza per gli sviluppatori, sarà necessario un sistema di autorizzazione distribuito. Per molti, OPA è il pezzo mancante del puzzle.

OPA per il controllo delle ammissioni di Kubernetes

Molti utenti utilizzano OPA anche per creare guardrail per Kubernetes. Kubernetes stesso è diventato mainstream e mission-critical e le organizzazioni sono alla ricerca di modi per definire e implementare guardrail di sicurezza per aiutare a mitigare il rischio di sicurezza e conformità. Utilizzando OPA, gli amministratori possono impostare criteri chiari in modo che gli sviluppatori possano accelerare la produzione di pipeline e portare rapidamente nuovi servizi sul mercato, senza preoccuparsi dei rischi operativi, di sicurezza o di conformità.

OPA può essere utilizzato per creare criteri che rifiutino qualsiasi ingresso che utilizzi lo stesso nome host o che richieda che tutte le immagini del contenitore provengano da un registro attendibile o per garantire che tutto lo spazio di archiviazione sia contrassegnato sempre con il bit di crittografia o che ogni app esposta a Internet utilizzare un nome di dominio approvato - per citare solo alcuni esempi.

Poiché OPA si integra direttamente con il server API Kubernetes, può rifiutare qualsiasi risorsa non consentita dai criteri, su elaborazione, rete, archiviazione e così via. Particolarmente vantaggioso per gli sviluppatori, è possibile esporre questi criteri nelle prime fasi del ciclo di sviluppo, ad esempio nella pipeline CI / CD, in modo che gli sviluppatori possano ricevere feedback in anticipo e risolvere i problemi prima del runtime. Inoltre, puoi persino convalidare le tue politiche fuori banda, assicurandoti che raggiungano l'effetto desiderato e non causino inavvertitamente problemi.

OPA per microservizi

Infine, OPA è diventato molto popolare per aiutare le organizzazioni a controllare i propri microservizi e le architetture mesh di servizi. Con OPA, puoi creare e applicare le policy di autorizzazione direttamente per un microservizio (in genere come sidecar), creare policy da servizio a servizio all'interno della mesh di servizi o, dal punto di vista della sicurezza, creare policy che limitano lo spostamento laterale all'interno della mesh di servizi architettura.

Creazione di policy unificate per architetture native del cloud

In generale, l'obiettivo generale quando si utilizza OPA è creare un approccio unificato alla creazione di policy attraverso lo stack nativo del cloud, in modo da non dover gestire continuamente le policy in dozzine di posizioni, utilizzando linguaggi e approcci diversi, attraverso un mix ad hoc di conoscenza tribale, wiki e PDF o un miscuglio di strumenti non corrispondenti.

[Anche su: 7 best practice per team agili remoti]

Oltre a semplificare lo sviluppo e accelerare la consegna, questa è una grande notizia anche per la sicurezza, poiché OPA riduce il numero di strumenti necessari per verificare se, ad esempio, si sospetta che sia stato tentato un accesso non autorizzato. Allo stesso modo, sia dal punto di vista delle operazioni che da quello della conformità, OPA semplifica l'estrazione e l'analisi delle informazioni in un ambiente eterogeneo, aiutandoti a identificare rapidamente i problemi e risolverli più rapidamente.

Gli sviluppatori sono alla ricerca di un modo più semplice ed efficiente per creare e gestire controlli basati su policy per i loro ambienti cloud-native. Per molti, quella soluzione è OPA. Se ti ritrovi a toccare la politica di autorizzazione in più luoghi, in più lingue o tra più team, OPA può aiutarti a eliminare la ridondanza e velocizzare la consegna, proprio come ha fatto per loro.

Tim Hinrichs è un co-fondatore del progetto Open Policy Agent e CTO di Styra. Prima di allora, ha co-fondato il progetto OpenStack Congress ed è stato ingegnere del software presso VMware. Tim ha trascorso gli ultimi 18 anni a sviluppare linguaggi dichiarativi per diversi domini come il cloud computing, il networking definito dal software, la gestione della configurazione, la sicurezza web e il controllo degli accessi. Ha conseguito il dottorato di ricerca. in Computer Science presso la Stanford University nel 2008.

-

Il New Tech Forum offre un luogo per esplorare e discutere la tecnologia aziendale emergente in profondità e ampiezza senza precedenti. La selezione è soggettiva, in base alla nostra scelta delle tecnologie che riteniamo importanti e di maggiore interesse per i lettori. non accetta materiale di marketing per la pubblicazione e si riserva il diritto di modificare tutti i contenuti forniti. Invia tutte le richieste a [email protected]