coulomb/ops-warden
4
0
Fork 0
Code Issues Pull requests Projects Releases 2 Packages Wiki Activity Actions

Assent to the NetKingdom security layer model (WARDEN-IN-0001)
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
Details
CI Smoke / container-smoke (push) Successful in 1s
Details

Browse source 
gate-house asked ops-warden to assent to three boundary items ratified in
GH-DEC-2026-001. All three are assented in ADR-0010.

Staff: accepted. Grepping section 5 as it invites turned up a real
non-conformance — src/warden/vault.py is a direct OpenBao client performing a
write, and so is `warden desk`'s `bao kv put`. Section 5's only escape hatch is
read-only diagnostics, which does not cover a signing write, so both are
declared in INTENT.md as an engine gap with intended owner secrets-engine and
the blocker "no engine exposes an SSH-CA surface" — ADR-0003 turned inward
rather than an exemption argued for. taint.py is metadata-only and declared
under the read-only allowance; `warden access` proxies run under the caller's
identity and supply no authority of their own.

Doctrine versus runbook: accepted. NetKingdom Security Literacy becomes a lane
routing runbook that references gate-house doctrine instead of restating it. It
had also become a prose second source for registry/routing/catalog.yaml, which
ADR-0001 already rules against.

Lane versus rule: assented unconditionally, and the access-engine veto is not
exercised. One request on sequencing only — a window where both names resolve.

gate-house added to the routing tables in INTENT.md and SCOPE.md.

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

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 4014535@bnt-lap001
Assistant-Session: d0036016-73e8-4da1-8e47-563e3ab39a3c
This commit is contained in:
tegwick 2026-08-28 21:47:44 +02:00
parent 85d3078bae
commit 70d8b503f0
8 changed files with 2579 additions and 31 deletions
Download patch file Download diff file Expand all files Collapse all files

85
INTENT.md
View file

