I migliori strumenti di gestione dei segreti Kubernetes nel 2026: Vault, ESO, segreti sigillati e altro

Ogni cluster Kubernetes viene fornito con un oggetto “Secret” integrato. Sembra sicurezza. Sembra sicurezza. Non è sicurezza.

Un segreto Kubernetes è, per impostazione predefinita, solo una stringa con codifica base64 archiviata in etcd, leggibile da chiunque abbia accesso al cluster e banalmente decodificabile con una riga: echo "c2VjcmV0" | base64 -d. A meno che tu non abbia abilitato esplicitamente la crittografia dei dati inattivi (e la maggior parte dei team non lo ha fatto), le password del database, i token API e le chiavi private TLS risiedono non crittografate nel datastore del piano di controllo del cluster. Invia un manifest Kubernetes contenente un “Segreto” a Git e quella credenziale rimarrà per sempre nella cronologia del tuo repository.

Questo è il problema che è emersa per risolvere una nuova generazione di strumenti di gestione dei segreti e, nel 2026, l’ecosistema è maturato in modo significativo. Questa guida illustra i sei strumenti più importanti per la gestione dei segreti negli ambienti Kubernetes: cosa fanno, cosa non fanno e quale si adatta al livello di maturità del tuo team.

Leggi correlati: Se sei preoccupato per la fuga di segreti attraverso la pipeline CI/CD, consulta la nostra raccolta dei migliori strumenti per pipeline CI/CD. Per un quadro più ampio sulla sicurezza dei container, consulta la nostra guida agli strumenti di scansione delle vulnerabilità.

Perché i segreti predefiniti di Kubernetes non sono all’altezza

Prima di approfondire gli strumenti, vale la pena essere precisi su ciò che manca a Kubernetes Secrets, perché comprendere il divario è ciò che ti consente di scegliere la soluzione giusta.

Nessuna crittografia a riposo per impostazione predefinita. etcd memorizza i segreti Kubernetes come base64, non crittografati. L’abilitazione della Crittografia dei dati inattivi è un passaggio di configurazione a livello di cluster che i provider Kubernetes gestiti (EKS, GKE, AKE) gestiscono in modo diverso e molti cluster autogestiti lo saltano completamente.

Nessuna rotazione dei segreti. Non esiste un meccanismo integrato che consenta a un segreto Kubernetes di sapere che le sue credenziali di supporto sono cambiate. Ruoti una password del database esternamente e i tuoi pod continuano a utilizzare quella vecchia finché non aggiorni manualmente il segreto e riavvii i pod interessati.

Nessun registro di controllo per l’accesso segreto. I registri di registrazione di controllo standard di Kubernetes registrano le modifiche agli oggetti segreti, ma la maggior parte delle configurazioni non registra le letture individuali, il che significa che non puoi rispondere “quale servizio ha avuto accesso a questo token e quando?”

Ostile a Git per natura. Il consiglio standard è “non inserire mai segreti in Git”. Ma in un mondo GitOps in cui l’obiettivo è tutto come codice, questa è un’eccezione dolorosa da mantenere.

RBAC come strumento schietto. Kubernetes RBAC ti consente di concedere o negare l’accesso agli oggetti segreti a livello di spazio dei nomi. Non può esprimere “Il servizio A può leggere il segreto X ma non il segreto Y” o “questo segreto scade tra 24 ore”.

Nessuno di questi è un motivo per abbandonare Kubernetes: sono motivi per utilizzare strumenti dedicati per la gestione dei segreti.

TL;DR: Confronto delle funzionalità

⚠️ = richiede componenti aggiuntivi

1. HashiCorp Vault: il gold standard per i segreti aziendali

HashiCorp Vault è il punto di riferimento rispetto al quale viene misurato ogni altro strumento di gestione dei segreti. È stato testato in ambienti aziendali per quasi un decennio e il suo set di funzionalità riflette questa profondità.

La funzionalità principale di Vault sono i segreti dinamici: credenziali generate su richiesta e che scadono automaticamente. Invece di archiviare una password PostgreSQL statica, Vault genera una coppia nome utente/password univoca per ciascun servizio richiedente, valida per un periodo di lease configurabile (ad esempio, un’ora). Alla scadenza del lease la credenziale viene revocata. Ciò elimina intere classi di espansione delle credenziali e rende notevolmente più semplice il contenimento delle violazioni.

