Keep ambient tokens out of the service-JWT OpenBao login
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:
parent
1732c419d2
commit
9ec4e0bea5
4 changed files with 112 additions and 19 deletions
|
|
@ -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
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue