Sicurezza nei sistemi automatici che utilizzano Puppet and Chef

5

In una presentazione estremamente interessante al Puppet Camp di Londra, Tomas Doran ha suggerito un approccio piuttosto radicale per mantenere tutto automatizzato gestendo tonnellate di container Docker con Puppet.

Essendo una persona attenta alla sicurezza, mi piace l'idea di Docker, poiché tutto viene eseguito nel proprio LXC e configuro tutti i servizi in modo che vengano eseguiti come non%% di utenti.

Come persona attenta all'amministrazione dei sistemi, mi piace l'idea della gestione di Puppet, dato che posso mantenere tutta la configurazione in un repository Git e persino mantenere ambienti diversi, il tutto nel controllo della versione. Il vantaggio è anche che ho ambienti in grado di strappare-giù (è una parola?) Che posso teoricamente ricostruire da zero senza troppi interventi manuali.

Tuttavia, ci sono cose che vorrei non da conservare in un repository Git, ovvero certificati SSL, password di database, ecc.

In che modo le organizzazioni che gestiscono enormi quantità di macchine (come il CERN) utilizzano servizi di provisioning come Puppet e Chef pur mantenendo la sicurezza? Certe cose sembrano facili, come imporre autorizzazioni sui file, ma altre cose sembrano difficili, come l'installazione di chiavi SSL o chiavi host SSH, che richiede un intervento manuale.

    
posta Naftuli Kay 13.06.2014 - 02:08
fonte

1 risposta

6

Ho usato un'installazione di marionette, quindi parlerò a quello che ho fatto allora.

  1. Le chiavi host SSH sono effimere. Quindi, quando costruisci un nuovo sistema o ne ricostruisci uno esistente, lasciamo che nuove chiavi vengano generate da SSHD quando è stato avviato. C'erano relativamente pochi utenti SSH in queste macchine e, durante la ricostruzione delle macchine, abbiamo pubblicato le impronte digitali delle chiavi host su un wiki interno. Quindi un utente malintenzionato dovrebbe compromettere l'accesso alle connessioni Wiha host e MITM SSH ed essere pronto a farlo subito dopo che la macchina è stata creata.

  2. Abbiamo sempre generato nuove chiavi SSL durante la reinstallazione della macchina. Uno dei passaggi umani nella ricostruzione dei servizi che coinvolgevano SSL stava generando la chiave, il CSR, e ottenendolo firmato dalla CA e quindi installando il certificato. Abbiamo usato uno script prepopolato da un modello di burattino per avere il CN & altri campi correttamente impostati.

Dubito che il CERN abbia molti host con certificati SSL coinvolti. O forse lo fanno, ma avere una CA automatizzata per firmare i certificati su richiesta di puppet.

Inoltre, non considero la memorizzazione di certs & le chiavi in un repository git ben controllato sono necessariamente cattive. Abbiamo appena preso il punto in cui stavamo ricostruendo un sistema come una grande opportunità per ruotare le nostre chiavi.

    
risposta data 13.06.2014 - 02:15
fonte

Leggi altre domande sui tag