Per Kubernetes, Vault Agent Injector o Vault Secrets Operator sono i percorsi di integrazione. L’iniettore funziona come un webhook mutante che inserisce automaticamente un agente Vault nei tuoi pod, che si autentica su Vault utilizzando l’account di servizio Kubernetes del pod e scrive i segreti su un volume in memoria condiviso. Vault Secrets Operator (VSO), l’approccio più recente, sincronizza i segreti del Vault in oggetti Kubernetes Secret nativi, più familiari agli operatori, a scapito dei segreti esistenti brevemente in etcd.

I motori segreti di Vault coprono una gamma impressionante:

• Credenziali del database (PostgreSQL, MySQL, MongoDB e altro)
• Credenziali dinamiche AWS, GCP, Azure
• Generazione di certificati PKI e TLS
• Firma del certificato SSH
• Token dell’account di servizio Kubernetes

Che cosa fa bene Vault: Credenziali dinamiche, policy di accesso granulari, un registro di controllo completo e un ecosistema di plug-in maturo. Se hai bisogno di una gestione segreta di livello conformità con traccia completa di chi ha avuto accesso a cosa e quando, Vault è spesso l’unica opzione ragionevole.

A cosa prestare attenzione: Vault presenta complessità operativa. L’esecuzione in modalità alta disponibilità richiede un’attenzione particolare ai backend di archiviazione (Raft è ora la scelta consigliata), alle procedure di apertura e ai percorsi di aggiornamento. La curva di apprendimento è reale. Budget per il tempo di progettazione della piattaforma.

Prezzi: La versione open source è gratuita e copre la maggior parte delle esigenze. HashiCorp Cloud Platform (HCP) Vault è l’offerta gestita con prezzi basati sulle ore del cluster e sulle operazioni segrete. La modifica della licenza BSL del 2023 ha portato al fork OpenTofu per Terraform, ma l’equivalente fork di Vault (OpenBao) è ancora in fase di maturazione.

📚 Lettura consigliata: Hacking Kubernetes di Andrew Martin e Michael Hausenblas: eccellente copertura delle superfici di attacco di Kubernetes, inclusi scenari di esfiltrazione segreta.

2. Operatore segreto esterno (ESO): il livello di integrazione nativo di K8s

External Secrets Operator ha una posizione architettonica fondamentalmente diversa: anziché essere esso stesso un secrets store, è un ponte tra Kubernetes e qualunque store esterno già possiedi. ESO sincronizza i segreti di AWS Secrets Manager, GCP Secret Manager, Azure Key Vault, HashiCorp Vault, 1Password, Doppler e un elenco crescente di altri backend in oggetti segreti Kubernetes nativi.

L’astrazione principale è la risorsa personalizzata “ExternalSecret”:

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: database-credentials
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: aws-secrets-manager
    kind: ClusterSecretStore
  target:
    name: db-creds
  data:
    - secretKey: password
      remoteRef:
        key: production/db/password

L’ESO controlla questa risorsa, recupera il segreto da AWS Secrets Manager (o dovunque) e crea un segreto Kubernetes standard. La tua applicazione legge “db-creds” proprio come qualsiasi altro segreto Kubernetes: non sono necessarie modifiche al codice. Quando viene selezionato “refreshInterval”, ESO recupera e aggiorna automaticamente il segreto.

Perché l’ESO è così popolare nel 2026: Funziona bene con gli investimenti esistenti. La tua organizzazione dispone già di AWS Secrets Manager (o Vault o GCP Secret Manager): ESO rende semplicemente utilizzabili questi segreti in Kubernetes senza modificare il codice dell’applicazione o i flussi di lavoro di rotazione dei segreti esistenti.

ESO o Vault Secrets Operator? Se utilizzi Vault, VSO presenta un’integrazione più stretta specifica di Vault (segreti dinamici di Vault, Vault PKI). Se utilizzi l’archivio segreto nativo di un fornitore di servizi cloud, ESO è la scelta più pulita. Molti team eseguono entrambi: ESO per i segreti statici archiviati nel cloud, VSO per le credenziali dinamiche gestite da Vault.

Prezzi: ESO è gratuito e open source (Apache 2.0), gestito da un progetto sandbox CNCF con un forte sostegno della comunità.

3. Segreti sigillati: segreti crittografati compatibili con GitOps

Sealed Secrets di Bitnami risolve un problema specifico: come si archiviano i manifest Kubernetes Secret in Git senza archiviare il testo in chiaro effettivo? La risposta è la crittografia asimmetrica.

