Kubernetes Secrets Management 2026: External Secrets, Vault e Domande da Colloquio

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.

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:

# 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 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:

# 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.

# 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, permette ai pod di autenticarsi senza distribuire credenziali a lunga durata.

La configurazione dell'autenticazione Vault richiede tre passaggi:

# 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:

# 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:

# 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 automatizza questo processo:

# 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.

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:

# 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:

# 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:

# 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 copre le modalità di disaster recovery e replica delle performance.

Per i team che usano ArgoCD, l'articolo sui pattern di deployment GitOps 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:

# 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:

# 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