Ook interessant Op zoek naar AI-certificering? Bezoek ons zusje-platform Route-to-AI.com
⏱ 7 min. lezen Sealed Secrets kubeseal installatie

Sealed Secrets: complete gids voor installatie en gebruik met kubeseal

Van installatie van de controller tot je eerste versleutelde geheim: een praktische, stap-voor-stap gids om Sealed Secrets in te zetten binnen een GitOps-workflow.

Vervolg op ons conceptartikel over Sealed Secrets: hier installeer je de controller en de kubeseal-CLI, en versleutel je je eerste geheim zodat het veilig in Git kan.

Stap 1: de controller installeren

Installatie met Helm
helm repo add sealed-secrets https://bitnami-labs.github.io/sealed-secrets
helm repo update

helm install sealed-secrets sealed-secrets/sealed-secrets 
  --namespace sealed-secrets 
  --create-namespace

Stap 2: de kubeseal-CLI installeren

kubeseal downloaden (Linux)
KUBESEAL_VERSION=0.27.1
wget "https://github.com/bitnami-labs/sealed-secrets/releases/download/v/kubeseal--linux-amd64.tar.gz"
tar -xvzf kubeseal--linux-amd64.tar.gz kubeseal
sudo install -m 755 kubeseal /usr/local/bin/kubeseal

Stap 3: een geheim versleutelen

Maak eerst een gewone Kubernetes Secret aan (nog niet toepassen op het cluster — dit is alleen als lokaal bestand):

geheim.yaml (lokaal, NIET committen)
apiVersion: v1
kind: Secret
metadata:
  name: database-wachtwoord
  namespace: productie-app
stringData:
  wachtwoord: SuperGeheim123

Versleutel dit bestand met kubeseal, gebruikmakend van de publieke sleutel van de controller:

Versleutelen naar een SealedSecret
kubeseal --format yaml < geheim.yaml > sealed-geheim.yaml

Het resulterende sealed-geheim.yaml is veilig om te committen naar Git — de inhoud is onleesbaar zonder de privésleutel die alleen in het cluster bestaat.

Stap 4: toepassen (handmatig of via GitOps)

Direct toepassen
kubectl apply -f sealed-geheim.yaml

Binnen een GitOps-workflow (Argo CD) commit je sealed-geheim.yaml gewoon naar je repository; de GitOps-operator past het toe zoals elk ander manifest, en de Sealed Secrets-controller in het cluster ontsleutelt het automatisch naar een gewone Secret.

De privésleutel back-uppen (kritiek!)

De sleutel exporteren voor back-up
kubectl get secret -n sealed-secrets 
  -l sealedsecrets.bitnami.com/sealed-secrets-key 
  -o yaml > sealed-secrets-key-backup.yaml
Waarschuwing: Bewaar dit back-upbestand net zo zorgvuldig als je meest gevoelige productiegeheim — verlies je deze sleutel (bijvoorbeeld bij het herinstalleren van een cluster zonder back-up), dan zijn alle bestaande SealedSecrets voorgoed onleesbaar. Zet het bestand zelf nooit in Git.

Namespace-brede versus clusterbrede scope

Standaard is een SealedSecret gebonden aan zowel de naam als de namespace waarvoor hij versleuteld is — kopieer je het YAML-bestand naar een andere namespace, dan werkt het niet. Voor herbruikbare secrets over meerdere namespaces gebruik je een annotatie:

Namespace-onafhankelijk maken
kubeseal --scope namespace-wide --format yaml < geheim.yaml > sealed-geheim.yaml

Veelgestelde vragen

Kan ik een SealedSecret weer terugzetten naar een leesbaar geheim buiten het cluster?

Nee — dat is precies het punt. Alleen de controller met de privésleutel kan ontsleutelen, en die sleutel verlaat het cluster nooit (behalve in je eigen, zorgvuldig beveiligde back-up).

Wat gebeurt er bij sleutelrotatie?

De controller genereert periodiek een nieuwe sleutel (standaard elke 30 dagen) maar bewaart oudere sleutels om bestaande SealedSecrets te kunnen blijven ontsleutelen. Nieuwe versleutelingen gebruiken automatisch de nieuwste sleutel.