La gestione della revoca dei certificati attendibili in contenitori come "cloud native" indica il più possibile

Question

La gestione della revoca dei certificati attendibili in contenitori come "cloud native" indica il più possibile

#1 da (0 voti)
#2 da (0 voti)

1

Questa è una domanda difficile da chiedere, quindi portami un po 'con me. Cercherò di essere breve se posso.

Dichiarazione del problema

Sto cercando una best practice moderna per la gestione e la distribuzione dell'elenco di certificati CA attendibili di root dei container Docker. So che posso cuocere i certificati in ogni contenitore attraverso un Dockerfile. Tuttavia, si tratta di una nuova immagine di finestra mobile per ogni contenitore ogni volta che è necessario apportare un certificato o un CRL. Idealmente nello spirito di "cloud native" (vedi 12 app di fattori) i nostri contenitori non avrebbero certificati e CRL infornati e tutto questo proviene dall'ambiente in qualche modo.

Per dare un po 'più di contesto. Sto eseguendo questi contenitori in Kubernetes, ma potrebbero essere eseguiti in qualsiasi piattaforma contenitore come OpenShift, AWS, ecc. E idealmente il mio obiettivo è trovare un'unica soluzione che permetta una vera portabilità del contenitore.

Soluzioni potenziali

Alcune idee con cui ho giocato:

1) crea un altro contenitore che ha tutti i certificati, i CRL e il volume montati su ciascun contenitore. - Questo è un approccio comune ma richiede il salvataggio del contenitore in una nuova immagine ogni volta che un nuovo CERT o CRL è stato aggiornato. Non terribile, ma non si sente molto "cloud nativo".

2) Usa Spring Config Server e costruisci un piccolo sidecar Spring Boot che installa tutti i certs all'avvio. - La configurazione centralizzata esterna sembra cloud nativa. - Potrebbe richiedere pesanti modifiche all'ordine di avvio dei servizi nel contenitore che potrebbero richiedere quei certificati. - Sembra troppo complicato per un contenitore.

3) Utilizzare un proxy in cui tutti i certificati sono gestiti. - Si sente come un hack per forzare tutto il traffico attraverso il proxy. - Possibili problemi di throughput e di conflitto quando si verificano carichi pesanti sulle risorse HTTPS. - Potrebbe non essere possibile instradare tutto su HTTP diretto.

4) Utilizzare le variabili di ambiente e avere uno script di avvio che li installa - Approccio semplice e generalizzato per qualsiasi tipo di contenitore utilizzato ovunque. Non sono sicuro se sia appropriato farlo in questo modo. Questi sarebbero molti valori variabili per l'ambiente. Potete immaginare come sarà una "printenv"?

5) Usa i segreti di Kubernetes (non è sicuro che funzioni ancora) - È una soluzione solo di Kubernetes che è un downer per scrivere una volta, usare ovunque.

So che questo è un po 'prolisso. Mi scuso per quello. Non sapevo come comprimerlo ulteriormente. Non vedo l'ora che inizi la discussione.

docker cloud-computing certificates container

posta Scott Lindner 13.08.2018 - 23:15

fonte

2 risposte

Leggi altre domande sui tag docker cloud-computing certificates container

Strumento di reporting BI conforme a HIPAA? Bug di accesso e-mail, è un problema di sicurezza per gli utenti di e-mail?

score 0 · Answer 1

Una soluzione emersa dalla chat / dai commenti:

Pubblica un tarball di ciò che il trust store dovrebbe avere su un URL statico: hai la possibilità di aggiornarlo a tuo piacimento.
Per il certificato TLS su questo URL, utilizzare un certificato che il contenitore finestra mobile consideri affidabile nella sua configurazione predefinita, da una CA attendibile pubblicamente o una CA radice privata esplicitamente per questo scopo che si aggiunge manualmente al modello finestra mobile. Chiamiamo questo CA bootstrap.

Dove è necessario inserire il certificato CA per il bootstrap dipende da come si recupera il tarball. Ad esempio, con arricciatura:

$ curl -O https://my.server/docker_root_cas.pem --cacert [file]

Poiché i certificati CA sono informazioni pubbliche, basta rilasciare il certificato CA in qualsiasi punto del file system (ovviamente assicurandosi che un utente malintenzionato non possa modificarlo prima dell'avvio, ma se fosse vero, avresti problemi più grandi ... )

Ora hai recuperato in modo sicuro l'elenco di certificati CA attendibili. Ciò porta anche a un meccanismo di aggiornamento semplice grazie al fatto che i contenitori estraggono periodicamente di nuovo l'elenco da questo URL o da uno protetto da un certificato TLS che si collega a una delle CA appena importate.

Considerazioni sulla sicurezza

L'immagine della finestra mobile deve essere protetta contro un utente malintenzionato che sostituisce il file CA di avvio con il proprio.
Il server che ospita il tarball diventa un grande obiettivo, quindi indurisci bene. Doubly-so, se disponi di un meccanismo di aggiornamento in cui i contenitori continuano a caricare periodicamente gli archivi fidati aggiornati perché ora una compromissione del server tarball comprometterà tutti i nuovi e tutti i contenitori esistenti in uno fell swoop.

score 0 · Answer 2

Sono giunto a una conclusione che funziona bene per i nostri bisogni che voglio offrire come risposta alla mia stessa domanda. Abbiamo implementato uno script di shell che stiamo iniettando nei nostri contenitori che possono essere abilitati e configurati tramite variabili di ambiente. Lo scopo di questo script è scaricare una tar ball o un zip di tutti i certificati CA attendibili (e certificati autofirmati per scopi di sviluppo) da installare all'avvio del contenitore docker. Ciò che fa è permetterci di creare un singolo contenitore che può essere distribuito ovunque senza cuocere i certs nel contenitore. Inoltre, questo aggiunge i vantaggi di risolvere un problema di distribuzione di certificati e CRL. Dal momento che ci stiamo adoperando affinché i nostri contenitori siano il più possibile conformi ai 12 fattori (noto anche come cloud native) è possibile pianificare il riavvio dei contenitori su base periodica che servirà effettivamente allo scopo di distribuire certificati e CRL affidabili.

Ho una dimostrazione di questo concetto e funziona molto bene. Per coloro che supportano DoD e IC questo ha un ulteriore vantaggio in quanto i certificati e i CRL approvati per le reti affidabili sono già mantenuti e pubblicati sulla rete in modo tale da poter indirizzare questo script direttamente a quelle palle tar ufficiali per distribuire certificati e CRL .

Sto utilizzando supervisord nei nostri contenitori e ho configurato tutti i [programmi] per non eseguire l'avvio automatico con l'eccezione di un bootstrap.sh che per prima cosa esegue lo script di installazione del certificato e quindi utilizza il comando start [programma] di supervisorctl per avviare i programmi definiti in supverisord.conf. Quale bootstrap.sh è l'unico programma in supervisord.conf che si avvia automaticamente. Questo garantisce che i certificati siano in vigore prima che inizi qualsiasi altra cosa.

Un dettaglio nitty che potrebbe essere essenziale per coloro che desiderano implementare una soluzione simile. Facoltativamente, inoltre, passiamo un certificato nel contenitore come una variabile d'ambiente da utilizzare solo per fidarsi dell'URL della tar ball del certificato che viene anche iniettato tramite una variabile d'ambiente. Questo risolve il potenziale Catch 22 di aver bisogno di un nuovo certificato per ottenere il tar tar del certificato.