‫Va
‫bene, quindi una nuova funzionalità in 1. 13. 1 era pieno supporto per i segreti.
‫Se dovessi creare un tag line di ciò che è, è fondamentalmente la 'soluzione sicura più semplice per memorizzare i segreti
‫in Swarm. "Dico che
‫è il più semplice perché è incorporato in Swarm, è
‫pronto all'uso e non c'è niente che devi fare per usarlo. Finché hai inizializzato lo sciame e la
‫tua versione 1. 13 o
‫più recente, hai segreti. transito e per essere disponibile solo nei luoghi che deve essere.
‫Dico che è sicuro perché è stato progettato da zero per essere crittografato su disco per essere criptato in
‫E questo è davvero ciò di cui abbiamo bisogno.
‫Quindi cos'è un segreto? Un segreto, in questo caso, è la classificazione di qualsiasi cosa che non
‫si desidera sulla prima pagina di un giornale. Se è arrivato in prima pagina e dovevi
‫cambiarlo, è un segreto.
‫che è necessario per consentire
‫la connettività tra le cose è probabilmente
‫un segreto e dovresti proteggilo.
‫È un nome utente o una password, è un certificato TLS o le chiavi, è una chiave SSH, è una chiave
‫API di Twitter, è una chiave Amazon, è tutto ciò
‫Fino ad ora non abbiamo avuto molte grandi opzioni per Swarm.
‫Esistono sicuramente molte opzioni come Vault e altri fantastici strumenti per la memorizzazione dei segreti, ma non
‫sono stati incorporati e hanno richiesto una configurazione dell'infrastruttura separata, in modo tale da
‫poter iniziare a utilizzarli.
‫Quindi, possiamo memorizzare qui tutto ciò che è una stringa o un binario fino a. 5 MB di dimensione.
‫più interessante di questo è che in realtà non richiede che la tua app venga riscritta per poterla utilizzare.
‫E la parte
‫Non devi avere la tua app per parlare con un servizio web da qualche altra parte al fine di ottenere questi.
‫Quindi vediamo come funziona.
‫A partire da 1. 13. 0 il database Swarm Raft è crittografato su disco per impostazione predefinita. Se installi Docker e fai uno
‫swarm init come abbiamo fatto prima, si tratta
‫di un database crittografato.
‫E quando spegne il servizio, viene crittografato con le chiavi archiviate in modo sicuro.
‫nodi manager e sono gli unici che hanno le chiavi per sbloccarlo o decodificarlo.
‫È solo memorizzato sul disco dei
‫Questo è già presente in Swarm, ma fondamentalmente il modo in cui i tasti
‫scendono verso i contenitori avviene attraverso il piano di controllo o le comunicazioni di
‫rete TLS crittografate tra i Manager e i Lavoratori. E quella connessione era già sicura, utilizzava già TLS e
‫autenticazione reciproca PKI, quindi era un ottimo modo per usare quel canale esistente per portare questi segreti ai nostri contenitori.
‫Il modo in cui li otteniamo è che prima li inseriamo nel database di Swarm usando i comandi
‫dei segreti Docker.
‫servizio stessi o un file di stack per dire a Swarm chi è autorizzato a usare questo segreto.
‫Poi li assegniamo ai servizi sia che usiamo i comandi di La chiave qui è che solo perché c'è un contenitore su un
‫host o su un nodo e hai assegnato la chiave a quel servizio, non significa che altri
‫contenitori possano accedervi.
‫Poiché questo è integrato nel Docker Engine, Docker Worker mantiene tale chiave protetta solo in memoria e arriva solo
‫ai contenitori su quel nodo che ne ha bisogno.
‫Ora, come vengono presentati nel file system al contenitore, sembra un file sul disco rigido delle
‫app all'interno del contenitore.
‫Ma non è in realtà quello. Non sono in realtà in esecuzione su disco. hai assegnato al segreto come file.
‫Sono in memoria solo usando un file system ramfs e li raggiungerai sotto la directory / run / secrets dove,
‫per impostazione predefinita, sarà il nome che
‫Quindi quando accedi a quel file vedrai l'unico segreto in esso contenuto.
‫Se si pensa a questo come un archivio di
‫valori chiave, la chiave è il nome del file e il valore è ciò che è contenuto.
‫Possiamo anche impostare alias in modo che possiamo avere più nomi per la stessa chiave e vedremo come questo entrerà
‫in gioco in seguito.
‫sta utilizzando un file stack con assegnazioni segrete, funzionerà effettivamente in Docker Compose sul computer locale.
‫Per lo sviluppo locale, se si
‫Ora di nuovo docker-compose, la riga di comando, non dovrebbe mai essere utilizzata in produzione su un server di produzione.
‫In questo caso, in particolare, è in realtà una falsa sicurezza.
‫Quindi, quello che sta succedendo è che vogliamo davvero che lo sviluppatore Docker o l'utente Docker sul loro computer siano in grado
‫di utilizzare il più possibile i file dello stack.
‫Quindi i contenitori che usi sulla tua macchina locale vedranno effettivamente i segreti proprio come
‫farebbero in Swarm.
‫a meno che non inizializziamo lì, cosa che la maggior parte delle persone non ha intenzione di fare.
‫Ma non abbiamo Swarm sulla nostra macchina locale
‫E il modo in cui archiviamo i segreti è nel database di Swarm.
‫Quindi questo può essere abbastanza ovvio per te, ma i segreti dipendono da Swarm. È una cosa di solo Sciame. Se non hai lo
‫sciame non puoi usare i segreti.
‫Tuttavia, il comando docker-compose ha una soluzione alternativa in cui in realtà monta i segreti in un file di
‫testo libero nel contenitore locale.
‫Ora non è sicuro, ma ci consente di utilizzare i segreti localmente sulla nostra macchina.
‫qualcosa che vorresti usare in produzione, ecco perché abbiamo il negozio sicuro per Swarm.
‫Non è