sealed-secrets/README.md

sealed-secrets

GitOps source-of-truth repository for the cluster Sealed Secrets controller.

This repo follows the same dormant-bootstrap pattern as the other application repositories, but the runtime payload is a pinned upstream Helm chart instead of raw kustomize manifests. The controller is installed in kube-system with the name sealed-secrets-controller so kubeseal works with its default controller name assumptions.

Layout

.
├── .gitea/
│   └── workflows/validate.yaml
├── .gitignore
├── bootstrap/
│   ├── applicationset.yaml
│   └── config.yaml
├── manifest/
│   └── overlays/
│       └── production/
│           └── helm-values/
│               └── values.yaml
└── README.md

Bootstrap activation model

1. Prepare the repo on init.
2. Keep bootstrap/config.yaml set to enabled: false while validating.
3. Promote the repo to main.
4. Change bootstrap/config.yaml to enabled: true on main.
5. Let the bootstrap workflow apply bootstrap/applicationset.yaml.

Controller decisions

• Namespace: kube-system
• Helm chart: bitnami-labs/sealed-secrets
• Chart version pin: 2.18.5
• Controller name override: sealed-secrets-controller

The name override matters because the chart defaults to sealed-secrets, while kubeseal expects sealed-secrets-controller unless you pass explicit flags.

Secret migration workflow

1. Install kubeseal locally.
2. Fetch the controller cert: kubeseal --fetch-cert --controller-namespace kube-system > sealed-secrets.pem
3. Convert an existing Secret manifest: kubeseal --format yaml --cert sealed-secrets.pem < secret.yaml > sealed-secret.yaml
4. Commit the resulting SealedSecret manifest in the owning app repo.
5. Remove the old SOPS-backed secret generator entry only after the app is syncing from the new SealedSecret path.

Use the default strict scope unless a secret must survive renames inside the same namespace. Avoid cluster-wide scope unless there is a concrete need.