Kubernetes Secrets Management 2026: External Secrets, Vault en Sollicitatievragen

Kubernetes secrets management blijft een van de meest kritieke beveiligingsuitdagingen in container-orchestratie. Native Kubernetes Secrets slaan gevoelige gegevens op als base64-gecodeerde waarden, wat standaard geen versleuteling in rust biedt en beveiligingsrisico's creëert die interviewers vaak onderzoeken tijdens DevOps-wervingsprocessen.

Waarom Native Kubernetes Secrets Tekortschieten

De ingebouwde Secret-resource slaat gegevens op in etcd met base64-codering. Deze codering is omkeerbaar met één enkel commando:

# decoding-secret.sh
# Decode any Kubernetes secret value instantly
kubectl get secret db-credentials -o jsonpath='{.data.password}' | base64 -d

Base64 is geen versleuteling. Iedereen met clustertoegang kan secret-waarden lezen. De Kubernetes-documentatie waarschuwt expliciet dat Secrets "standaard niet versleuteld zijn" en beveelt aan om versleuteling in rust in te schakelen.

Drie primaire beperkingen beïnvloeden productie-deployments:

1. Geen audit trail: Native Secrets bieden geen logging van wie welke waarde wanneer heeft benaderd
2. Geen rotatiemechanisme: Het wijzigen van een secret vereist handmatige interventie en pod-herstarts
3. GitOps-incompatibiliteit: Het opslaan van versleutelde secrets in Git legt nog steeds het sleutelbeheerprobleem bloot

External Secrets Operator Architectuur

External Secrets Operator (ESO) verbindt Kubernetes met externe secret management-systemen. Uitgebracht als CNCF Sandbox-project in 2023 en versie 0.10 bereikend in 2026, ondersteunt ESO AWS Secrets Manager, HashiCorp Vault, Google Secret Manager, Azure Key Vault en 15 andere backends.

De architectuur omvat drie custom resources:

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

Deze ClusterSecretStore configureert ESO om te authenticeren bij Vault met behulp van Kubernetes service account tokens. De kubernetes authenticatiemethode valideert de service account JWT tegen de TokenReview API van het 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 pollt Vault elk uur (refreshInterval: 1h) en werkt de Kubernetes Secret automatisch bij. De creationPolicy: Owner zorgt ervoor dat de Secret wordt verwijderd wanneer de ExternalSecret wordt verwijderd.

HashiCorp Vault Integratiepatronen

Vault biedt dynamische secrets, automatische rotatie en uitgebreide audit logging. De Kubernetes authenticatiemethode, gedocumenteerd in de Vault Kubernetes Auth-documentatie, stelt pods in staat om te authenticeren zonder langlevende credentials te distribueren.

Het opzetten van Vault-authenticatie vereist drie stappen:

# 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

Deze configuratie bindt de external-secrets service account aan een Vault-policy. De TTL beperkt de tokengeldigheid, dwingt herauthenticatie af en verkleint de impact radius van gecompromitteerde tokens.

Voor productie-deployments moet de policy het principe van minimale rechten volgen:

# readonly-secrets.hcl
# Vault policy granting read-only access to specific paths
path "secret/data/production/*" {
  capabilities = ["read"]
}

path "secret/metadata/production/*" {
  capabilities = ["list"]
}

Deze policy verleent alleen leestoegang tot het productie-secrets-pad. Teams die verschillende omgevingen beheren, ontvangen aparte policies met overeenkomstige padbeperkingen.

Secret-rotatie Zonder Downtime

Automatische rotatie voorkomt dat secrets verouderde aanvalsvectoren worden. ESO handelt de Kubernetes-kant af, maar de applicatie moet secrets herladen zonder opnieuw te starten.

Twee benaderingen bestaan voor zero-downtime rotatie:

Volume-gemounte secrets met 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 werkt gemounte secret-bestanden bij binnen de kubelet-synchronisatieperiode (standaard 1 minuut). De applicatie leest credentials uit /etc/secrets/password bij elke databaseverbinding en pikt nieuwe waarden op zonder herstart.

Reloader voor omgevingsvariabelen-secrets:

Applicaties die omgevingsvariabelen gebruiken, vereisen pod-herstarts. Stakater Reloader automatiseert dit:

# 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 bewaakt Secret-updates en voert rolling restarts uit, waarbij de beschikbaarheid behouden blijft tijdens de rotatie.

Sollicitatievragen over Kubernetes Secrets

DevOps-sollicitaties testen consequent het begrip van secrets management. Deze vragen verschijnen op alle niveaus, van junior tot senior:

V: Welke codering gebruiken Kubernetes Secrets en waarom is dit onvoldoende voor beveiliging?

