Sono ben conscio che esistano pareri discordanti su quando la metodologia (o vogliamo chiamarlo “movimento”) DevOps sia partita. Quando mi capita di parlarne, ad una classe o ad un talk la mia risposta è una ed una soltanto: anno 2013, quando Solomon Hykes ha presentato al mondo Docker.

Quel momento ha reso una tecnologia presente ma di difficile utilizzo (i processi isolati, o per meglio dire i container, in Linux ci sono da ben prima di Docker) accessibile a tutti. Ha creato il ponte tra gli sviluppatori e gli operatori, ha cancellato la frase “eh ma sul mio laptop tutto funziona” che è stata origine di enormi conflitti tra i due mondi, rendendo operativamente vivo il concetto di DevOps.

Se esiste una specifica OCI (Open Container Initiative), lo si deve a Docker. Se esiste una modalità standard e condivisa di creare e condividere immagini, lo si deve a Docker. Se tutto questo è fruibile per tutti, visto che è stato donato alla community, lo si deve a Docker.

Poi si sa, tutto è opinabile, ma ci sono dati oggettivi da cui certe volte è meglio non allontanarsi troppo.

A cosa serviva questa lunga introduzione, vi starete chiedendo? Serviva a presentare la notizia di oggi che parla di un ennesimo passo che il progetto Docker ha fatto per rendere il mondo un posto migliore: la donazione della Sandbox Kit Spec alla CNCF, la Cloud Native Computing Foundation.

Per capire la portata di questa mossa, è bene chiarire in cosa consista la Sandbox Kit Spec.

Il problema che Docker vuole risolvere è abbastanza sottile. Con un container tradizionale, l’immagine descrive principalmente che cosa deve essere eseguito (ossia il processo isolato). Ma i permessi con cui quel software viene eseguito sono spesso definiti altrove: parametri di docker run, Compose, configurazioni CI/CD, secret, mount e via dicendo.

Se per un’applicazione tradizionale questo modello funziona abbastanza bene, per gli agenti AI le cose funzionano in maniera diversa e, purtroppo o per fortuna, è nell’era degli agenti AI che stiamo vivendo. Un agente AI non esegue semplicemente un programma predeterminato. Durante il lavoro può decidere di installare nuovi pacchetti, oppure eseguire codice, chiamare API, utilizzare credenziali, accedere a filesystem e servizi e addirittura modificare l’ambiente nel quale sta lavorando.

Tutte cose che abbiamo esplorato nella serie Capire l’AI (Parte 1, Parte 2 e Parte 3), da cui è emerso con chiarezza quanto diventa importante sapere non soltanto “che cosa esegue questo agente?“, ma anche “che cosa gli abbiamo permesso di fare?“.

Il Kit porta queste informazioni insieme all’agente, dentro la stessa immagine OCI.

Questo produce una conseguenza interessante: se scarico un Kit, posso vedere non solo il software che sto per eseguire, ma anche l’insieme delle capability che richiede. Se una nuova versione dell’agente chiede, per esempio, accesso a un ulteriore host o a una nuova credenziale, quella modifica può essere individuata e sottoposta a review. Inoltre, fissando l’image digest, si fissano insieme contenuto dell’agente e relative richieste di accesso.

Quindi per spiegare in una frase quello che fa un Kit è: i container rendono portabile il software, i Kit rendono portabile anche l’autorità concessa all’agente.

Si capisce quindi come non basti più garantire l’isolamento proprio dei container, ma anche il contenimento dell’agente che vi agisce all’interno. Se si legge questo articolo di The Register la questione è molto chiara: per controllare ciò che fa un’agente serve una combinazione di due livelli. Il primo è quello della Sandbox, che determina dove può andare l’agente, il secondo è quello dei permessi, ossia cosa gli permetto di fare.

In conclusione, Docker sta cercando di fare per le autorizzazioni degli agenti AI quello che OCI ha fatto per i container: creare un formato aperto e interoperabile in cui non sia portabile soltanto il software che esegui, ma anche il perimetro di ciò che quell’agente è autorizzato a fare.

Il tutto con l’impegno di donare la specifica alla CNCF per una governance neutrale.

Chapeau.