@ -1,19 +1,26 @@
# INTENT
> **NetKingdom layering review — 2026-08-28.** This repository's role was reviewed
> against the NetKingdom IT-security layer model: **Taxonomy → Tooling → Engines →
> Staff**, layered by determinism and by the kind of artifact each layer produces.
> Findings and the argument behind them:
> `gate-house/history/2026-08-28-security-layer-model-and-gate-house-recut.md`.
> The model is `net-kingdom/canon/standards/security-layer-model_v0.1.md` (proposed),
> ratified by `gate-house/decisions/decisions.md` GH-DEC-2026-001.
> **Layer: Staff.** ops-warden is a Staff repository under the NetKingdom
> IT-security layer model (Taxonomy -> Tooling -> Engines -> Staff, layered by
> determinism and by the kind of artifact each layer produces):
> `net-kingdom/canon/standards/security-layer-model_v0.1.md`, owned by gate-house,
> ratified as `gate-house/decisions/decisions.md` GH-DEC-2026-001.
>
> The layer rule that binds every repository: **Staff never touches tooling
> directly. It acts only through engine APIs.**
> **The binding rule: Staff never touches Tooling directly. It acts only through
> Engine APIs.** ops-warden holds no state another layer depends on at runtime and
> renders no authorization decision — it consumes them from access-engine.
>
> **This repository is Staff — interactive, non-deterministic; operational stewardship.** Add the layer label and the Staff invariant. Two substantive changes. (1) The **"NetKingdom Security Literacy"** section is evidence that the security curriculum had no owner; it now has one. Doctrine and curriculum move to gate-house, and this section becomes lane-specific runbooks that reference gate-house doctrine rather than restating it. The boundary is **doctrine versus runbook**. (2) The literacy and routing tables should add gate-house — currently every plane is listed and gate-house appears nowhere — routing doctrine and authority-model questions there, while continuing to route policy decisions to access-engine. Record the lane/rule demarcation as in ops-mason.
> **Declared exception (standard section 5).** `src/warden/vault.py` (`VaultCA`) is a
> direct OpenBao client that performs a write, and `warden desk` shells `bao kv put`
> for paste-once provisioning. Both are non-conformant. Intended owner:
> **secrets-engine**; blocked on: no engine exposes an SSH certificate signing
> surface; reviewed quarterly. `src/warden/taint.py` reads KV metadata only, declared
> under the read-only observation allowance. `warden access --fetch/--exec/--wrap`
> runs the owner's tool under **the caller's** identity and supplies no authority of
> its own (`ADR-0002`).
>
> *This note records what should change. The body below is not yet adapted.*
> Assent, reasoning, and the amendment offered back to gate-house:
> `history/2026-08-28-security-layer-model-assent.md` and `ADR-0010`.
> This file captures **why this repository exists**, the **direction it is
> moving toward**, and the **kind of system it is meant to become**.
@ -92,30 +99,51 @@ owns one lane and points at the rest:
---
## NetKingdom Security Literacy
## Lane routing — who owns which need
ops-warden should be fluent in the platform architecture documented in
`net-kingdom` — especially:
**This is a runbook, not doctrine.** Security doctrine, the authority model, and the
security curriculum are **gate-house's** (`security-layer-model_v0.1` section 8).
ops-warden references them and does not restate them. What follows is lane
stewardship: which subsystem owns which need, and what ops-warden does about it.
| Plane / component | Role in access | ops-warden relationship |
| --- | --- | --- |
| **key-cape / Keycloak** | Identity — who is the actor, MFA, IAM Profile claims | Instruct identity path; do not re-implement OIDC |
| **flex-auth + Topaz** | Authorization — may this actor perform this action | Caller-side policy gate shipped (opt-in); production flip is flex-auth's |
| **OpenBao** | Runtime secrets — API keys, dynamic creds, leases, audit | Instruct custody paths; SSH engine is signing backend only; proxy reads as caller when `exec_capable` |
| **secrets-engine** | Owner-native secret-exec (`secrets-engine exec`) | Route provisioned exec lanes (e.g. npm publish); ops-warden does not hold tokens |
| **railiance-platform** (credential broker) | Scoped lease grants (`credential exec`) | Route `warden-sign` token needs; ops-warden does not mint OpenBao tokens |
| **tenant-engine** | Tenant/client secret custody and front door | Route tenant lanes once fronted; ops-warden's current tenant proxies are interim (§9) |
| **user-engine** | End-user identity and account lifecycle | No ops-warden lane today; route rather than absorb |
| **ops-warden** | Operational SSH certificates — short-lived host access | **Own and issue** this lane |
| **ops-bridge** | Tunnel transport — consumes certs via `cert_command` | Primary consumer; document integration |
| **railiance-infra** | Host principals, force-command, SSH hardening | Instruct host-side deployment; do not own Ansible |
| **railiance-platform** (deploy) | OpenBao/K8s/platform service deployment | Instruct production endpoints; do not deploy clusters |
The machine-readable form is `registry/routing/catalog.yaml`, and the executable form
is `warden plan "<need>"` / `warden route find`. Prefer either over this table — it is
orientation, and the catalog is the source of truth (`ADR-0001`).
| Component | Layer | Owns | ops-warden relationship |
| --- | --- | --- | --- |
| **gate-house** | Staff | Security doctrine, invariants, authority ceilings, authority context, conformance review, curriculum | **Route doctrine and authority-model questions here.** Not policy decisions — those go to access-engine |
| **access-engine** (`flex-auth`) | Engine | **The policy decision** — whether an actor may act. The only decision point in NetKingdom | Consume decisions; caller-side pre-sign gate. ops-warden never renders or caches one |
| **key-cape / Keycloak** | Tooling | Identity — who the actor is, MFA, IAM Profile claims | Instruct the identity path; do not re-implement OIDC |
| **OpenBao** | Tooling | Runtime secrets — API keys, dynamic creds, leases, audit | Instruct custody paths; proxy reads as the caller when `exec_capable`. Direct client use is the declared exception above |
| **secrets-engine** | Engine | Credential abstraction, custody, lifecycle; owner-native exec | Route provisioned exec lanes (e.g. npm publish). **Intended owner of the SSH-CA surface** |
| **tenant-engine** | Engine | Tenant/client secret custody and front door | Route tenant lanes once fronted; current tenant proxies are interim (section 9) |
| **user-engine** | Engine | Users, accounts, memberships | No ops-warden lane today; route rather than absorb |
| **zone-engine** | Engine | Zone identity and membership | Consume compiled membership; ops-warden declares `z1-operational` (`ADR-0009`) |
| **railiance-platform** (broker) | — | Scoped lease grants (`credential exec`) | Route `warden-sign` token needs; ops-warden does not mint OpenBao tokens |
| **ops-mason** | Staff | Building and tearing down access routes and perimeters | Peer lane owner; same lane/rule demarcation applies |
| **ops-warden** | Staff | **Operational access lanes** — short-lived SSH certificates, routing, stewardship, runbooks | **Own and issue** the SSH lane |
| **ops-bridge** | Staff | Tunnel transport — consumes certs via `cert_command` | Primary consumer; document integration |
| **railiance-infra** | — | Host principals, force-command, SSH hardening | Instruct host-side deployment; do not own Ansible |
| **kings-guard** | Staff | Adaptive defence, observation, containment; publishes posture | Posture may reduce authority, never manufacture it |
### Access lane versus access rule
Normative, per `security-layer-model_v0.1` section 8 and assented to in `ADR-0010`:
- **access lane** — ops-warden and ops-mason. *How* a worker reaches a host.
- **access rule** — access-engine. *Whether* they may.
ops-warden owns the route and never the decision. A question about whether an actor
may do something is not an ops-warden question, however it arrives.
Canonical references:
- `net-kingdom/canon/standards/security-layer-model_v0.1.md` (layers, section 5, section 8)
- `net-kingdom/docs/platform-identity-security-architecture.md`
- `net-kingdom/docs/responsibility-map.md`
- `wiki/AccessManagementDirective.md` (ops SSH actor model)
- `.claude/rules/credential-routing.md` (agent-facing runbook — stays inline by design)
---
@ -138,7 +166,8 @@ Canonical references:
| Need | Route to |
| --- | --- |
| OIDC login, MFA, human identity claims | key-cape / Keycloak (NetKingdom IAM Profile) |
| Policy decision — may actor X access resource Y | flex-auth |
| Security doctrine, invariants, authority model | gate-house |
| Policy decision — may actor X access resource Y | access-engine (`flex-auth`) |
| API keys, provider secrets, DB creds, object-storage STS | OpenBao (+ flex-auth policy where required) |
| Inter-Hub operator keys, LLM provider credentials | OpenBao or approved operator secret store |
| Tunnel lifecycle, port forwarding | ops-bridge |