coulomb/ops-warden
2
0
Fork 0
generated from coulomb/repo-seed
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs(WARDEN-WP-0014): T5 — assist-layer docs, security model, INTENT/SCOPE

Browse Source 
- wiki/OperatorAccessAssist.md: warden access contract, conduit-vs-broker
  boundary, the three guardrails + catalog secret guard, lane semantics.
- AccessRouting.md: issue/route/assist roles; reconciled the anti-pattern
  table so the transparent conduit no longer contradicts it.
- credential-routing.md rule: added warden access + "standing broker
  forbidden, transparent --fetch sanctioned" anti-pattern.
- INTENT.md: pointer→assist charter extension. SCOPE.md: implemented
  list + Getting Oriented + maturity A4→A5 (Availability).
- history decision record for the proxy-mode choice and guardrails.

WP-0014 finished (T1–T5). 172 passed, lint clean.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
Bernd Worsch
2026-06-27 17:35:57 +02:00
parent 1c3d1b4d52
commit 5bbb791f21
7 changed files with 253 additions and 37 deletions
Download Patch File Download Diff File Expand all files Collapse all files

47
wiki/AccessRouting.md
View File

@@ -2,16 +2,21 @@
Date: 2026-06-18
ops-warden **issues short-lived SSH certificates** and **routes every other
credential need to the subsystem that owns it.** This page states that role
plainly so it cannot be misread as a desk that wraps the platform.
ops-warden **issues short-lived SSH certificates**, **routes every other credential
need to the subsystem that owns it**, and **assists** with obtaining it through the
`warden access` front door. This page states that role plainly so it cannot be
misread as a desk that wraps the platform.
- **What ops-warden executes:** the SSH certificate lane only (`warden sign`,
`cert_command`, `ops-ssh-wrapper`).
- **What ops-warden answers:** *where* a credential need belongs and *who owns it* —
pointing at the owner's docs, never restating their procedure.
- **What ops-warden never does:** vend API keys, log you in, decide policy, open
tunnels, or deploy hosts.
- **What ops-warden assists with:** `warden access` renders the exact auth/path/command
for any need and, for `exec_capable` lanes, **proxies the fetch as the caller** — a
transparent, policy-gated, audited conduit that holds, caches, and logs nothing.
- **What ops-warden never does:** *own* a secret store, *establish* identity, *decide*
policy, open tunnels, or deploy hosts. The assist conduit uses **your** identity and
owns none of these. See `OperatorAccessAssist.md`.
For the worker-facing decision tree see `CredentialRouting.md`; for component
literacy see `NetKingdomSecurityMap.md`. This page is the steward's statement of
@@ -36,24 +41,38 @@ Only the first row is something ops-warden **executes**. Every other row is a
**pointer**: ops-warden names the owner and the doc, and the worker acts on the
owning system directly.
**Assist layer (`warden access`).** For routed rows, ops-warden goes beyond the
pointer: it renders the exact auth method, path template, and command, and — where the
catalog marks a lane `exec_capable` (today: OpenBao secret reads, key-cape login) —
**proxies the call as the caller**. This does not change ownership: the secret stays in
OpenBao, the decision stays in flex-auth, the identity stays in key-cape. ops-warden is
a transparent conduit using the caller's identity, never a custodian of the value. The
boundary that keeps this sound is in `OperatorAccessAssist.md#the-conduit-vs-broker-boundary`.
---
## Anti-patterns (not coming to ops-warden)
These commands do **not** exist and will **not** be added — they belong to other
subsystems. If you find yourself wanting one, you are on the wrong desk:
ops-warden does not **own** custody, identity, authorization, or transport — those
belong to other subsystems. The assist layer (`warden access`) may *proxy* a call as
the caller, but it never becomes the owner. Don't reach for a command that implies
ownership:
| Tempting command | Why it's wrong | Right path |
| --- | --- | --- |
| `warden secret` / `warden bao` | ops-warden does not store or vend secrets | OpenBao |
| `warden login` | ops-warden does not establish identity | key-cape / Keycloak |
| `warden policy` | ops-warden does not decide authorization | flex-auth |
| `warden secret` / `warden bao` (as a store/vend) | ops-warden owns no secret store and vends nothing | OpenBao; to obtain *as yourself*, `warden access <need> --fetch` |
| `warden login` (as an identity owner) | ops-warden does not establish identity | key-cape / Keycloak; to run the login *as yourself*, `warden access <login need> --fetch` (login lane) |
| `warden policy` (as a decision) | ops-warden does not decide authorization | flex-auth makes the call; ops-warden only gates its own proxy on it |
| `warden tunnel` | ops-warden does not manage transport | ops-bridge |
ops-warden authors step-by-step procedure for exactly one lane — SSH issuance —
because it owns it. For everything else it carries a **pointer**, not a fork of
the owner's runbook. See the no-double-source rule in
`workplans/WARDEN-WP-0010-access-routing-charter.md`.
The distinction: a **standing broker** (warden's own secret-read token, a cache of
values) is forbidden; a **transparent conduit** (`warden access --fetch`, caller's
identity, nothing retained) is sanctioned. ops-warden authors step-by-step procedure
for exactly one lane — SSH issuance — because it owns it. For everything else it
carries a **pointer** (and, for `exec_capable` lanes, a conduit), not a fork of the
owner's runbook. See the no-double-source rule in
`workplans/WARDEN-WP-0010-access-routing-charter.md` and the conduit-vs-broker
boundary in `OperatorAccessAssist.md`.
---