Secrets on My personal blog

Segreti in Kubernetes senza lacrime

Tue, 28 Jul 2026 09:00:00 +0200

Perché conta

Abbiamo imparato a non mettere mai i segreti nel codice. Nel cluster il problema torna con una trappola specifica: i Secret di Kubernetes sono codificati in base64, non cifrati. Chiunque legga l’oggetto Secret, o acceda a etcd, li legge in chiaro con un comando. Sono comodi per consegnare un segreto a un pod, ma pessimi come deposito. Questo capitolo è come usarli bene senza illudersi.

base64 non è cifratura

1
2
3

kubectl get secret db-pass -o jsonpath='{.data.password}' | base64 -d
# → stampa la password in chiaro.
# base64 è una CODIFICA, non una protezione: reversibile da chiunque, senza chiave.

Due conseguenze immediate: cifrare etcd a riposo (encryption-at-rest, idealmente con un KMS esterno) perché altrimenti chi copia etcd ha tutti i segreti; e restringere con RBAC chi può leggere i Secret, perché il permesso get secrets equivale ad avere quei segreti.

Il problema del GitOps

Il GitOps vuole tutto in git, inclusa la configurazione dei Secret. Ma committare un Secret, anche base64, è committare il segreto in chiaro nella history. Due soluzioni opposte:

  flowchart TD
    subgraph A[External Secrets Operator]
        G1[Git: solo un<br/>RIFERIMENTO al segreto] --> ESO[Operator]
        V[(Vault / cloud<br/>secret manager)] --> ESO
        ESO -->|crea/sincronizza| S1[Secret nel cluster]
    end
    subgraph B[Sealed Secrets]
        G2[Git: segreto<br/>CIFRATO, sicuro da<br/>committare] --> CTRL[Controller]
        CTRL -->|decifra con chiave<br/>solo nel cluster| S2[Secret nel cluster]
    end
    style V fill:#fde2e4,stroke:#e63946

External Secrets Operator: la fonte di verità resta un vault esterno; in git c’è solo un riferimento. L’operator sincronizza. Il segreto non tocca mai git.
Sealed Secrets: il segreto si cifra con una chiave pubblica; la cifratura è sicura da committare perché solo il controller nel cluster ha la chiave privata per decifrarla.

Montare senza esporre

Il modo in cui il segreto arriva al container conta. Le variabili d’ambiente sono comode ma trapelano facilmente (compaiono nei dump, nei log di errore, nell’introspezione del processo). Montare i segreti come file è più sicuro, e i CSI Secrets Store driver fanno un passo oltre: montano il segreto dal vault esterno direttamente nel filesystem del pod a runtime, senza nemmeno creare un oggetto Secret persistente. Il segreto esiste solo finché il pod vive.

Rotazione e vita breve

Vale qui ciò che valeva per i segreti applicativi: meglio dinamici e a vita breve che statici e rotati a mano. L’External Secrets Operator può ri-sincronizzare periodicamente; i vault possono emettere credenziali effimere. E l’approdo naturale è non consegnare affatto un segreto condiviso, ma dare a ogni workload una identità da cui derivare le credenziali — il tema del prossimo capitolo.

Domanda: se cifro etcd a riposo e restringo l'RBAC, i Secret nativi di Kubernetes non sono già abbastanza sicuri? Perché aggiungere la complessità di vault esterni e operator?

Cifrare etcd e stringere l'RBAC sono necessari e vanno fatti comunque, ma risolvono solo una parte del problema, e la parte che lasciano aperta è spesso quella dove i segreti trapelano davvero. Cosa coprono: chi ruba una copia di etcd non legge i segreti (cifratura a riposo), e chi non ha i permessi non può fare get secrets (RBAC). Cosa non coprono: primo, il ciclo di vita. Un Secret nativo è statico — lo crei una volta e resta lì finché qualcuno lo ruota a mano, cosa che in pratica non succede mai; non c'è rotazione automatica, non c'è scadenza, un segreto trapelato vale finché qualcuno non se ne accorge. Un vault esterno offre credenziali dinamiche a vita breve, così il valore di un furto crolla. Secondo, il perimetro di fiducia. Con i Secret nativi, la tua sorgente di verità per i segreti è il cluster stesso: chiunque comprometta il cluster — o un suo amministratore — ha tutti i segreti. Con un vault esterno il cluster è solo un consumatore, il vault applica le proprie policy di accesso e audit, e puoi revocare l'accesso del cluster senza toccare i segreti. Terzo, la frammentazione. Senza un vault, ogni cluster ha i suoi Secret scollegati; con un vault hai una gestione centralizzata, un audit unico di chi ha letto cosa, e la stessa credenziale non duplicata in dieci posti. Quarto, il GitOps: i Secret nativi ti costringono a scegliere tra non mettere i segreti in git (e perdere la riproducibilità) o committarli in base64 (e bruciarli); External Secrets e Sealed Secrets risolvono esattamente questo. Non sto dicendo che ti serva sempre tutto l'armamentario: per un cluster piccolo, Secret nativi + etcd cifrato + RBAC stretto sono un punto di partenza onesto. Ma la complessità del vault non è gratuita per capriccio: compra rotazione, vita breve, centralizzazione e audit — cioè proprio le proprietà che trasformano "il segreto è protetto se nessuno sbaglia" in "il segreto vale poco anche se qualcosa va storto". La domanda da farsi è quanto vale ciò che quei segreti proteggono.

