Kubernetes Secrets en externe secretmanagers gebruiken

In Kubernetes-configuraties horen wachtwoorden, API-tokens, private sleutels en andere gevoelige waarden horen niet thuis in containerimages, ConfigMaps of leesbare configuratiebestanden. Gebruik hiervoor een Secret in Kubernetes of haal de waarden op uit een externe secretmanager.

In deze handleiding maak je een Kubernetes Secret zonder de waarden in een YAML-bestand of je shellgeschiedenis te zetten. Je koppelt de Secret als bestanden aan een Pod, gebruikt zo nodig een veilige verwijzing als omgevingsvariabele en leert hoe je een externe secretmanager met External Secrets Operator koppelt.

Een opslagmethode kiezen

Kies de opslagmethode op basis van de inhoud en de manier waarop je de waarden beheert:

• ConfigMap: gebruik deze alleen voor niet-gevoelige configuratie, zoals een hostnaam, poortnummer of feature flag.
• Kubernetes Secret: gebruik deze voor gevoelige waarden die je binnen één cluster beheert. De waarden staan in de Kubernetes API en kunnen als bestanden of via een verwijzing als omgevingsvariabelen beschikbaar worden gemaakt.
• Externe secretmanager: gebruik deze wanneer je Secrets centraal wilt beheren, roteren en controleren, bijvoorbeeld voor meerdere clusters. Een operator kan de waarden automatisch met Kubernetes synchroniseren.

Sla nooit een echt wachtwoord, token of een private sleutel op onder data of stringData in een YAML-bestand dat je deelt of aan Git toevoegt. Ook een base64-gecodeerde waarde is eenvoudig terug te zetten naar de oorspronkelijke waarde.

Benodigdheden

Voor deze handleiding heb je het volgende nodig:

• Een werkend Kubernetes-cluster.
• kubectl, geconfigureerd voor het cluster.
• Optioneel: Helm 3 wanneer je External Secrets Operator installeert.
• Optioneel: een externe secretmanager met een opgeslagen Secret en een ondersteunde authenticatiemethode.

Een Kubernetes Secret maken

Stap 1

Maak een afzonderlijke namespace voor de voorbeelden in deze handleiding:

kubectl create namespace secret-demo

Stap 2

Beperk de toegangsrechten voor nieuwe lokale bestanden tot je eigen gebruiker en open twee bestanden voor de gebruikersnaam en het wachtwoord.

Windows en MacOS: gebruik e.v.t. Notepad of TextEdit om de bestanden genaamd db-username en db-password aan te maken in de directory waar je kubectl uitvoert.

umask 077
nano db-username
nano db-password

Vul in elk bestand alleen de bijbehorende waarde in; in dit voorbeeld zijn dat respectievelijk de gebruikersnaam en wachtwoord van een database. Sla de wijzigingen op en sluit nano met ctrl + x > y > enter.

Maak vervolgens de Secret en verwijder de lokale bestanden direct daarna:

kubectl create secret generic database-credentials --namespace secret-demo --from-file=username=db-username --from-file=password=db-password
rm db-username db-password

De gebruikte argumenten hebben de volgende functie:

• generic: maakt een Secret van het type Opaque voor algemene gevoelige gegevens.
• --namespace secret-demo: maakt de Secret in de namespace secret-demo.
• --from-file=username=db-username: slaat de inhoud van db-username op onder de key username. Het tweede argument doet hetzelfde voor password.

Stap 3

Controleer of de Secret bestaat zonder de waarden op te vragen:

kubectl get secret database-credentials --namespace secret-demo
kubectl describe secret database-credentials --namespace secret-demo

De uitvoer van describe toont de namen en groottes van de keys, maar niet de inhoud. Gebruik geen uitvoerformaat zoals -o yaml in logs of gedeelde terminalsessies: de getoonde base64-waarden zijn niet versleuteld.

Stap 4

Open het bestand secret-reader.yaml:

nano secret-reader.yaml

Voeg de volgende configuratie toe. De Secret wordt alleen-lezen als bestanden aan de container gekoppeld:

apiVersion: v1
kind: Pod
metadata:
  name: secret-reader
  namespace: secret-demo