Il controller Sealed Secrets viene eseguito nel tuo cluster e contiene una chiave privata. La CLI “kubeseal” crittografa un manifest Kubernetes Secret con la chiave pubblica del cluster, producendo un CRD “SealedSecret”. Questo manifest crittografato può essere inviato a Git in modo sicuro: solo la chiave privata del cluster può decrittografarlo e può essere decrittografato solo in quel cluster specifico (per impostazione predefinita, il testo cifrato è associato a spazio dei nomi + nome).

# Encrypt a secret for Git storage
kubectl create secret generic db-creds \
  --from-literal=password=s3cr3t \
  --dry-run=client -o yaml | \
  kubeseal --format=yaml > db-creds-sealed.yaml

# This file is safe to commit
git add db-creds-sealed.yaml

Quando applichi “SealedSecret” al cluster, il controller lo decrittografa e crea l’oggetto “Secret” corrispondente.

Ciò che Sealed Secrets fa bene: Flussi di lavoro GitOps. Se utilizzi Argo CD o Flux e desideri che ogni risorsa del cluster (inclusi i segreti) venga archiviata in modo dichiarativo in Git, Sealed Secrets si adatta perfettamente a quel modello. Non richiede dipendenze esterne oltre al controller nel cluster.

Cosa non fa: Rotazione, credenziali dinamiche o registrazione di controllo oltre gli eventi Kubernetes standard. Sealed Secrets è una soluzione di archiviazione Git, non una piattaforma completa di gestione dei segreti. Se la tua password cambia, crittografi nuovamente ed esegui nuovamente il commit.

Il backup della chiave privata è fondamentale. Se perdi la chiave privata del controller, perderai la possibilità di decrittografare i tuoi segreti sigillati. Eseguire il backup del segreto sealed-secrets-key in un luogo separato e sicuro.

Prezzi: Completamente gratuito e open source (Apache 2.0).

4. AWS Secrets Manager con Kubernetes

Se i tuoi carichi di lavoro vengono eseguiti principalmente su EKS (o si connettono pesantemente ai servizi AWS), AWS Secrets Manager abbinato al driver CSI Secrets Store o all’operatore Secrets esterno è una soluzione naturale. Mantieni i segreti nell’archivio gestito, crittografato e registrato di AWS e li inserisci in Kubernetes quando necessario.

Il Secrets Store CSI Driver (SSCSID) è l’approccio gestito da CNCF: i segreti vengono montati direttamente nei pod come file tramite un volume CSI, mai scritti su etcd come oggetti segreti Kubernetes. Questo è il percorso di sicurezza più elevato: i segreti esistono nella memoria del pod ma non nell’archivio segreto di Kubernetes.

volumes:
  - name: secrets-store
    csi:
      driver: secrets-store.csi.k8s.io
      readOnly: true
      volumeAttributes:
        secretProviderClass: aws-secrets

Le funzionalità native di AWS Secrets Manager includono la rotazione automatica per i servizi supportati (RDS, Redshift, DocumentDB e tramite Lambda per la rotazione personalizzata), l’accesso tra account e l’integrazione approfondita di CloudTrail per gli audit trail della conformità.

Considerazione sui costi: AWS Secrets Manager addebita i costi per segreto al mese e per chiamata API. Per le grandi flotte con tanti piccoli segreti, i costi possono aumentare. Consulta la nostra guida all’ottimizzazione dei costi del cloud per le strategie sulla gestione della spesa AWS relativa ai segreti.

Ideale per: Team nativi EKS che hanno già investito nell’ecosistema AWS e desiderano una stretta integrazione IAM e una rotazione delle credenziali RDS native.

5. Doppler: la prima piattaforma segreta SaaS per gli sviluppatori

Doppler adotta un approccio SaaS-first che dà priorità all’esperienza dello sviluppatore rispetto alla complessità operativa. Definisci i segreti nell’interfaccia utente di Doppler (o tramite CLI/API), li organizzi per ambiente (sviluppo, staging, produzione) e l’operatore Doppler Kubernetes li sincronizza automaticamente in Kubernetes Secrets.

L’operatore interroga Doppler per verificare le modifiche e aggiorna il segreto Kubernetes corrispondente, facoltativamente attivando il riavvio del pod quando i segreti cambiano. L’installazione è un’unica installazione del grafico Helm:

helm repo add doppler https://helm.doppler.com
helm install --generate-name doppler/doppler-kubernetes-operator

