coulomb/railiance-platform
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Document recovered ESO lanes and recognize explicit invalid-token responses
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
Details
CI Smoke / container-smoke (push) Successful in 1s
Details

Browse source 
Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a06ecb-456a-71c2-b41e-0755d336e883
This commit is contained in:
codex 2026-09-05 18:51:40 +02:00
parent 153223983f
commit 3759850cc4
6 changed files with 78 additions and 8 deletions
Download patch file Download diff file Expand all files Collapse all files

48
docs/eso-auth-recovery.md Normal file
View file

@ -0,0 +1,48 @@
# Three-lane ESO authentication recovery
RPF-WP-0037 repairs Forgejo SMTP, reuse-surface and target-revenue delivery.
All three consumers were active; their old static-token stores failed with 403.
Before resync, attended comparison proved existing OpenBao values identical to
deployed workload Secrets. This is an authentication migration, not an
application credential rotation.
| Store | Dedicated service account | OpenBao role |
| --- | --- | --- |
| openbao-forgejo | forgejo/forgejo-mailer-eso | forgejo-mailer-eso |
| openbao-reuse | reuse/reuse-surface-eso | reuse-surface-runtime-eso |
| openbao-target-revenue | target-revenue/target-revenue-eso | target-revenue-runtime-eso |
Source: `openbao/eso-auth-recovery/lanes.json`, `serviceaccounts.yaml`, the three
`*-eso.hcl` policies and existing ClusterSecretStore manifests under
`argocd/platform-addons/openbao-secretstore/`. These stores remain outside the
coulombcore kustomization. No broad RBAC is added; ESO's existing TokenRequest
authority is used with exact namespace/SA/audience OpenBao bindings.
Roles use audience `openbao`, 15-minute TTL/max/explicit max, no default policy,
and exact data reads. ESO also needs token lookup-self and revoke-self. No KV
metadata/list/write, token creation or sibling access is granted. Existing
caller-facing policies and application credentials remain in place.
Commit and push source before running the attended command:
```sh
warden access openbao-platform-admin-login --exec -- \
/usr/bin/python3 /home/worsch/railiance-platform/scripts/repair_eso_kubernetes_auth.py \
apply --kubeconfig /home/worsch/.kube/config-railiance01 \
--receipt /tmp/eso-auth-apply.json --confirm 'APPLY RPF-WP-0037'
```
The helper pins cluster identity, compares custody before mutation, refuses
scope drift, validates bounded positive and negative authentication, and patches
only each store's auth using a JSON Patch test of the observed spec. `verify`
forces another refresh and requires its timestamp to advance. `cleanup` performs
the same verification, proves the old token is unreferenced, revokes it or proves
invalidity, and deletes only its obsolete Secret with UID/resourceVersion
preconditions. All receipts are exclusively created mode 0600; values and tokens
stay in captured memory. Choose a fresh receipt path for each invocation.
On failure, inspect only the receipt and safe metadata. Completed store repairs
can be verified independently; retry apply only against matching reviewed source.
Do not roll back to rejected static credentials. Correct forward to the accepted
Kubernetes role; application Secrets are retained and no workload restart is
part of this procedure. Custody disagreement needs its own owner-led resolution.