Keep ambient tokens out of the service-JWT OpenBao login
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Successful in 1s

The anonymous JWT login inherited BAO_TOKEN/VAULT_TOKEN and the bao CLI
token helper, so it presented an env/operator token alongside the JWT.
Run that login with no env token and a token helper that returns none,
proven against the real bao CLI. This closes secrets-engine's part of the
CCR-2026-0038 no-fallback check.

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

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 544698@bnt-lap001
Assistant-Session: 279b8520-335f-4041-ba2a-9491335473db
This commit is contained in:
tegwick 2026-10-10 13:26:20 +02:00
parent 1732c419d2
commit 9ec4e0bea5
4 changed files with 112 additions and 19 deletions

View file

@ -337,6 +337,14 @@ priority: medium
state_hub_task_id: "d7bc8bdc-a0f8-5058-a640-374ef9859148"
```
Progress 2026-10-10. The CCR-2026-0038 no-fallback check, which is
secrets-engine's to prove, passed. Fixing it exposed a gap: the anonymous JWT
login inherited `BAO_TOKEN`/`VAULT_TOKEN` and the CLI token helper, so it sent an
ambient token alongside the JWT. `OpenBaoClient.login_jwt` now runs with no env
token and with a token helper that returns none. This is verified with the real
`bao` CLI against a header-recording listener. Evidence:
`docs/evidence/2026-10-10-service-jwt-no-fallback.json`.
Progress 2026-09-02. Named engine auth is shipped: `service-jwt`, `bootstrap`,
and `env` are exclusive providers. `--auth service-jwt` exchanges the KeyCape
service JWT and logs in through `OpenBaoClient.login_jwt` (JSON file, never