Best Practices per la Gestione di Segreti e Dati Sensibili nei Cluster Kubernetes

I segreti Kubernetes sono comodi, ma non sono automaticamente sicuri solo perché l'oggetto si chiama Secret. Se il tuo RBAC è troppo ampio o etcd non è crittografato, un token trapelato può esporre password di database, chiavi API e certificati privati in tutto il cluster.

Usa i segreti Kubernetes come un livello, poi aggiungi crittografia, controllo degli accessi, pattern di iniezione più sicuri e archivi di segreti esterni dove il rischio lo giustifica.

Comprendere i Segreti Kubernetes: Il Meccanismo Predefinito

Kubernetes introduce l'oggetto Secret progettato specificamente per contenere informazioni sensibili. Sebbene utile, è fondamentale comprenderne i limiti e il comportamento predefinito in termini di sicurezza.

Comportamento Predefinito e Avvertenze

Per impostazione predefinita, i segreti Kubernetes non sono crittografati a riposo all'interno di etcd, il database di supporto del cluster per tutti i dati di configurazione. Sono semplicemente codificati in Base64, che non offre alcuna crittografia reale. Chiunque abbia accesso al datastore etcd (ad esempio, amministratori del cluster, nodi compromessi) può decodificare facilmente questi valori.

Avvertenza: Non affidarti mai esclusivamente all'oggetto Secret predefinito di Kubernetes per dati altamente sensibili senza applicare misure di crittografia.

Codifica Base64 vs. Crittografia

È un equivoco comune pensare che la codifica Base64 fornisca sicurezza. Base64 è uno schema di codifica, non uno schema di crittografia. È facilmente reversibile:

# Esempio di decodifica di un valore Secret Kubernetes
echo 'c3VwZXItc2VjcmV0Cg==' | base64 -d
# Output: super-secret

Livello 1: Proteggere i Segreti a Riposo (Crittografia etcd)

Il passo più fondamentale per proteggere i segreti è garantire che siano crittografati a livello di storage (etcd). Questo protegge i dati anche se il database sottostante viene accesso direttamente.

Abilitare la Crittografia a Riposo

La crittografia a riposo viene configurata tramite il server API Kubernetes utilizzando un oggetto EncryptionConfiguration. Questa configurazione specifica quali provider devono essere utilizzati per crittografare vari tipi di dati memorizzati in etcd, inclusi i secrets.

Componenti Chiave della Configurazione di Crittografia:

1. kind: EncryptionConfiguration: Dichiara il tipo di risorsa.
2. resources: Specifica quali risorse API devono essere crittografate.
3. providers: Definisce il meccanismo di crittografia. I provider comuni includono aescbc, aesgcm e provider KMS (come AWS KMS o GCP KMS).

Best Practice: Usa un provider KMS quando la tua piattaforma lo supporta. Se usi chiavi locali, gestisci attentamente la rotazione delle chiavi e mantieni le vecchie chiavi disponibili fino a quando i dati esistenti non sono stati ricrittografati.

Livello 2: Proteggere i Segreti in Transito e in Uso

Mentre la crittografia etcd risolve il problema 'a riposo', i segreti vengono comunque decrittografati dal Kubelet quando vengono montati in un Pod. Dobbiamo controllare come e dove questi segreti appaiono.

Strategia 1: Montaggio di Segreti come Volumi

Il modo standard per iniettare dati Secret in un contenitore è montarli come volume (spesso risultando in un file nel filesystem del contenitore).

apiVersion: v1
kind: Pod
metadata:
  name: secure-app
spec:
  containers:
  - name: my-container
    image: nginx
    volumeMounts:
    - name: secret-volume
      mountPath: "/etc/config/db"
      readOnly: true
  volumes:
  - name: secret-volume
    secret:
      secretName: my-sensitive-secret

Considerazione sulla Sicurezza: I volumi Secret montati sono solitamente supportati da tmpfs sui nodi Linux, ma i valori sono comunque visibili al processo del contenitore e a chiunque abbia sufficiente accesso al nodo o al Pod. Usa readOnly: true, evita di scaricare variabili d'ambiente o file di configurazione nei log e limita l'accesso shell ai Pod di produzione.

Strategia 2: Variabili d'Ambiente (Sconsigliato per Alta Sensibilità)

Sebbene comodo, l'uso di variabili d'ambiente provenienti da Secret è generalmente sconsigliato per segreti di alto valore. Le variabili d'ambiente possono essere facilmente trapelate attraverso:

• Log del contenitore generati da applicazioni mal configurate.
• Lettura di /proc/1/environ dall'interno del contenitore o di altri contenitori privilegiati.
• Strumenti di ispezione del contenitore.

