Cos'è Cirrus CLI? La seguente descrizione è tratta dalla descrizione della pagina GitHub della CLI Cirrus:
Cirrus CLI è uno strumento per eseguire attività containerizzate in modo riproducibile in qualsiasi ambiente. Più comunemente, le attività Cirrus vengono utilizzate come parte di flussi di lavoro di integrazione continua, ma possono anche essere utilizzate come parte del processo di sviluppo locale come sostituzione ermetica di script helper/Makefile. Cirrus CLI esegue le tue attività localmente nello stesso modo in cui vengono eseguite in CI o sul computer del tuo collega. L'immutabilità dei contenitori garantisce che le attività verranno eseguite allo stesso modo tra anni, indipendentemente dalle versioni dei pacchetti disponibili in locale.
Cirrus CLI ha supportato Docker sin dall'inizio, ma la richiesta di un demone contenitore che venga eseguito come root e fornisca l'accesso agli utenti meno privilegiati a volte non è un'opzione:ad esempio, quando si compila su una macchina condivisa, si isolano i contenitori nidificati o semplicemente si tratta di sicurezza -consapevole di ciò che viene eseguito sul tuo desktop.
E anche se Docker ha introdotto la modalità rootless circa un anno fa, la sua esperienza utente è attualmente carente a nostro avviso, principalmente a causa della mancanza di pacchetti e di una storia in cui Docker è un demone. Podman, d'altra parte, è nato come motore di container senza daemon e il suo processo di installazione copre praticamente tutte le distribuzioni.
Inoltre, esaminando Podman come opzione aggiuntiva per l'esecuzione di attività Cirrus, ci siamo resi conto che è un piccolo passo verso l'interruzione della monocultura del software perché, alla fine, la sua qualità del software aumenta. Emergono nuovi standard e elementi costitutivi come il progetto Rootless Containers che aprono la strada al futuro del software.
I container senza root sono alimentati da... spazi dei nomi?
Gli spazi dei nomi di Linux sono la pietra angolare più importante di ciò che fa funzionare i container su Linux. Sono altamente specifici per Linux, al punto che viene creata una VM Linux separata quando esegui i container su Windows e macOS.
Gli spazi dei nomi consentono una separazione granulare delle risorse. Ad esempio, se un processo è collegato a uno specifico spazio dei nomi PID, vede solo altri processi collegati allo stesso spazio dei nomi. Oppure se un filesystem FUSE è montato su root (/ ) pur trovandosi in uno spazio dei nomi di montaggio separato, l'host non si arresterà improvvisamente in modo anomalo a causa della mancanza di binari.
Uno degli spazi dei nomi più complicati sono gli spazi dei nomi utente. Gli spazi dei nomi utente consentono essenzialmente di essere una radice all'interno di quello spazio dei nomi, ma appaiono come un normale utente dall'esterno. Poiché la maggior parte delle immagini di container prevede di essere eseguita come root per determinate operazioni, l'implementazione degli spazi dei nomi utente è fondamentale per i container senza root.
Vediamo cosa succede quando più utenti avviano i propri comandi di build utilizzando Docker senza spazi dei nomi utente abilitati:
Quando si osservano gli ID di questi processi dall'host del contenitore, tutti i lavori vengono eseguiti sotto root, nonostante siano stati avviati da utenti diversi. Lo stesso vale per containerd . E mentre in realtà avresti potuto passarlo --userns-remap flag, il contenitore verrà comunque eseguito come root e sarà un singolo punto di errore.
Le cose funzionano così nella modalità predefinita perché l'implementazione di contenitori senza root non è banale.
Gli spazi dei nomi utente stessi sono probabilmente una delle configurazioni più complesse per implementare e produrre molti bug relativi alla sicurezza. Alcune distribuzioni come Debian hanno persino deciso di disabilitarle per impostazione predefinita qualche tempo fa.
[ Nel caso te lo fossi perso: principi di sicurezza di base per container e runtime di container ]
Come Podman risolve le difficoltà di esecuzione senza radici
L'avvio di un container senza privilegi di root comporta alcuni compromessi e soluzioni alternative.
Ad esempio, come utente, quando crei uno spazio dei nomi di rete (che dovrebbe avere uno spazio dei nomi utente), ottieni solo un lo interfaccia. Normalmente, un motore di container crea anche un veth coppia di dispositivi e sposta una delle sue estremità all'host per connetterlo a un'interfaccia di rete reale o a un bridge (per la comunicazione tra container).
Tuttavia, la connessione delle interfacce sull'host richiede che tu sia un root nello spazio dei nomi dell'host, quindi non è possibile. Podman risolve questo problema utilizzando slirp4netns, uno stack di rete che instrada i pacchetti tra il container e il monitor stesso, invece di utilizzare le funzionalità del kernel. Pertanto, non richiede privilegi di superutente.
A causa delle complessità legate agli spazi dei nomi utente, non è inoltre possibile utilizzare determinati filesystem normalmente disponibili per la radice dell'host. Uno di questi filesystem è OverlayFS, che aiuta notevolmente con la deduplicazione dei livelli di immagine del contenitore e migliora l'esperienza del contenitore. Tuttavia, è ancora possibile utilizzare FUSE. Il team Podman ha implementato fuse-overlayfs , che viene utilizzato se installato, ricorrendo alla semplice estrazione del contenuto dell'immagine in una directory a scapito delle prestazioni.
Ora, se eseguiamo gli stessi lavori che eseguivamo prima, ma con Podman, il risultato sarà il seguente:
Tieni presente che ora nulla viene eseguito come root e non esiste un singolo punto di errore se un motore di container si arresta in modo anomalo per qualche motivo.
Integrazione con Podman
Quando avvii una nuova build con cirrus run , genera il processo Podman sotto il cofano e gli parla tramite l'API REST, introdotta di recente come successore della vecchia API Varlink.
L'API stessa è molto simile all'API Docker Engine, che consente un'astrazione pulita per entrambe le API nella stessa base di codice.
In effetti, lo stesso endpoint Podman offre un livello di compatibilità API Docker Engine, ma è ancora un work in progress al momento della scrittura.
Abilitazione di Podman nella CLI
Se non hai ancora installato Podman, segui le istruzioni per la tua distribuzione Linux e poi leggi il tutorial rootless.
La CLI supporta Podman versione 0.17.0 e successive. Puoi abilitarlo passando il --container-backend=podman bandiera:
cirrus run --container-backend=podman Lint Tieni presente che se non hai Docker installato sul tuo sistema, non devi nemmeno specificare nulla:tutto funziona automaticamente.
[ Iniziare con i container? Dai un'occhiata a questo corso gratuito. Distribuzione di applicazioni containerizzate:una panoramica tecnica. ]
Concludi
Le build senza root sono una componente importante delle distribuzioni di container. Cirrus CLI collabora con Podman per fornire questa funzionalità. Utilizza queste due utilità per gestire e proteggere al meglio i tuoi ambienti container.