Make the secret layout configuration, not a constant

ops-warden routes API-key needs to railiance-platform, whose convention is
platform/workloads/<domain>/<workload>/<bundle>. This repository invented
secret/fluid-telegram/<campaign>/telegram instead, which is not its call to
make -- a service that picks its own paths in someone else's store is how a
policy ends up written around a mistake.

Mount and prefix are now BAO_MOUNT and FLUID_BAO_PREFIX, with the old scheme
kept as a development fallback. The runbook points at `warden access` for the
current shape and at OIDC login rather than a plain token, and names the
check that tells whether a login actually took.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0172sgCZEEDJcnQmr4SGDvKa

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1361245@bnt-lap001
Assistant-Session: b3b428ef-f3e6-4688-b091-01f71461d66a
This commit is contained in:
tegwick 2026-09-04 22:32:09 +02:00
parent de7a7bdd2a
commit ff2b19456f
3 changed files with 37 additions and 4 deletions

View file

@ -118,8 +118,17 @@ Reconciliation is **converging, never destructive**:
Nothing sensitive enters the spec or the resolved state. Both are committed.
Paths are computed as `<mount>/fluid-telegram/<campaign>/telegram/<key>`, so two
campaigns on one interface cannot read each other's credentials.
Paths are `<mount>/<prefix>/<key>`, set by `BAO_MOUNT` and `FLUID_BAO_PREFIX`.
The default (`secret/fluid-telegram/<campaign>/telegram`) is a development
fallback, and the campaign is part of it so that two campaigns on one interface
cannot read each other's credentials.
**This repository does not get to invent the fleet's secret layout.** ops-warden
routes API-key needs to railiance-platform, whose convention is
`platform/workloads/<domain>/<workload>/<bundle>` — see
`ops-warden/wiki/CredentialRouting.md`. The final names are owner-confirmed, so
they are configuration here rather than a constant, and the production values
are settled with railiance-platform before the first apply.
| Secret | Key | Rule |
|---|---|---|

View file

@ -73,7 +73,24 @@ secret/fluid-telegram/hall-of-helix/telegram/bot-token written by the t
secret/fluid-telegram/hall-of-helix/telegram/redaction-salt written by the tool, once
```
Set these before any command below. `BAO_MOUNT` defaults to `secret`.
Those are the **development defaults**. The fleet convention for an API-key
bundle is `platform/workloads/<domain>/<workload>/<bundle>`, owned by
railiance-platform; ask ops-warden for the current shape and override it:
```bash
export BAO_MOUNT=platform
export FLUID_BAO_PREFIX=workloads/infotech/fluid-telegram
```
Authenticate the way ops-warden routes you, which is OIDC through key-cape
rather than a plain token login:
```bash
warden access 'openbao token for reading a kv secret' # shows auth, path, policy
bao login -method=oidc role=<domain>
```
`bao token lookup` succeeding is the check that the login actually took.
```bash
export BAO_ADDR=https://bao.coulomb.social

View file

@ -54,12 +54,19 @@ func NewFromEnv(campaign string) (*Store, error) {
return nil, fmt.Errorf("no OpenBao token: set BAO_TOKEN, or run `bao login` "+
"to write ~/.vault-token (BAO_ADDR is %s)", addr)
}
// Mount and prefix are configurable because this repo does not get to invent
// the fleet's secret layout. ops-warden routes API-key needs to
// railiance-platform, whose convention is
// platform/workloads/<domain>/<workload>/<bundle> -- see
// ops-warden/wiki/CredentialRouting.md. The defaults below are a local
// fallback for development, not the intended production location.
mount := firstNonEmpty(os.Getenv("BAO_MOUNT"), "secret")
prefix := firstNonEmpty(os.Getenv("FLUID_BAO_PREFIX"), "fluid-telegram/"+campaign+"/telegram")
return &Store{
addr: strings.TrimSuffix(addr, "/"),
token: token,
mount: mount,
prefix: "fluid-telegram/" + campaign + "/telegram",
prefix: strings.Trim(prefix, "/"),
hc: &http.Client{Timeout: 20 * time.Second},
}, nil
}