Secrets gebruiken base64-codering, wat een omkeerbare transformatie is, geen versleuteling. Elke gebruiker met get-rechten op Secrets kan waarden decoderen. Beveiliging vereist versleuteling in rust (etcd-versleuteling inschakelen) en het beperken van RBAC-rechten. Voor diepgaandere Kubernetes-concepten, raadpleeg de Kubernetes sollicitatie-fundamenten.

V: Hoe zou men voorkomen dat secrets in Git-repositories verschijnen bij gebruik van GitOps?

External Secrets Operator slaat alleen referenties naar secrets op in Git, niet de waarden zelf. Het ExternalSecret-manifest bevat het pad naar de secret in Vault of AWS Secrets Manager, terwijl de daadwerkelijke secret nooit de repository raakt. Sealed Secrets van Bitnami biedt een alternatieve aanpak met asymmetrische versleuteling.

V: Leg het verschil uit tussen SecretStore en ClusterSecretStore.

SecretStore heeft namespace-scope: ExternalSecrets in dezelfde namespace kunnen ernaar verwijzen. ClusterSecretStore heeft cluster-scope: elke namespace kan ernaar verwijzen. Gebruik ClusterSecretStore wanneer meerdere teams een enkele Vault-instantie delen, en SecretStore wanneer elke namespace geïsoleerde secret-backends heeft.

V: Een pod kan na deployment geen toegang krijgen tot zijn secrets. Hoe zou men dit troubleshooten?

Begin met de ExternalSecret-status:

# 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

Veelvoorkomende fouten zijn verlopen Vault-tokens, onjuiste secret-paden en RBAC-misconfiguraties in de ClusterSecretStore.

V: Hoe wordt secret-rotatie voor database-credentials in productie afgehandeld?

Vaults database secrets engine genereert dynamische, kortlevende credentials. Configureer ESO met een refreshInterval korter dan de credential-TTL. Voor statische credentials die rotatie vereisen, gebruik Vaults rotation API gecombineerd met Reloader om pods opnieuw te starten na updates. De applicatie moet verbindingsfouten elegant afhandelen tijdens het rotatievenster.

AWS Secrets Manager met ESO

AWS Secrets Manager-integratie vereist IAM roles for service accounts (IRSA). Dit patroon elimineert statische credentials volledig:

# 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

De service account-annotatie linkt naar de IAM-rol:

# 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 roteert automatisch secrets die zijn aangemaakt via Secrets Manager met een Lambda-functie. Gecombineerd met ESO's refresh-interval propageren secrets naar Kubernetes binnen de geconfigureerde polling-periode.

Multi-Cluster Secret-synchronisatie

Organisaties die meerdere clusters draaien, hebben consistente secret-distributie nodig. Twee patronen adresseren deze vereiste:

Hub-and-spoke met ClusterSecretStore:

Alle clusters verbinden met een centrale Vault-instantie. De ESO-installatie van elk cluster verwijst naar dezelfde secrets, en Vault handelt toegangscontrole af via namespace-gebaseerde policies.

Replicatie met Vault Enterprise:

Vault Enterprise ondersteunt performance-replicatie over regio's. Elk cluster verbindt met zijn lokale Vault-replica, wat latentie vermindert terwijl consistentie behouden blijft. De Vault-replicatiedocumentatie behandelt disaster recovery en performance-replicatiemodi.

Voor teams die ArgoCD gebruiken, behandelt het artikel over GitOps deployment-patronen ApplicationSets die ExternalSecrets over meerdere clusters deployen.

RBAC-hardening voor Secrets-toegang

Standaard cluster-rollen verlenen overmatige secret-toegang. Versterk RBAC door minimale rollen te creëren:

# 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"]

Het resourceNames-veld beperkt toegang tot expliciet genoemde secrets. Zonder dit veld verleent de rol toegang tot alle secrets in de namespace.

Audit logging vangt secret-toegangspogingen:

# 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"]

Deze policy logt het volledige verzoek en antwoord voor secret-operaties, waardoor beveiligingsteams ongeautoriseerde toegangspatronen kunnen detecteren.

Productie-checklist voor Kubernetes Secrets

• Schakel etcd-versleuteling in rust in met de EncryptionConfiguration API-resource
• Deploy External Secrets Operator v0.10+ met ClusterSecretStore die naar Vault of cloud provider wijst
• Configureer refreshInterval onder de credential-TTL om te zorgen dat secrets vóór expiratie worden bijgewerkt
• Gebruik IRSA (AWS), Workload Identity (GCP), of Kubernetes auth (Vault) in plaats van statische credentials
• Beperk RBAC met resourceNames om secret-toegang te limiteren tot specifiek genoemde secrets
• Schakel Kubernetes audit logging in voor secret-operaties met RequestResponse-niveau
• Deploy Reloader voor applicaties die omgevingsvariabelen gebruiken om secret-updates af te handelen
• Test secret-rotatie in staging vóór productie-deployment
• Documenteer herstelprocedures voor secret-backend-storingen die pod-scheduling beïnvloeden