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

Adopt the confirmed secret layout

Browse source 
platform/workloads/infotech/fluid-telegram/<campaign>/<key>, confirmed with
the owner. The campaign sits between workload and bundle so two campaigns on
one interface cannot read each other's credentials, and both halves stay
overridable because the layout belongs to railiance-platform.

Records what ops-warden is for while it is fresh: it issues SSH certificates
and routes every other credential need to its owner, so it answers how to
authenticate to OpenBao and never holds what is stored there.

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 23:03:52 +02:00
parent ff2b19456f
commit c2ba960aee
3 changed files with 40 additions and 33 deletions
Download patch file Download diff file Expand all files Collapse all files

26
docs/provisioning.md
View file

@ -118,17 +118,23 @@ Reconciliation is **converging, never destructive**:
Nothing sensitive enters the spec or the resolved state. Both are committed.
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.
Paths follow the fleet convention
`platform/workloads/<domain>/<workload>/<bundle>`, owned by railiance-platform
and routed to by ops-warden (`ops-warden/wiki/CredentialRouting.md`):
**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.
```
platform/workloads/infotech/fluid-telegram/<campaign>/<key>
```
The campaign sits between the workload and the bundle so that two campaigns on
one interface cannot read each other's credentials; the bundle then names the
secret itself. `BAO_MOUNT` and `FLUID_BAO_PREFIX` override both halves, because
the layout belongs to its owner and not to this repository.
ops-warden does not hold any of these. It **issues** SSH certificates and
**routes** every other credential need to the subsystem that owns it, so it is
where to ask *how* to authenticate to OpenBao — `warden access 'openbao token
for reading a kv secret'` — and never where the secret lives.
| Secret | Key | Rule |
|---|---|---|

27
docs/seeding-runbook.md
View file

@ -67,20 +67,17 @@ The provisioner computes these paths; they are not a convention you may vary.
For campaign `hall-of-helix` on the default `secret` mount:
```
secret/fluid-telegram/hall-of-helix/telegram/operator-app api_id, api_hash
secret/fluid-telegram/hall-of-helix/telegram/operator-session written by the tool
secret/fluid-telegram/hall-of-helix/telegram/bot-token written by the tool
secret/fluid-telegram/hall-of-helix/telegram/redaction-salt written by the tool, once
platform/workloads/infotech/fluid-telegram/hall-of-helix/operator-app api_id, api_hash
platform/workloads/infotech/fluid-telegram/hall-of-helix/operator-session written by the tool
platform/workloads/infotech/fluid-telegram/hall-of-helix/bot-token written by the tool
platform/workloads/infotech/fluid-telegram/hall-of-helix/redaction-salt written by the tool, once
```
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
```
This follows the fleet convention
`platform/workloads/<domain>/<workload>/<bundle>` owned by railiance-platform,
with the campaign between workload and bundle so two campaigns on one interface
cannot read each other's credentials. These are the defaults; `BAO_MOUNT` and
`FLUID_BAO_PREFIX` override them if the owner changes the layout.
Authenticate the way ops-warden routes you, which is OIDC through key-cape
rather than a plain token login:
@ -140,14 +137,14 @@ exposes it, Step 2 disappears.
everything downstream reads it:
```bash
bao kv put secret/fluid-telegram/hall-of-helix/telegram/operator-app \
bao kv put platform/workloads/infotech/fluid-telegram/hall-of-helix/operator-app \
api_id=<the number> api_hash=<the hash>
```
Verify the tool can see it before going on:
```bash
bao kv get secret/fluid-telegram/hall-of-helix/telegram/operator-app
bao kv get platform/workloads/infotech/fluid-telegram/hall-of-helix/operator-app
```
They are shown once per application. Losing them means creating another.
@ -165,7 +162,7 @@ go run ./cmd/provision session bootstrap --campaign hall-of-helix
It prompts for the phone number, the login code, and the 2FA password, then
writes the session string to OpenBao at
`secret/fluid-telegram/hall-of-helix/telegram/operator-session`.
`platform/workloads/infotech/fluid-telegram/hall-of-helix/operator-session`.
The session string is a **full-account credential** — it can do anything the
account can. It never leaves OpenBao, is never given to the adapter, and is used

20
internal/secrets/secrets.go
View file

@ -54,14 +54,18 @@ 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")
// The fleet convention, confirmed with the owner:
// platform/workloads/<domain>/<workload>/<bundle>, per
// ops-warden/wiki/CredentialRouting.md and railiance-platform.
//
// The campaign sits between the workload and the bundle so that two
// campaigns on one interface cannot read each other's credentials -- the
// bundle then names the secret itself (operator-app, bot-token, ...).
// Both halves stay overridable: the layout is the owner's to change, not
// this repository's.
mount := firstNonEmpty(os.Getenv("BAO_MOUNT"), "platform")
prefix := firstNonEmpty(os.Getenv("FLUID_BAO_PREFIX"),
"workloads/infotech/fluid-telegram/"+campaign)
return &Store{
addr: strings.TrimSuffix(addr, "/"),
token: token,