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

WP-0039-T03: record option (b) and add silent seeding script
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
Details
CI Smoke / container-smoke (push) Successful in 3s
Details
Build and Publish Container Image / build-and-push (push) Successful in 14s
Details

Browse source 
The founder chose to mint fresh tokens for both worker identities. Add the
reviewed, idempotent, silent script for the attended OpenBao admin lane, and
the cutover order that keeps the claim loop's gap to seconds.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 151606@bnt-lap001
Assistant-Session: 3c0a4ad5-bb8b-4bf7-b9f0-fa5f29204e48
This commit is contained in:
tegwick 2026-09-23 17:48:51 +02:00
parent b690ce03fa
commit a129249d25
2 changed files with 71 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

31
workplans/ACTIVITY-WP-0039-multi-worker-identity-and-token-custody.md
View file

@ -123,6 +123,24 @@ Founder-attended, through `warden access openbao-platform-admin-login --exec`
Done when both paths hold a value and no value has been printed or logged.
**Decision 2026-09-23 (founder): option (b).** Both tokens are minted fresh, so
the hand-generated claim-loop value is retired at cutover. The reviewed script
`scripts/wp0039-seed-worker-tokens.sh` does the minting. It runs silently, never
overwrites an existing path, and exits 0 when both paths are verified, 3 on an
unusable existing path, 4 on a write failure, and 5 on a verification failure.
It generates each value inside a pipe and sends it to `bao kv put ... token=-`
on stdin. The founder runs it in their own terminal:
```bash
BAO_ADDR=http://127.0.0.1:18200 VAULT_ADDR=http://127.0.0.1:18200 \
warden access openbao-platform-admin-login --exec -- \
sh scripts/wp0039-seed-worker-tokens.sh
```
Read warden's printed line rather than its exit code (orientation section 5).
Minting does not depend on T02, but ESO cannot read the paths until the policy
lands.
## Roll out and prove both identities
```task
@ -143,4 +161,17 @@ Prove four things:
- A metered token paired with the loop identity is rejected with HTTP 403.
- The previous hand-set Secret key is now owned by ESO.
Cutover order for option (b), which keeps the claim loop's gap to seconds.
The pods read `actcore-runtime-secret` only at start.
1. Apply `15-externalsecret-worker-tokens.yaml`, then force a refresh. The
Secret now holds the new tokens, and the running API still uses the old one.
2. On railiance01, write the new `ACTIVITY_CORE_WORKER_TOKEN` from the Secret
into `~/.config/rein-aharness/claim-loop.env`. Use a go-template read piped
into the file, and never print the value.
3. Apply `ACTIVITY_CORE_WORKERS` to `actcore-runtime-config`, then restart
`deployment/actcore-api`.
4. Restart `rein-aharness-claim-loop.service`, and confirm its first poll
returns HTTP 200.
Report the revision to secrets-engine on threads `914853d9` and `6e694682`.