Doppler brilla: Sviluppo locale e integrazione CI/CD insieme a Kubernetes. La CLI Doppler sostituisce completamente i file di ambiente (“doppler run – your-command”), fornendo gli stessi segreti negli ambienti locali, CI e di produzione. Per pipeline CI/CD, le integrazioni native di Doppler con GitHub Actions, CircleCI e altri eliminano la necessità di copiare i segreti nelle variabili di ambiente della pipeline.

Cosa non copre Doppler: Credenziali del database dinamico. Doppler è un archivio di segreti statico con cronologia delle versioni e registrazione di controllo: non è un motore di generazione di segreti come Vault.

Prezzi: Doppler offre un livello gratuito per piccoli team. I piani a pagamento aggiungono SSO, richieste di accesso e funzionalità di conformità. Controlla la pagina dei prezzi di Doppler per i livelli attuali (cambiamenti di prezzo; verifica prima di definire il budget).

6. Infisical: alternativa al vault open source

Infisical è il più forte sfidante open source al duopolio Vault/Doppler. Fornisce un’interfaccia utente Web, una CLI, SDK e un operatore Kubernetes, distribuibile in modalità self-hosted o utilizzato come servizio cloud.

Infisical ha aggiunto il supporto per i segreti dinamici nel 2024, mirando alla generazione di credenziali del database in modo simile al motore dei segreti del database di Vault. L’operatore Infisical Kubernetes sincronizza i CRD “InfisicalSecret” con i segreti Kubernetes nativi, con intervalli di aggiornamento configurabili.

Per i team che desiderano UX a livello SaaS (dashboard web, flussi di lavoro delle richieste di accesso, registri di controllo) ma non possono utilizzare SaaS esterni a causa dei requisiti di conformità, Infisical self-hosted è convincente. È molto più semplice da utilizzare rispetto a Vault e offre un’esperienza di onboarding più intuitiva per gli sviluppatori.

Prezzi: Il core open source è gratuito. La versione ospitata sul cloud ha un livello gratuito e piani a pagamento per funzionalità avanzate. La licenza aziendale self-hosted è disponibile per ambienti con requisiti di conformità elevati.

📚 Per un approfondimento sull’architettura di sicurezza di Kubernetes: Kubernetes Security and Observability su Amazon copre segreti, RBAC, policy di rete e sicurezza di runtime in un unico framework coerente.

Suggerimenti per l’implementazione

Inizia con la crittografia dei dati inattivi. Prima di aggiungere qualsiasi strumento aggiuntivo, abilita la crittografia Kubernetes etcd dei dati inattivi. Per i cluster gestiti, spesso si tratta di una singola casella di controllo. Per i cluster autogestiti, segui la guida ufficiale. Ciò aumenta immediatamente la tua posizione di sicurezza di base.

Adotta l’RBAC con privilegi minimi per i segreti. Controlla quali account di servizio dispongono delle autorizzazioni “get”, “list” o “watch” sugli oggetti segreti. Gli account di servizio predefiniti in molti grafici Helm presentano un provisioning eccessivo. Stringere l’RBAC prima di passare a un archivio esterno.

Pianifica in anticipo le convenzioni per la denominazione dei segreti. I segreti proliferano rapidamente. Una gerarchia coerente ({env}/{service}/{credential-type}) rende l’automazione, le policy RBAC e i flussi di lavoro di rotazione notevolmente più semplici in tutti gli strumenti.

Non saltare i test di rotazione segreti. Qualunque strumento tu scelga, esegui un esercizio di rotazione prima che ti serva. Verifica che la tua applicazione acquisisca nuove credenziali senza tempi di inattività. I segreti dinamici con Vault o ESO rendono tutto ciò molto più semplice rispetto ai segreti statici aggiornati manualmente.

Monitora l’espansione dei segreti. Man mano che la tua piattaforma cresce, i segreti si accumulano. Integra il reporting sulla gestione dei segreti nei dashboard di ingegneria della tua piattaforma. Consulta la nostra Guida agli strumenti di monitoraggio Kubernetes per gli strumenti di osservabilità in grado di tenere traccia dei modelli di accesso segreto.

Quale strumento per quale squadra?

Team piccolo, nativo del cloud (AWS/GCP/Azure): Inizia con l’operatore dei segreti esterni che si connette all’archivio segreto nativo del tuo provider cloud. Spese operative minime, solida integrazione di audit, gratuita.