Usa le variabili d'ambiente solo per dati di configurazione a bassa sensibilità, se devi usarle.

Livello 3: Gestione Avanzata con Archivi di Segreti Esterni

Il pattern più sicuro prevede di mantenere i dati sensibili completamente al di fuori del piano di controllo Kubernetes (etcd) e recuperarli dinamicamente in fase di esecuzione utilizzando strumenti specializzati.

Utilizzo di Operatori di Segreti Esterni

Gli operatori di segreti esterni colmano il divario tra un segreto memorizzato in modo sicuro in un vault dedicato (come HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) e l'oggetto Secret nativo di Kubernetes.

1. Archivio: Il segreto reale vive solo nel vault esterno.
2. Sincronizzazione/Iniezione: Un operatore osserva una risorsa personalizzata (come ExternalSecret) e recupera i dati dal vault.
3. Creazione: L'operatore crea quindi un oggetto Secret Kubernetes standard localmente, che può poi essere montato nei Pod.

Vantaggio: La fonte di verità rimane al di fuori del cluster, migliorando la rotazione e la verificabilità. Tuttavia, il Secret Kubernetes sincronizzato esiste ancora nel cluster, quindi hai ancora bisogno di RBAC, crittografia etcd e isolamento dei namespace.

Utilizzo del Driver CSI Secrets Store

Per le applicazioni che necessitano di accesso diretto ed effimero senza memorizzare il segreto localmente in etcd, il driver CSI Secrets Store è la scelta superiore.

• Il driver sfrutta un provider (ad esempio, provider Vault, provider Azure).
• Monta il segreto direttamente dall'archivio esterno nel filesystem del Pod come volume temporaneo, bypassando la necessità di scrivere mai i dati del segreto in etcd.

Questo offre il massimo livello di sicurezza eliminando completamente il segreto dal database etcd.

Best Practice Operative per la Gestione dei Segreti

Oltre ai meccanismi di archiviazione tecnici, l'igiene operativa è cruciale per mantenere una postura di sicurezza.

1. Principio del Minimo Privilegio (PoLP)

Assicurati che il Service Account associato a un Pod abbia solo i permessi per leggere il Secret specifico di cui ha bisogno, e nessun altro. Usa il Controllo degli Accessi Basato sui Ruoli (RBAC) per limitare strettamente i permessi.

2. Ruota Frequentemente i Segreti

Implementa programmi di rotazione automatizzati per tutte le credenziali. I segreti a lunga durata aumentano la finestra di opportunità per compromissioni. Gli strumenti integrati con vault esterni spesso gestiscono questa rotazione automaticamente.

3. Verifica e Monitora l'Accesso

Configura il logging di audit per tracciare chi legge o modifica gli oggetti Secret. Gli strumenti che si integrano con vault esterni (come Vault Agents o driver CSI) dovrebbero anche registrare i tentativi di accesso all'archivio esterno.

4. Non Inviare Mai Segreti su Git

Questa è una regola fondamentale. Non memorizzare mai segreti in chiaro o codificati in Base64 nei repository Git, nemmeno in quelli privati. Usa strumenti come git-secrets o strumenti di templating per la gestione della configurazione (come Helm o Kustomize) combinati con meccanismi di iniezione di segreti esterni per gestire i manifest di deployment.

Esempio con Kustomize (Riferimento Esterno):

Quando usi il templating, potresti usare segnaposto nei tuoi file manifest e affidarti a un passaggio di build o a una pipeline CI/CD per iniettare i valori segreti reali recuperati in modo sicuro da un vault prima di applicare il YAML al cluster.

Confronto delle Strategie di Gestione

Strategia	Livello di Sicurezza	Esposizione etcd?	Complessità	Migliore per
Secret K8s Predefinito (Nessuna crittografia etcd)	Molto Bassa	Sì (Testo in chiaro)	Bassa	Solo test temporanei
Secret K8s con Crittografia etcd	Media	Sì (Crittografato)	Media	Dati di configurazione generali
Operatore di Segreti Esterni	Alta	Sì (Secret gestito dall'operatore)	Alta	Standardizzazione della gestione dei segreti
Driver CSI Secrets Store	Altissima	No (Montaggio Diretto)	Alta	Credenziali e token altamente sensibili

Inizia abilitando la crittografia etcd e stringendo il RBAC. Poi decidi se ogni carico di lavoro può utilizzare Secret sincronizzati, montaggi CSI diretti o credenziali dinamiche da un vault esterno. La configurazione migliore è quella che limita chi può leggere il segreto, dove è memorizzato e per quanto tempo rimane utile dopo l'esposizione.