Nik Afiq
f006090fea
Some checks failed
validate / lint (push) Failing after 1s
Not used enough to justify chasing the stale-NFS-handle issue on its photos-art mount. Removes manifests/media/immich.yaml (Namespace, PVCs, Deployments, Service, Certificate, IngressRoute), its secret script and sealed secret, immich.home.arpa from both Pi-hole values files, its Dashy dashboard tile, and all other repo references (READMEs, secrets-leak-scanner scope, regen-sealed-secret example, .env.example). Per explicit confirmation: this also means the live namespace's PVCs (immich-library 50Gi, immich-postgres-data 20Gi, immich-ml-cache 10Gi, all local-path with Delete reclaim policy) are intended to be deleted along with it -- any photos actually uploaded to Immich's own library are gone once the namespace is deleted, separately from the read-only NFS folders it browsed (untouched either way, those live independently on nik-debian). Git removal alone does not delete the live cluster resources -- the media Application has prune: false. Manual `kubectl delete namespace immich` still needed to actually free the namespace/PVCs/data. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
50 lines
2.4 KiB
Markdown
50 lines
2.4 KiB
Markdown
---
|
|
name: regen-sealed-secret
|
|
description: Regenerate a committed *-sealed.yaml SealedSecret from .env values. Use when rotating a secret or when a *-secret.sh script needs to be run to refresh sealed output.
|
|
disable-model-invocation: true
|
|
---
|
|
|
|
Regenerate the sealed secret for: $ARGUMENTS
|
|
|
|
This repo keeps sealed secrets and their source script side by side (e.g.
|
|
`manifests/home-services/discord-bot-secret.sh` →
|
|
`manifests/home-services/discord-bot-sealed.yaml`,
|
|
`manifests/home-services/ha-gateway-secret.sh` →
|
|
`manifests/home-services/ha-gateway-sealed.yaml`). The script is the source of
|
|
truth; the `*-sealed.yaml` file is generated output.
|
|
|
|
## Steps
|
|
|
|
1. Find the matching `*-secret.sh` script for the target secret (search
|
|
`manifests/**/*-secret.sh`). If none exists yet, model the new one on
|
|
`manifests/home-services/discord-bot-secret.sh`:
|
|
```bash
|
|
source "$(dirname "$0")/../../.env"
|
|
kubectl create secret generic <name> \
|
|
--namespace=<namespace> \
|
|
--from-literal=<KEY>="${ENV_VAR}" \
|
|
--dry-run=client -o yaml \
|
|
| kubeseal --controller-namespace=kube-system \
|
|
--controller-name=sealed-secrets-controller \
|
|
--format=yaml \
|
|
> "$(dirname "$0")/<name>-sealed.yaml"
|
|
```
|
|
2. Confirm the source value is up to date in `.env` (copy from
|
|
`.env.example` if the key is missing, then ask the user to fill it in —
|
|
never invent a secret value).
|
|
3. Confirm `kubeseal` can reach the cluster's controller:
|
|
`kubeseal --controller-namespace=kube-system --controller-name=sealed-secrets-controller --fetch-cert`
|
|
should succeed against the live cluster (`minisforum`, context `default`).
|
|
4. Run the script: `bash manifests/<area>/<name>-secret.sh`.
|
|
5. Diff the resulting `*-sealed.yaml` — it should be the only file that
|
|
changed, and it should NOT contain plaintext (sealed secrets are
|
|
ciphertext under `spec.encryptedData`, unlike the raw
|
|
`kubectl create secret ... -o yaml` output piped into it).
|
|
6. Commit only the regenerated `*-sealed.yaml`. Never commit the raw
|
|
`kubectl create secret --dry-run=client -o yaml` output or `.env` itself.
|
|
|
|
If the secret should instead be created directly in-cluster without being
|
|
committed (the runtime-script pattern, e.g. `authentik-secret.sh`), skip
|
|
`kubeseal` entirely and pipe straight to `kubectl apply -f -` — don't
|
|
sealed-secret something that was never meant to be committed.
|