spec:
  containers:
    - name: app
      image: busybox:1.37.0
      command:
        - /bin/sh
        - -c
        - sleep 3600
      volumeMounts:
        - name: database-credentials
          mountPath: /run/secrets/database
          readOnly: true
  volumes:
    - name: database-credentials
      secret:
        secretName: database-credentials
        defaultMode: 0400

Sla de wijzigingen op en sluit nano. Maak daarna de Pod:

kubectl apply -f secret-reader.yaml

Elke key in de Secret wordt een bestand onder /run/secrets/database. Met readOnly: true kan de container de bestanden niet wijzigen. defaultMode: 0400 geeft standaard alleen leesrechten aan de eigenaar van de bestanden.

Stap 5

Wacht totdat de Pod gereed is en controleer daarna of beide bestanden leesbaar zijn. De opdracht toont niet de inhoud:

kubectl wait --for=condition=Ready pod/secret-reader --namespace secret-demo --timeout=60s
kubectl exec --namespace secret-demo secret-reader -- sh -c 'test -r /run/secrets/database/username && test -r /run/secrets/database/password && echo "Secret-bestanden zijn beschikbaar."'

Je ziet de melding ‘Secret-bestanden zijn beschikbaar.’ wanneer de koppeling werkt.

Een Secret als omgevingsvariabele gebruiken

Gebruik bij voorkeur gekoppelde bestanden wanneer de applicatie dit ondersteunt. Een omgevingsvariabele kan zichtbaar worden in diagnostische uitvoer, crashrapporten of een proces dat de omgeving uitleest. Bovendien ontvangt een bestaande container geen gewijzigde Secret-waarde via een omgevingsvariabele; je moet de Pod opnieuw starten.

Ondersteunt de applicatie alleen omgevingsvariabelen? Verwijs dan met secretKeyRef naar een Secret en plaats de gevoelige waarde nooit rechtstreeks onder value.

Open het bestand secret-env-reader.yaml:

nano secret-env-reader.yaml

Voeg de volgende configuratie toe:

apiVersion: v1
kind: Pod
metadata:
  name: secret-env-reader
  namespace: secret-demo
spec:
  containers:
    - name: app
      image: busybox:1.37.0
      command:
        - /bin/sh
        - -c
        - test -n "$DATABASE_PASSWORD" && echo 'Secret environment variable is available.'; sleep 3600
      env:
        - name: DATABASE_PASSWORD
          valueFrom:
            secretKeyRef:
              name: database-credentials
              key: password

Sla de wijzigingen op, sluit nano en maak de Pod:

kubectl apply -f secret-env-reader.yaml
kubectl logs secret-env-reader --namespace secret-demo

De Pod controleert alleen of de variabele bestaat en schrijft de gevoelige waarde niet naar de logs.

Een externe secretmanager koppelen

Met External Secrets Operator synchroniseer je waarden uit onder meer HashiCorp Vault, Azure Key Vault, Google Secret Manager en verschillende andere secretmanagers naar Kubernetes Secrets. De configuratie van de verbinding en authenticatie verschilt per provider.

Stap 1

Voeg de officiële Helm-repository toe en installeer External Secrets Operator:

helm repo add external-secrets https://charts.external-secrets.io
helm repo update
helm upgrade --install external-secrets external-secrets/external-secrets --namespace external-secrets --create-namespace --wait

De gebruikte optionele argumenten hebben de volgende functie:

• --install: installeert de release wanneer deze nog niet bestaat en werkt een bestaande release anders bij.
• --namespace external-secrets: gebruikt de namespace external-secrets voor de operator.
• --create-namespace: maakt de namespace automatisch wanneer deze nog niet bestaat.
• --wait: wacht totdat de geïnstalleerde resources gereed zijn of de Helm-timeout verloopt.

Controleer daarna de Pods van de operator:

kubectl get pods --namespace external-secrets

Stap 2

Maak in secret-demo een SecretStore voor jouw provider. Gebruik hiervoor de providerdocumentatie van External Secrets Operator. Gebruik waar mogelijk een workload identity, Kubernetes ServiceAccount of een andere kortlevende identiteit in plaats van een statisch beheertoken.

Controleer na het toepassen van de providerconfiguratie of de SecretStore gereed is:

