# 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

```text
.
├── .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.