2015-08-26 31 views
8

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:Popolazione di contenitori Docker con informazioni sensibili tramite kubernetes

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?

+0

@larsks Ma il file di definizione per il segreto non dovrebbe essere archiviato in chiaro? O in base64, che potrebbe essere facilmente decodificato. – hohner

+0

Sì, e ho interpretato erroneamente il fatto che stavi già sfruttando questa API. Quindi, non importa ... – larsks

+0

Come ho capito, Secrets è il modo per passare informazioni sensibili, ma ha i suoi limiti. Eppure è meglio che passare informazioni sensibili direttamente nelle variabili ENV. – MrE

risposta

4

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.

+1

Bene, ecco perché non sono sicuro che questa sia una buona idea: 1. Penso che il posizionamento segreti in singoli file un po 'goffi, dal momento che non è il modo in cui la maggior parte delle applicazioni si occupa di dati sensibili. Dovresti scrivere una logica extra di avvio, il che è sconveniente. 2. Il montaggio di file di volume e il loro inserimento nell'env è troppo statico. Preferirei che la configurazione della mia app fosse memorizzata dinamicamente in etcd, usando 'crypt' per la crittografia. 3. Da un punto di vista della sicurezza, penso che richiedere tempo e conoscenza extra per l'accesso sia meglio che darglielo in chiaro. – hohner

+0

un segreto può essere lungo solo 256 caratteri ... quindi funziona bene per password e chiavi, ma non per cose come certificati ecc ... può essere molto più lungo. – MrE

+1

Un segreto * chiave * può essere solo 256 caratteri; non c'è limite ai dati * segreti *. – lavalamp

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.

Problemi correlati