kubectl get secretstore --namespace secret-demo
kubectl describe secretstore <secretstore-naam> --namespace secret-demo

Vervang <secretstore-naam> door de naam uit jouw SecretStore-configuratie. Ga pas verder wanneer de status aangeeft dat de verbinding gereed is.

Stap 3

Open het bestand database-external-secret.yaml:

nano database-external-secret.yaml

Voeg de volgende configuratie toe en vervang de placeholders door de namen uit je SecretStore en externe secretmanager:

apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata:
  name: database-credentials
  namespace: secret-demo
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: <secretstore-naam>
    kind: SecretStore
  target:
    name: database-credentials
    creationPolicy: Owner
  data:
    - secretKey: username
      remoteRef:
        key: <secretnaam-in-provider>
        property: username
    - secretKey: password
      remoteRef:
        key: <secretnaam-in-provider>
        property: password

De belangrijkste velden hebben de volgende functie:

• refreshInterval: 1h: controleert ieder uur of de externe waarde is gewijzigd.
• secretStoreRef: selecteert de namespaced SecretStore waarmee de operator verbinding maakt.
• target.name: bepaalt de naam van de Kubernetes Secret die de operator aanmaakt.
• remoteRef: koppelt een key en property uit de externe secretmanager aan een key in de Kubernetes Secret.

Sla de wijzigingen op, sluit nano en maak de ExternalSecret:

kubectl apply -f database-external-secret.yaml

Stap 4

Controleer de synchronisatie zonder de waarden op te vragen:

kubectl get externalsecret database-credentials --namespace secret-demo
kubectl get secret database-credentials --namespace secret-demo

De ExternalSecret moet de status ‘SecretSynced’ of ‘Ready’ tonen en de Kubernetes Secret database-credentials moet bestaan. Omdat de aangemaakte Secret dezelfde naam en keys gebruikt, kun je deze koppelen met dezelfde Pod-configuratie uit het eerdere voorbeeld.

Na een rotatie synchroniseert de operator de nieuwe waarde volgens refreshInterval. Een gekoppeld Secret-volume wordt daarna uiteindelijk bijgewerkt, maar de applicatie moet het bestand zelf opnieuw inlezen. Een omgevingsvariabele verandert pas nadat je de Pod opnieuw hebt gestart.

Toegang tot Secrets beperken

Houd bij het beheren van Secrets rekening met de volgende maatregelen:

• Geef gebruikers en ServiceAccounts volgens de Kubernetes-richtlijnen voor Secrets met RBAC alleen de minimaal benodigde rechten. Ook de rechten list en watch kunnen toegang geven tot Secret-inhoud.
• Geef alleen de containers die een Secret nodig hebben toegang tot het bijbehorende volume of de bijbehorende key.
• Behandel rechten om Pods, Deployments of vergelijkbare workloads te maken als een project met gevoelige rechten. Een gebruiker die een Pod mag maken, kan mogelijk Secrets uit dezelfde namespace koppelen.
• Schrijf Secret-waarden niet naar logs en toon ze niet in foutmeldingen of diagnostische opdrachten.
• Voeg bestanden met gevoelige waarden, Kubernetes Secret-manifests en lokale .env-bestanden niet toe aan Git.
• Roteer wachtwoorden, tokens en sleutels regelmatig en direct nadat je vermoedt dat een waarde is uitgelekt.

Secrets verwijderen

Secrets kun je verwijderen door de namespace te verwijderen. Verwijder External Secrets Operator alleen wanneer geen andere ExternalSecrets of SecretStores in het cluster ervan afhankelijk zijn. Een namespace verwijder je als volgt:

kubectl delete namespace secret-demo

Of bekijk welke secrets aanwezig zijn:

kubectl get secrets -n secret-demo

en verwijder ze vervolgens:

kubectl delete secret <secretname>

Je hebt gevoelige waarden veilig als Kubernetes Secret beschikbaar gemaakt en geleerd wanneer een externe secretmanager geschikt is. Door Secret-volumes, verwijzingen en minimale toegangsrechten te gebruiken, voorkom je dat wachtwoorden, tokens en sleutels in configuratiebestanden of logs terechtkomen.