Popolazione di contenitori Docker con informazioni sensibili tramite kubernetes

Question

Possiedo un pod che esegue contenitori che richiedono l'accesso a informazioni sensibili come le chiavi API e le password DB. In questo momento, questi valori sensibili sono incorporati nelle definizioni regolatore in questo modo:

env: 
- name: DB_PASSWORD 
    value: password 

che sono quindi disponibili all'interno del contenitore Docker come variabile $DB_PASSWORD ambiente. Tutto abbastanza facile.

Tuttavia, leggendo la loro documentazione su Secrets, affermano esplicitamente che l'inserimento di valori di configurazione sensibili nella definizione viola le best practice ed è potenzialmente un problema di sicurezza. L'unica altra strategia mi viene in mente è la seguente:

• creare una chiave OpenPGP per comunità di utenti o namespace
• uso crypt per impostare il valore di configurazione in etcd (che è codificato utilizzando la chiave privata)
• creare un segreto kubernetes contenente la chiave privata, like so
• associato quel segreto con il contenitore (il che significa che la chiave privata sarà accessibile come montare un volume), like so
• quando l'ho container avviato, accederà al file all'interno del volume mount per la chiave privata e lo userà per decrittografare i valori conf restituiti da etcd
• questo può quindi essere incorporato in confd, che popola i file locali secondo una definizione di modello (tale come file di configurazione Apache o WordPress)

Questo sembra abbastanza complicato, ma più sicuro e flessibile, poiché i valori non saranno più statici e memorizzati in testo in chiaro.

Quindi la mia domanda, e so che non è del tutto obiettiva, è se questo sia completamente necessario o no? Solo gli amministratori saranno in grado di visualizzare ed eseguire le definizioni RC in primo luogo; quindi se qualcuno ha violato il master di Kubernetes, hai altri problemi di cui preoccuparti. L'unico vantaggio che vedo è che non c'è pericolo che i segreti vengano trasferiti al filesystem in testo in chiaro ...

Esistono altri modi per popolare i contenitori Docker con informazioni segrete in modo sicuro?

Answer 1

A meno che non si disponga di molti megabyte di configurazione, questo sistema sembra inutilmente complesso. L'uso previsto è per voi di mettere ogni configurazione in un segreto, e i pod che necessitano della configurazione possono montare quel segreto come volume.

È quindi possibile utilizzare una varietà di meccanismi per trasferire tale configurazione all'attività, ad es. se si tratta di variabili di ambiente source secret/config.sh; ./mybinary è un modo semplice.

Non credo che tu guadagni ulteriore sicurezza archiviando una chiave privata come segreto.

Answer 2

Io personalmente risolverei all'utente un keymanager remoto che il tuo software potrebbe accedere attraverso la rete tramite una connessione HTTPS. Ad esempio, Keywhiz o Vault corrisponderebbero probabilmente al conto.

Vorrei ospitare il keymanager su una subnet separata separata e configurare il firewall per consentire solo l'accesso agli indirizzi IP di cui mi aspettavo che avessero bisogno delle chiavi.Sia KeyWhiz che Vault sono dotati di un meccanismo ACL, quindi potresti non dover fare nulla con i firewall, ma non fa male a considerarlo - tuttavia la chiave qui è ospitare il keymanager su una rete separata, e anche possibile un fornitore di hosting separato.

Il file di configurazione locale nel contenitore conterrà solo l'URL del servizio chiavi e possibili credenziali per recuperare la chiave dal keymanager: le credenziali sarebbero inutili per un utente malintenzionato se non corrispondesse all'ACL/Indirizzi IP.