Quando si utilizza la funzionalità del sacchetto dati crittografato per Chef, come si fa a distribuire la chiave su molti server? Se lo inserisci in una ricetta, chiunque abbia accesso a uno qualsiasi dei server o client dello chef può estrarre la chiave e potenzialmente decodificare qualsiasi databag.
Come si fa a garantire che la chiave si trovi sulle macchine che ne hanno bisogno, ma anche al sicuro da chiunque si curi?
Risposte:
Sfortunatamente non puoi fare molto perché la chiave deve trovarsi da qualche parte sul nodo Chef in testo semplice. Se qualcuno ha shell o accesso locale alla casella, potrebbe essere possibile per loro leggere le chiavi.
Per mitigare un po 'le cose, aggiungo quanto segue al mio nome di base (ovvero una ricetta o un ruolo comune a tutti i nodi):
directory "/etc/chef/keys" do
mode 0700
owner "root"
group "root"
end
e qualunque meccanismo di distribuzione delle chiavi tu abbia messo le chiavi in quella posizione. Le autorizzazioni e la proprietà impediscono la lettura delle chiavi se qualcuno dimentica di inserire le autorizzazioni corrette in un file chiave.
A mio avviso, i sacchetti di dati crittografati sono più utili per proteggere il materiale chiave dalla leggibilità in un sistema di controllo del codice sorgente, e meno come funzionalità di sicurezza sugli stessi nodi Chef.
I miei EDB sono separati da:
Carichiamo tutte le chiavi con un suffisso speciale su ogni nuova istanza di EC2 mentre la bootstrap e quindi rimuoviamo tutte le chiavi che non sono state utilizzate da nessuna delle ricette in run_list alla fine delle prime esecuzioni di chef-client (che sarà proprio quando inizia l'istanza.)
Tutti i file vengono caricati come proprietario e gruppo "root" e con autorizzazioni di sola lettura.
Ogni ricetta che utilizza un EDB, genera il nome EDB e il nome del file chiave al momento dell'esecuzione della ricetta concatenando "edb_" + l'ambiente dei nodi + nome specifico ricetta / elemento + ".key" e quindi cerca la chiave con questo nome . (Se non esiste, viene generata un'eccezione per impostazione predefinita.)
Pertanto, per il nostro server couchdb, che esegue un ruolo chiamato "couch", per ottenere le credenziali che stiamo utilizzando per gli utenti amministratori nell'ambiente di sviluppo, la ricetta cerca una chiave denominata "edb_dev_couch.key"
Quindi cerca un data bag chiamato "edb_dev" per un elemento chiamato "couch_credentials".
Per la gestione delle chiavi, sto attualmente utilizzando il semplice approccio di:
Si spera che questo limiti il tempo in cui le chiavi al di fuori dell'ambito di un singolo nodo sono suscettibili fino a quando la macchina non è stata avviata e ha avuto la prima esecuzione di chef_client.
Questo è il nostro primo giro di test su come proteggere le chiavi, ma finora soddisfa le nostre attuali esigenze poiché impedisce a un server di sviluppo root di accedere immediatamente a qualsiasi altra credenziale del server archiviata in un EDB.
Per continuare ad avere una ricetta alla fine di ogni elenco esecuzioni, utilizzo un processo exec coltello che si assicura che questa ricetta delete_keys sia esattamente l'ultima ricetta su ogni nodo.
Le mie chiavi sono inserite nelle AMI che usiamo o nelle immagini che usiamo. Non lo faccio come parte del bootstrap in quanto i dati non sono sicuri. In genere puoi vedere i dati nei registri e simili se non stai attento.