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
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_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):
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:
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)
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!)
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:
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.