Sicurezza delle marionette e topologie di rete

Sfondo:

Finalmente mi sto riservando del tempo per unirmi al 21 ° secolo e guardare Puppet.

Allo stato attuale controlliamo tutte le configurazioni del server in un repository che si tiene internamente in ufficio. Quando è necessario effettuare un aggiornamento, le modifiche vengono ricontrollate nei repository e trasferite manualmente alla macchina in questione. Questo di solito significa SFTP sul computer remoto e quindi spostare i file in posizione, con le relative autorizzazioni, da una shell.

Quindi spero che Puppet sarà un'estensione semplice ma sorprendente di ciò che già abbiamo.

Ora considero il processo che attualmente dobbiamo essere ragionevolmente sicuri. Partendo dal presupposto che la nostra rete interna sarà sempre relativamente più sicura delle reti pubbliche nei nostri data center.

• Il processo è sempre a senso unico. I cambiamenti attraversano da un ambiente sicuro a insicuro e mai il contrario.

• Il negozio principale si trova nel posto più sicuro possibile. Il rischio di compromesso, rubando configurazioni o inviando modifiche dannose, è notevolmente ridotto.

Domanda:

Da quello che ho capito del modello server / client Puppet è che i client eseguono il polling e tirano giù gli aggiornamenti direttamente dal server. Il traffico è protetto da SSL, quindi non può essere intercettato o falsificato. Ma differisce da quello che facciamo attualmente perché i server Puppet dovrebbero essere ospitati in un luogo pubblico. A livello centrale o uno per ogni sito di data center che gestiamo.

Quindi mi chiedo:

• Sono inutilmente paranoico sul passaggio da push a pull?

• Sono inutilmente paranoico sulla memorizzazione centralizzata di tutte queste informazioni su una rete pubblica?

• In che modo altri gestiscono più reti - server separato per ciascun sito?

Aggiornamento 30/07/09:

Immagino che un'altra delle mie maggiori preoccupazioni sia quella di porre la fiducia in una singola macchina. I burattinai sarebbero protetti da firewall, protetti e così via. Ma anche così qualsiasi macchina pubblica con servizi di ascolto ha una superficie di attacco di una certa dimensione.

Presumibilmente se il master dispone dell'autorizzazione per aggiornare qualsiasi file su uno qualsiasi dei client fantoccio, il suo compromesso alla fine comporterebbe il compromesso di tutti i suoi client. I "re del regno" per così dire.

• Questa ipotesi è corretta?

• Esiste un modo per mitigarlo?

Poiché a volte memorizzo le password in variabili nei miei moduli, per essere in grado di distribuire applicazioni senza dover completare la configurazione manualmente, ciò significa che non riesco a mettere decentemente il mio repository fantoccio su un server pubblico. Ciò significherebbe che attaccare il burattinaio consentirebbe di ottenere alcune password app o db di tutte le nostre diverse applicazioni su tutti i nostri server.

Quindi il mio burattinaio è nella nostra rete privata dell'ufficio e non eseguo il demone puppetd sui server. Quando devo distribuire, utilizzo ssh dalla rete privata ai server, creando un tunnel e chiamando da remoto puppetd.
Il trucco non è di impostare il tunnel remoto e il client fantoccio per connettersi al burattinaio, ma a un proxy che accetta http connect e può raggiungere il server fantoccio sulla rete privata. Altrimenti il ​​burattino rifiuterà di estrarre a causa del conflitto del nome host con i certificati

# From a machine inside privatenet.net :
ssh -R 3128:httpconnectproxy.privatenet.net:3128 \
    -t remoteclient.publicnetwork.net \
    sudo /usr/sbin/puppetd --server puppetmaster.privatenet.net \
    --http_proxy_host localhost --http_proxy_port 3128 \
    --waitforcert 60 --test –-verbose

Funziona per me, spera che ti aiuti

Abbiamo due siti, il nostro ufficio e il nostro colo. Ogni sito ha il suo burattinaio. Abbiamo creato un repository svn con la seguente struttura:

root/office
root/office/manifests/site.pp
root/office/modules
root/colo
root/colo/manifests/site.pp
root/colo/modules
root/modules

