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

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