GitOps-first team (Argo CD/Flux): Segreti sigillati per la configurazione archiviata in GitOps, combinati con ESO per credenziali di runtime sensibili che non dovrebbero essere nemmeno crittografate in Git.

Azienda con requisiti di conformità (SOC 2, PCI, HIPAA): HashiCorp Vault: cluster Raft self-hosted o HCP Vault gestito. Il registro di controllo, le credenziali dinamiche e il motore di policy a grana fine sono difficili da replicare altrove.

Ambiente misto focalizzato sull’esperienza dello sviluppatore (K8 + locale + CI/CD): Doppler per DX unificato tra ambienti o Infisical self-hosted se la residenza dei dati è importante.

Team di piattaforma di grandi dimensioni che gestisce ambienti multi-cluster: Operatore Secrets esterno come livello di astrazione lato K8, supportato da Vault o da un archivio nativo del cloud. Centralizzare la fonte della verità in un unico negozio utilizzando l’ESO come adattatore universale tra i cluster è un modello ben collaudato nel 2026.

Correlato: Per i rischi per la sicurezza introdotti dagli strumenti di codifica AI nei manifest Kubernetes e nelle pipeline CI/CD, consulta la nostra guida sui rischi per la sicurezza della codifica di vibe nel 2026.

Domande frequenti

I segreti Kubernetes sono crittografati per impostazione predefinita?

No. I segreti Kubernetes sono codificati in base64 per impostazione predefinita: codifica, non crittografia. I dati vengono archiviati in etcd senza crittografia a meno che non si abiliti esplicitamente la crittografia dei dati inattivi. Verifica sempre la configurazione del cluster e considera strumenti di gestione dei segreti esterni per i carichi di lavoro di produzione.

Qual è la differenza tra Sealed Secrets e Operatore Secrets Esterno?

Sealed Secrets crittografa i manifest segreti per un’archiviazione Git sicura: è una soluzione GitOps. L’Operatore dei segreti esterni recupera segreti in tempo reale da archivi esterni (Vault, AWS Secrets Manager, ecc.) e crea da essi segreti Kubernetes nativi. Risolvono problemi diversi e vengono spesso utilizzati insieme.

Cosa sono i segreti dinamici e perché sono importanti?

I segreti dinamici sono credenziali generate su richiesta con scadenza automatica, anziché password statiche archiviate a tempo indeterminato. HashiCorp Vault è la fonte principale di segreti dinamici per Kubernetes. Se una credenziale dinamica viene compromessa, scade secondo la propria pianificazione. Ciò limita drasticamente il raggio di esplosione della violazione rispetto ai segreti statici di lunga durata.

Dovrei utilizzare Doppler o HashiCorp Vault per Kubernetes?

Doppler vince in termini di esperienza degli sviluppatori e rapida adozione. Vault vince in termini di conformità aziendale: credenziali dinamiche, registri di controllo granulari e policy granulari. Per i team di piccole e medie dimensioni, il Doppler è spesso il percorso più veloce. Per gli ambienti SOC 2, PCI DSS o HIPAA, Vault è in genere la scelta più difendibile.

Come posso evitare che i segreti penetrino nei log del contenitore?

Monta i segreti come file anziché come variabili di ambiente (le variabili di ambiente possono essere esposte tramite “/proc” e gli endpoint di debug). Utilizzare il driver CSI Secrets Store per ignorare completamente etcd. Esegui la scansione per individuare commit segreti accidentali nella tua pipeline CI/CD con strumenti come lo scanner segreto di Trivy: consulta la nostra guida agli strumenti di scansione delle vulnerabilità per i dettagli di configurazione.

Qual è il miglior strumento di gestione dei segreti per un piccolo team Kubernetes?

Inizia con l’operatore di segreti esterni supportato dall’archivio segreto nativo del tuo provider cloud. Overhead operativo minimo, registrazione di controllo solida, gratuita. Aggiungi il livello gratuito di Doppler se desideri anche un’esperienza unificata di segreti di sviluppo/CI/produzione.

Come posso integrare AWS Secrets Manager con Kubernetes?

Utilizza l’operatore Secrets esterno con un ClusterSecretStore che punta ad AWS Secrets Manager. Su EKS, utilizza IRSA (ruoli IAM per account di servizio) per l’autenticazione IAM a livello di pod: non sono necessarie credenziali statiche. Sui cluster non EKS, utilizza un utente IAM con secretsmanager:GetSecretValue con ambito agli ARN segreti specifici.