coulomb/the-custodian
4
0
Fork 0
Code Issues 1 Pull requests Projects Releases Packages Wiki Activity Actions

Record target-revenue adoption, the ESO auth runbook, and the last-applied annotation exposure.
All checks were successful
CI Smoke / host-smoke (push) Successful in 1s
Details
CI Smoke / container-smoke (push) Successful in 2s
Details

Browse source 
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
codex 2026-09-21 19:22:36 +02:00
parent e1ac9c6016
commit c635b381ef
1 changed files with 12 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

12
docs/kubernetes-change-gate-decision.md
View file

@ -197,3 +197,15 @@ All of the following were done with the founder's go-ahead, in `ADMINISTER @ rea
**4. external-secrets Helm release.** It had been stuck in `pending-upgrade` (rev 7) since 2026-07-07. Rev 6 and rev 7 were identical in values and manifests, and live matched both exactly, so the upgrade had fully applied and only the status was stuck. It was fixed with `helm rollback external-secrets 6`: dry run first, the chart has no hooks, and the result is rev 8, deployed. All three pods kept their names and their 36-day age, so nothing restarted.
**Found and routed, not fixed:** two ClusterSecretStores have been failing since 2026-09-13 (`openbao-email-connect`) and 2026-09-19 (`openbao-activity-core`). Their static OpenBao tokens are rejected with 403 on `lookup-self`, so 5 of 37 ExternalSecrets are not syncing, including activity-core's offsite-backup credential. This is credential custody, so it was routed to railiance-platform, activity-core and email-connect. No token was read or minted.
## target-revenue adopted, and a credential-exposure finding, 2026-09-21
**RPF-WP-0044-T05, target-revenue.** Adopted with the founder's go-ahead.
- The server-side diff conflicted on `limits.cpu` (`1` vs `1000m`, the same quantity, owned by an old client-side apply). The client-side diff, which is what the apply strategy uses, was rc=0.
- A manual sync with the apply strategy and prune off succeeded, so **0 hook Jobs ran** against the production database.
- The pod is unchanged, CNPG is healthy, and `/healthz` returns 200.
- Automated sync waits on target-revenue confirming its two Sync-hook Jobs are safe to re-run.
**RPF-WP-0045.** The runbook for moving openbao-activity-core and openbao-email-connect to OpenBao Kubernetes auth, as the three recovered stores already use, is written. Nothing is applied. One step needs the OpenBao admin credential and is the founder's to run.
**Credential exposure (routed to railiance-platform).** Secrets created with `kubectl apply` carry their full data in the `kubectl.kubernetes.io/last-applied-configuration` annotation, so a *metadata-only* read prints the secret. This was observed on the two dead ESO tokens. It is suspected, not verified, on five live `*-eso-token` Secrets. The custodian did not inspect them. Remediation — a check that prints no value, stripping the annotation, deciding on rotation, and fixing the creation paths — belongs to custody.