# Kubernetes Secrets Management 2026: External Secrets, Vault e Domande da Colloquio > Padroneggiare la gestione dei segreti Kubernetes con External Secrets Operator e HashiCorp Vault. Pattern sicuri, errori comuni da evitare e preparazione per domande da colloquio DevOps sui segreti k8s. - Published: 2026-09-02 - Updated: 2026-09-02 - Author: Anthony Fillion-Maillet - Tags: kubernetes, secrets, vault, external-secrets, security, devops - Reading time: 12 min --- La gestione dei segreti Kubernetes rimane una delle sfide di sicurezza più critiche nell'orchestrazione dei container. I Secrets nativi di Kubernetes memorizzano dati sensibili come valori codificati in base64, che non forniscono crittografia a riposo per impostazione predefinita e creano rischi di sicurezza che i selezionatori esplorano frequentemente durante i processi di assunzione DevOps. > **Risposta Rapida per Colloqui** > > Quando viene chiesto della sicurezza dei segreti Kubernetes: i Secrets nativi sono codificati in base64, non crittografati. Gli ambienti di produzione richiedono gestori di segreti esterni come HashiCorp Vault o AWS Secrets Manager, sincronizzati tramite External Secrets Operator (ESO). Questa separazione garantisce che i segreti non esistano mai nei repository Git. ## Perché i Secrets Nativi di Kubernetes Sono Insufficienti La risorsa Secret integrata memorizza i dati in etcd con codifica base64. Questa codifica è reversibile con un singolo comando: ```bash # decoding-secret.sh # Decode any Kubernetes secret value instantly kubectl get secret db-credentials -o jsonpath='{.data.password}' | base64 -d ``` Base64 non è crittografia. Chiunque abbia accesso al cluster può leggere i valori dei segreti. La [documentazione Kubernetes](https://kubernetes.io/docs/concepts/configuration/secret/) avverte esplicitamente che i Secrets "non sono crittografati per impostazione predefinita" e raccomanda di abilitare la crittografia a riposo. Tre limitazioni principali influenzano i deployment in produzione: 1. **Nessuna traccia di audit**: I Secrets nativi non forniscono log di chi ha accesso a quale valore e quando 2. **Nessun meccanismo di rotazione**: Cambiare un segreto richiede intervento manuale e riavvio dei pod 3. **Incompatibilità GitOps**: Memorizzare segreti crittografati in Git espone comunque il problema della gestione delle chiavi di crittografia ## Architettura dell'External Secrets Operator L'External Secrets Operator (ESO) collega Kubernetes con sistemi esterni di gestione dei segreti. Rilasciato come progetto CNCF Sandbox nel 2023 e raggiungendo la versione 0.10 nel 2026, ESO supporta AWS Secrets Manager, HashiCorp Vault, Google Secret Manager, Azure Key Vault e altri 15 backend. L'architettura coinvolge tre risorse personalizzate: ```yaml # secret-store.yaml # ClusterSecretStore defines the connection to Vault apiVersion: external-secrets.io/v1beta1 kind: ClusterSecretStore metadata: name: vault-backend spec: provider: vault: server: "https://vault.internal:8200" path: "secret" version: "v2" auth: kubernetes: mountPath: "kubernetes" role: "external-secrets" serviceAccountRef: name: "external-secrets" namespace: "external-secrets" ``` Questo ClusterSecretStore configura ESO per autenticarsi con Vault utilizzando i token del service account Kubernetes. Il metodo di autenticazione `kubernetes` valida il JWT del service account contro l'API TokenReview del cluster. ```yaml # external-secret.yaml # ExternalSecret fetches and syncs the actual secret data apiVersion: external-secrets.io/v1beta1 kind: ExternalSecret metadata: name: database-credentials namespace: production spec: refreshInterval: 1h secretStoreRef: name: vault-backend kind: ClusterSecretStore target: name: db-secret creationPolicy: Owner data: - secretKey: username remoteRef: key: secret/data/production/database property: username - secretKey: password remoteRef: key: secret/data/production/database property: password ``` ESO interroga Vault ogni ora (`refreshInterval: 1h`) e aggiorna automaticamente il Secret Kubernetes. La `creationPolicy: Owner` garantisce che il Secret venga eliminato quando l'ExternalSecret viene rimosso. ## Pattern di Integrazione HashiCorp Vault Vault fornisce segreti dinamici, rotazione automatica e logging di audit completo. Il metodo di autenticazione Kubernetes, documentato nella [documentazione Vault Kubernetes Auth](https://developer.hashicorp.com/vault/docs/auth/kubernetes), permette ai pod di autenticarsi senza distribuire credenziali a lunga durata. La configurazione dell'autenticazione Vault richiede tre passaggi: ```bash # vault-k8s-auth.sh # Enable Kubernetes auth method in Vault vault auth enable kubernetes # Configure Vault to validate tokens against the Kubernetes API vault write auth/kubernetes/config \ kubernetes_host="https://kubernetes.default.svc:443" \ kubernetes_ca_cert=@/var/run/secrets/kubernetes.io/serviceaccount/ca.crt # Create a role that binds service accounts to policies vault write auth/kubernetes/role/external-secrets \ bound_service_account_names=external-secrets \ bound_service_account_namespaces=external-secrets \ policies=readonly-secrets \ ttl=1h ``` Questa configurazione lega il service account `external-secrets` a una policy Vault. Il TTL limita la validità del token, forzando la ri-autenticazione e riducendo il raggio d'impatto dei token compromessi. Per i deployment in produzione, la policy dovrebbe seguire i principi del privilegio minimo: ```hcl # readonly-secrets.hcl # Vault policy granting read-only access to specific paths path "secret/data/production/*" { capabilities = ["read"] } path "secret/metadata/production/*" { capabilities = ["list"] } ``` Questa policy concede accesso in lettura solo al percorso dei segreti di produzione. I team che gestiscono ambienti diversi ricevono policy separate con restrizioni di percorso corrispondenti. ## Rotazione dei Segreti Senza Downtime La rotazione automatica impedisce ai segreti di diventare vettori di attacco obsoleti. ESO gestisce il lato Kubernetes, ma l'applicazione deve ricaricare i segreti senza riavviarsi. Esistono due approcci per la rotazione a zero downtime: **Segreti montati come volume con file watching:** ```yaml # deployment-volume-secrets.yaml # Mount secrets as files that update automatically apiVersion: apps/v1 kind: Deployment metadata: name: api-server spec: template: spec: containers: - name: api image: api:v2.1.0 volumeMounts: - name: secrets mountPath: /etc/secrets readOnly: true volumes: - name: secrets secret: secretName: db-secret ``` Kubernetes aggiorna i file dei segreti montati entro il periodo di sincronizzazione del kubelet (default 1 minuto). L'applicazione legge le credenziali da `/etc/secrets/password` ad ogni connessione al database, acquisendo i nuovi valori senza riavvio. **Reloader per segreti come variabili d'ambiente:** Le applicazioni che usano variabili d'ambiente richiedono il riavvio dei pod. [Stakater Reloader](https://github.com/stakater/Reloader) automatizza questo processo: ```yaml # deployment-with-reloader.yaml # Annotation triggers rolling restart when secret changes apiVersion: apps/v1 kind: Deployment metadata: name: api-server annotations: reloader.stakater.com/auto: "true" spec: template: spec: containers: - name: api envFrom: - secretRef: name: db-secret ``` Reloader monitora gli aggiornamenti dei Secret ed esegue rolling restart, mantenendo la disponibilità durante la rotazione. ## Domande da Colloquio sui Secrets Kubernetes I colloqui DevOps testano costantemente la comprensione della gestione dei segreti. Queste domande appaiono a tutti i livelli, da junior a senior: **D: Quale codifica usano i Secrets Kubernetes e perché è insufficiente per la sicurezza?** I Secrets usano codifica base64, che è una trasformazione reversibile, non crittografia. Qualsiasi utente con permessi `get` sui Secrets può decodificare i valori. La sicurezza richiede crittografia a riposo (abilitando la crittografia etcd) e la restrizione dei permessi RBAC. Per concetti Kubernetes più approfonditi, consultare i [fondamenti di Kubernetes per colloqui](/technologies/devops/interview-questions/kubernetes-basics). **D: Come impedire ai segreti di apparire nei repository Git quando si usa GitOps?** External Secrets Operator memorizza solo i riferimenti ai segreti in Git, non i valori stessi. Il manifest ExternalSecret contiene il percorso al segreto in Vault o AWS Secrets Manager, mentre il segreto effettivo non tocca mai il repository. Sealed Secrets di Bitnami offre un approccio alternativo usando crittografia asimmetrica. **D: Spiegare la differenza tra SecretStore e ClusterSecretStore.** SecretStore ha scope di namespace: gli ExternalSecrets nello stesso namespace possono riferirsi ad esso. ClusterSecretStore ha scope di cluster: qualsiasi namespace può riferirsi ad esso. Usare ClusterSecretStore quando più team condividono una singola istanza Vault, e SecretStore quando ogni namespace ha backend di segreti isolati. **D: Un pod non può accedere ai suoi segreti dopo il deployment. Come si risolve il problema?** Iniziare con lo stato dell'ExternalSecret: ```bash # troubleshoot-secrets.sh # Check ExternalSecret sync status and conditions kubectl get externalsecret database-credentials -o yaml # Verify the Secret was created kubectl get secret db-secret -o yaml # Check ESO controller logs for auth errors kubectl logs -n external-secrets deployment/external-secrets ``` I fallimenti comuni includono token Vault scaduti, percorsi dei segreti errati e configurazioni RBAC errate nel ClusterSecretStore. **D: Come si gestisce la rotazione dei segreti per le credenziali del database in produzione?** Il motore di segreti database di Vault genera credenziali dinamiche e di breve durata. Configurare ESO con un `refreshInterval` più breve del TTL delle credenziali. Per credenziali statiche che richiedono rotazione, usare l'API di rotazione di Vault combinata con Reloader per riavviare i pod dopo gli aggiornamenti. L'applicazione dovrebbe gestire elegantemente i fallimenti di connessione durante la finestra di rotazione. ## AWS Secrets Manager con ESO L'integrazione con AWS Secrets Manager richiede IAM roles for service accounts (IRSA). Questo pattern elimina completamente le credenziali statiche: ```yaml # aws-secret-store.yaml # ClusterSecretStore for AWS Secrets Manager with IRSA apiVersion: external-secrets.io/v1beta1 kind: ClusterSecretStore metadata: name: aws-secrets spec: provider: aws: service: SecretsManager region: eu-west-1 auth: jwt: serviceAccountRef: name: external-secrets-sa namespace: external-secrets ``` L'annotazione del service account si collega al ruolo IAM: ```yaml # service-account-irsa.yaml # Service account with IAM role annotation apiVersion: v1 kind: ServiceAccount metadata: name: external-secrets-sa namespace: external-secrets annotations: eks.amazonaws.com/role-arn: arn:aws:iam::123456789:role/external-secrets ``` AWS ruota automaticamente i segreti creati tramite Secrets Manager con una funzione Lambda. Combinato con l'intervallo di refresh di ESO, i segreti si propagano a Kubernetes entro il periodo di polling configurato. ## Sincronizzazione dei Segreti Multi-Cluster Le organizzazioni che gestiscono più cluster necessitano di distribuzione coerente dei segreti. Due pattern affrontano questo requisito: **Hub-and-spoke con ClusterSecretStore:** Tutti i cluster si connettono a un'istanza Vault centrale. L'installazione ESO di ogni cluster fa riferimento agli stessi segreti, e Vault gestisce il controllo degli accessi attraverso policy basate sui namespace. **Replica con Vault Enterprise:** Vault Enterprise supporta la replica delle performance tra regioni. Ogni cluster si connette alla sua replica Vault locale, riducendo la latenza mantenendo la consistenza. La [documentazione sulla replica Vault](https://developer.hashicorp.com/vault/docs/enterprise/replication) copre le modalità di disaster recovery e replica delle performance. Per i team che usano ArgoCD, l'articolo sui [pattern di deployment GitOps](/blog/devops/argocd-gitops-kubernetes-continuous-deployment-interview-questions) copre gli ApplicationSets che deployano ExternalSecrets su più cluster. ## Hardening RBAC per l'Accesso ai Segreti I ruoli cluster predefiniti concedono accesso eccessivo ai segreti. Rafforzare RBAC creando ruoli minimi: ```yaml # restricted-role.yaml # Role allowing secret access only in specific namespace apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: secret-reader namespace: production rules: - apiGroups: [""] resources: ["secrets"] verbs: ["get"] resourceNames: ["db-secret", "api-key"] ``` Il campo `resourceNames` restringe l'accesso ai segreti elencati esplicitamente. Senza questo campo, il ruolo concede accesso a tutti i segreti nel namespace. L'audit logging cattura i tentativi di accesso ai segreti: ```yaml # audit-policy.yaml # Kubernetes audit policy for secret operations apiVersion: audit.k8s.io/v1 kind: Policy rules: - level: RequestResponse resources: - group: "" resources: ["secrets"] verbs: ["get", "list", "watch"] ``` Questa policy registra la richiesta e la risposta complete per le operazioni sui segreti, permettendo ai team di sicurezza di rilevare pattern di accesso non autorizzati. ## Checklist di Produzione per i Secrets Kubernetes - Abilitare la crittografia etcd a riposo usando la risorsa API `EncryptionConfiguration` - Deployare External Secrets Operator v0.10+ con ClusterSecretStore che punta a Vault o al cloud provider - Configurare `refreshInterval` sotto il TTL delle credenziali per assicurare che i segreti si aggiornino prima della scadenza - Usare IRSA (AWS), Workload Identity (GCP), o Kubernetes auth (Vault) invece di credenziali statiche - Restringere RBAC con `resourceNames` per limitare l'accesso ai segreti a specifici segreti nominati - Abilitare il logging di audit Kubernetes per le operazioni sui segreti con livello RequestResponse - Deployare Reloader per applicazioni che usano variabili d'ambiente per gestire gli aggiornamenti dei segreti - Testare la rotazione dei segreti in staging prima del deployment in produzione - Documentare le procedure di recovery per interruzioni del backend dei segreti che influenzano lo scheduling dei pod --- Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack. HTML version of this page: https://sharpskill.dev/it/blog/devops/kubernetes-secrets-management-2026-external-secrets-vault-interview