railiance-platform/docs/eso-auth-recovery.md

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:

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.