Conclusione

I Secret di Kubernetes sono un meccanismo di consegna, non una cassaforte: base64 non è cifratura, quindi servono etcd cifrato e RBAC stretto, e per il GitOps o un vault esterno (External Secrets) o la cifratura (Sealed Secrets), montando a runtime via CSI quando possibile. Il passo successivo è smettere di consegnare segreti condivisi e dare a ogni workload la propria identità verificabile, da cui tutto il resto deriva. È l’identità dei workload nella pipeline e nel cluster, prossimo capitolo.

Gestione dei segreti: mai nel codice

Tue, 07 Apr 2026 09:00:00 +0200

Perché conta

Il threat modeling identifica dove i dati attraversano confini di fiducia; i segreti — chiavi, token, password — sono proprio ciò che protegge quei confini. Lasciarli nel codice è l’errore più banale e più diffuso: una chiave AWS in un commit, un token in un file .env versionato, e un repository anche privato diventa una bomba a orologeria. È il primo difetto concreto da eliminare nel flusso di sviluppo.

Il problema della history di Git

Il tranello peggiore: rimuovere un segreto con un commit successivo non lo elimina. Resta nell’intera history, recuperabile da chiunque abbia accesso al repository.

git add config.py        # contiene AWS_SECRET=...
git commit -m "config"   # il segreto è ora NELLA history, per sempre
git rm config.py         # lo toglie dalla HEAD, NON dalla history
# → il segreto va considerato COMPROMESSO: ruotalo subito

Regola d’oro: un segreto committato è un segreto bruciato. Non basta rimuoverlo, va ruotato (invalidato e rigenerato). La pulizia della history (con strumenti come git filter-repo) serve a non ripetere l’incidente, non a “annullarlo”.

I tre livelli di difesa

  flowchart TD
    A[1. Prevenzione<br/>secret scanning<br/>pre-commit] --> B[2. Centralizzazione<br/>secret manager<br/>niente segreti nel codice]
    B --> C[3. Riduzione del danno<br/>segreti dinamici<br/>a vita breve]
    style C fill:#fde2e4,stroke:#e63946

Prevenzione: uno scanner (gitleaks, trufflehog) come hook di pre-commit e nella pipeline blocca il segreto prima che entri nella history.
Centralizzazione: un secret manager (Vault, AWS Secrets Manager, cloud KMS) custodisce i segreti; l’applicazione li recupera a runtime con una propria identità, non li porta nel codice.
Riduzione del danno: i segreti dinamici — credenziali generate su richiesta e valide pochi minuti — fanno sì che un segreto trapelato valga quasi nulla, perché scade subito.

Segreti dinamici: il salto di qualità

Un segreto statico vive per mesi: se trapela, l’attaccante ha mesi. Vault può invece generare al volo una credenziale di database valida un’ora, legata al servizio che l’ha chiesta. Il furto diventa una finestra di minuti, non un accesso permanente. È lo stesso principio dei certificati a vita breve che vedremo per l’identità dei workload: ridurre il valore nel tempo di ogni credenziale.

Nel flusso di lavoro

Pre-commit: hook locale che rifiuta il commit con un segreto.
CI: scansione del diff e, periodicamente, dell’intera history.
Runtime: l’app chiede il segreto al manager con la sua identità; nessun segreto nel container image né nelle variabili d’ambiente scritte a mano.
Rotazione: automatica e regolare, non “quando ci ricordiamo”.

Domanda: se l'app recupera i segreti da Vault, le serve comunque una credenziale per autenticarsi a Vault — non abbiamo solo spostato il problema?

È la domanda giusta, ed è il classico "problema del segreto zero" — lo stesso che SPIFFE/SPIRE risolve per i workload. Sì, serve una credenziale iniziale per parlare con Vault, ma la si è spostata da "mille segreti sparsi in mille repository e file di config" a "un solo punto di bootstrap, progettato apposta per essere protetto". E quel bootstrap non deve essere a sua volta un segreto statico scritto da qualche parte: i metodi di auth di Vault sfruttano un'identità che la piattaforma attesta, non una stringa consegnata. In Kubernetes l'app si autentica con il suo ServiceAccount token, che il cluster emette e verifica; in cloud con l'identità dell'istanza (IAM role, managed identity), provata dal provider; con SPIFFE, con lo SVID emesso per attestazione. In tutti i casi la fiducia iniziale poggia su qualcosa che l'ambiente testimonia — "sei il pod X nel namespace Y sul nodo Z" — non su una chiave che qualcuno deve custodire per prima. Il problema non è "spostato" in circolo: è ridotto da N segreti fragili a un unico punto radicato nell'identità della piattaforma, molto più difendibile e monitorabile.

Conclusione

I segreti non stanno mai nel codice: si previene con lo scanning, si centralizza con un secret manager, si riduce il danno con segreti dinamici a vita breve. E un segreto committato è un segreto da ruotare, non da nascondere. Con i segreti fuori dal codice, possiamo guardare il codice stesso: il primo controllo automatico che lo ispeziona mentre viene scritto è l’analisi statica, prossimo capitolo.