3759850cc4
Assistant: codex Assistant-Model: gpt-6-astra Assistant-Session: 01a06ecb-456a-71c2-b41e-0755d336e883
48 lines
2.7 KiB
Markdown
48 lines
2.7 KiB
Markdown
# 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.
|