La directory dei moduli sotto ciascun sito è una directory svn: externals torna alla directory dei moduli di livello superiore. Ciò significa che condividono esattamente la stessa directory dei moduli. Quindi ci assicuriamo che la stragrande maggioranza delle classi che scriviamo siano nella directory dei moduli e utilizzati da entrambi i siti. Questo ha il bel vantaggio di costringerci a pensare in modo generico e non legare una classe a un determinato sito.

Per quanto riguarda la sicurezza, ospitiamo il nostro burattinaio (e il resto della nostra rete) dietro il nostro firewall, quindi non siamo così preoccupati di archiviare la configurazione centralmente. Il burattinaio invierà solo la configurazione agli host di cui si fida. Ovviamente è necessario mantenere quel server sicuro.

Non posso dare un giudizio su quanto sia necessaria la tua paranoia, dipende fortemente dal tuo ambiente. Tuttavia, posso affermare con sicurezza che i due punti principali della configurazione esistente possono ancora essere applicati. Puoi assicurarti che il tuo cambiamento passi da un ambiente sicuro (il repository del tuo ufficio) a un ambiente meno sicuro, ovunque si trovi il tuo burattinaio. Modifichi il processo da SFTP a un gruppo di server e inserendo manualmente i file in SFTP per il tuo burattinaio e lasciando che Puppet distribuisca i file e li metta nella posizione corretta. Il tuo negozio principale è ancora il repository e i tuoi rischi sono mitigati.

Non credo che push o pull siano intrinsecamente più sicuri dell'altro modello. Puppet fa un ottimo lavoro nel proteggere le configurazioni in transito, nonché nell'autenticare client e server per garantire che vi sia una fiducia bidirezionale in atto.

Per quanto riguarda le reti multiple, lo gestiamo con un burattinaio "master" centrale con burattinai in ogni posizione fungendo da client per il master centrale.

Un approccio progettuale consiste nell'avere un burattinaio locale in ciascun sito di sistemi e utilizzare uno strumento di distribuzione per inviare modifiche ai burattinai. (Anche usare git con git git potrebbe funzionare).

Ciò manterrebbe la tua preoccupazione per i servizi di ascolto su una rete pubblica poiché il traffico di reti fantoccio sarebbe solo interno.

È anche possibile eseguire il push dei manifest su ciascun server e fare in modo che il client fantoccio analizzi i manifest e applichi le relative configurazioni.

anche se dici "esterno", dubito davvero che le persone arbitrarie debbano collegarsi al tuo burattinaio. puoi sempre lanciare una VPN nel mix. un mio amico una volta mi ha chiesto "devi preoccuparti della sicurezza del protocollo se la connessione è sicura?" mentre non sono d'accordo con quell'atteggiamento, uno strato extra non fa mai male e certamente fa miracoli sulla mia paranoia personale. inoltre, è divertente scavare tunnel.

Mark Burgess, autore di cfengine e professore universitario (a cui sembra che il burattino debba la sua eredità) ha scritto molto su push and pull. Afferma che pull è intrinsecamente più sicuro. Se guardi al sito Web di cfengine, hanno avuto solo 1 incidente di sicurezza della rete in 17 anni. Burgess afferma che ciò è dovuto al design pull. Penso che un singolo punto di compromesso sia inevitabile. Sarei più preoccupato per le vie di attacco fino a quel punto.

Se lo desideri, puoi eseguire il burattino senza un maestro centrale. Un metodo che ho visto è usare un repository git e avere degli script che uniranno e distribuiranno un aggiornamento solo se il tag è firmato da uno di un elenco predefinito di chiavi gpg. Le persone hanno persino capito come ottenere le configurazioni memorizzate (utilizzate ad esempio per impostare il monitoraggio dei nagios su un server centrale da una risorsa elaborata su un altro server).

Quindi, se il server git centrale fosse compromesso, gli altri server non avrebbero applicato altri aggiornamenti da esso. Le chiavi di gpg sarebbero su laptop amministratore di sistema o qualcosa del genere, insieme a un modo di revocare le chiavi.

Maggiori informazioni su http://current.workingdirectory.net/posts/2011/puppet-without-masters/