Sealed Secrets Configuration Guide
Purpose: For platform engineers, operators, shows how to use and configure Sealed Secrets in cluster repositories that consume the openCenter base.
Use this guide when a cluster repo needs to manage encrypted secrets through the Sealed Secrets controller deployed from the base repo.
What the Base Deploys
The base service deploys:
-
Namespace/sealed-secrets -
HelmRelease/sealed-secrets -
base values from the service
helm-values/directory -
optional
Secret/sealed-secrets-values-override
The base does not create any SealedSecret application objects; those belong in the cluster repo.
Typical Workflow
-
Fetch the cluster’s sealing certificate.
-
Generate a normal Secret locally.
-
Seal it into a
SealedSecret. -
Commit the sealed manifest to the cluster repo.
Example:
kubeseal --fetch-cert \
--controller-name sealed-secrets \
--controller-namespace sealed-secrets > sealed-secrets.crt
Override Values Pattern
Use sealed-secrets-values-override only for controller-level changes such as resources or key renewal behavior.
Operational Guidance
-
Back up the controller keys if sealed secrets must survive cluster rebuilds.
-
Be explicit about namespace scope when sealing secrets.
-
Treat resealing as part of secret rotation or migration workflows.
Verification
kubectl get helmrelease -n sealed-secrets sealed-secrets
kubectl get pods -n sealed-secrets
kubectl get sealedsecrets -A
kubectl describe sealedsecret <name> -n <namespace>
Healthy signs:
-
controller Pod is
Running -
HelmRelease/sealed-secretsisReady=True -
SealedSecretresources reconcile into normal Kubernetes Secrets
Common Failure Modes
Cannot decrypt after cluster rebuild: - the controller key changed and old key material was not restored
SealedSecret never becomes a Secret: - verify controller name, namespace, and sealing scope
kubeseal --fetch-cert fails:
- verify service reachability and correct controller namespace/name