generated from coulomb/repo-seed
Define INTENT, refresh SCOPE, and plan NetKingdom stewardship
Add ops-warden INTENT as operational access steward for NetKingdom security (route credential lanes, align docs, issue SSH certs only). Refresh SCOPE for stewardship scope, persist INTENT↔SCOPE gap assessment, and open WARDEN-WP-0006 for routing runbooks and platform alignment.
This commit is contained in:
224
INTENT.md
Normal file
224
INTENT.md
Normal file
@@ -0,0 +1,224 @@
|
||||
# INTENT
|
||||
|
||||
> This file captures **why this repository exists**, the **direction it is
|
||||
> moving toward**, and the **kind of system it is meant to become**.
|
||||
> It is intentionally **aspirational and stable**, not a description of
|
||||
> current implementation. See `SCOPE.md` for what is implemented today.
|
||||
|
||||
---
|
||||
|
||||
## One-liner
|
||||
|
||||
**Operational access steward for the NetKingdom security model — knows the platform
|
||||
credential lanes, keeps them aligned, and issues short-lived SSH certificates where
|
||||
that lane belongs to ops-warden.**
|
||||
|
||||
---
|
||||
|
||||
## Why This Exists
|
||||
|
||||
Development workers — human operators, kaizen agents, CI automations, and
|
||||
custodian tooling — need **safe, attributable access** across an increasingly
|
||||
complex NetKingdom stack: identity, MFA, authorization, runtime secrets, SSH
|
||||
reachability, and tunnel transport.
|
||||
|
||||
That stack is easy to misuse:
|
||||
|
||||
- static SSH keys and pasted API tokens in chat or Git
|
||||
- wrong subsystem chosen for a credential need (OpenBao vs warden vs key-cape)
|
||||
- drift between NetKingdom architecture canon and what operators actually run
|
||||
- ad hoc rediscovery of bootstrap and custody rules every time a worker needs access
|
||||
|
||||
**ops-warden exists so operational access has a custodian-domain home** that
|
||||
understands NetKingdom security infrastructure, routes workers to the right
|
||||
subsystem, keeps local guidance current, and **directly operates only the SSH
|
||||
short-lived certificate lane** it owns.
|
||||
|
||||
---
|
||||
|
||||
## The Mission
|
||||
|
||||
> *Where we are going.*
|
||||
|
||||
ops-warden aims to become the **operational access desk** for the ops fleet:
|
||||
|
||||
1. **Know** the NetKingdom security model — identity, authorization, secrets,
|
||||
SSH access, tunnels, bootstrap custody, and tenant/platform boundaries.
|
||||
2. **Route** workers to the correct subsystem for each credential type instead
|
||||
of becoming a universal secret vending machine.
|
||||
3. **Align** runbooks, wiki, inventory patterns, and scorecard checks with
|
||||
NetKingdom canon as the platform evolves (OpenBao-first, flex-auth policy,
|
||||
key-cape IAM Profile, railiance deployment layers).
|
||||
4. **Issue** short-lived SSH certificates for `adm` / `agt` / `atm` actors when
|
||||
host or ops reachability requires the SSH lane — via `warden sign`,
|
||||
`cert_command`, and `ops-ssh-wrapper`.
|
||||
5. **Audit** SSH signing operations and cert-side compliance so gatekeeping is
|
||||
observable, not tribal knowledge.
|
||||
|
||||
---
|
||||
|
||||
## NetKingdom Security Literacy
|
||||
|
||||
ops-warden should be fluent in the platform architecture documented in
|
||||
`net-kingdom` — especially:
|
||||
|
||||
| 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 | Future policy gate before SSH issuance; document integration |
|
||||
| **OpenBao** | Runtime secrets — API keys, dynamic creds, leases, audit | Instruct secret custody paths; SSH engine is signing backend only |
|
||||
| **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** | OpenBao/K8s/platform service deployment | Instruct production endpoints; do not deploy clusters |
|
||||
|
||||
Canonical references:
|
||||
|
||||
- `net-kingdom/docs/platform-identity-security-architecture.md`
|
||||
- `net-kingdom/docs/responsibility-map.md`
|
||||
- `wiki/AccessManagementDirective.md` (ops SSH actor model)
|
||||
|
||||
---
|
||||
|
||||
## Responsibility Boundary
|
||||
|
||||
### ops-warden owns
|
||||
|
||||
- NetKingdom-aligned **operational SSH access** guidance and stewardship
|
||||
- **SSH certificate issuance** for registered `adm` / `agt` / `atm` actors
|
||||
- Actor inventory, TTL/principal policy, cert-side scorecard, signatures log
|
||||
- `cert_command` contract and `ops-ssh-wrapper` automation surface
|
||||
- Keeping ops-warden docs and patterns aligned with NetKingdom security evolution
|
||||
|
||||
### ops-warden instructs but does not own
|
||||
|
||||
| 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 |
|
||||
| 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 |
|
||||
| `/etc/ssh/auth_principals/`, host hardening | railiance-infra |
|
||||
| OpenBao cluster init/unseal, platform deploy | railiance-platform |
|
||||
|
||||
**ops-warden is not a general secrets manager.** It may document *how* workers
|
||||
obtain non-SSH credentials; it must not store long-lived secrets in Git, State
|
||||
Hub, workplans, logs, or chat.
|
||||
|
||||
---
|
||||
|
||||
## Design Principles
|
||||
|
||||
### 1. Right lane, right subsystem
|
||||
|
||||
Every credential request should land in the subsystem NetKingdom designed for it.
|
||||
ops-warden optimizes for **correct routing** as much as for **fast issuance**.
|
||||
|
||||
### 2. Short-lived by default (SSH lane)
|
||||
|
||||
Operational SSH access uses CA-signed certificates with TTL and principals —
|
||||
never unbounded static keys in worker workflows.
|
||||
|
||||
### 3. Align with canon, reduce drift
|
||||
|
||||
When NetKingdom security architecture changes (e.g. OpenBao standardization,
|
||||
new bootstrap lanes), ops-warden updates its wiki, SCOPE, and runbooks so dev
|
||||
workers do not reconstruct decisions from stale chat history.
|
||||
|
||||
### 4. Attributable actors
|
||||
|
||||
Humans, agents, and automations are distinct actor types (`adm` / `agt` / `atm`)
|
||||
with naming, TTL, and principal conventions — matching the Access Management
|
||||
Directive and NetKingdom agent-operating model.
|
||||
|
||||
### 5. Implement narrowly, guide broadly
|
||||
|
||||
**Implement** only what belongs in the SSH certificate lane.
|
||||
**Guide** across the full NetKingdom security surface through documentation,
|
||||
scorecard checks, inventory patterns, and future policy-integration hooks.
|
||||
|
||||
### 6. Observable gatekeeping
|
||||
|
||||
Every successful SSH sign is auditable (`signatures.log`). Compliance checks
|
||||
(scorecard) make cert-side policy violations visible before they become incidents.
|
||||
|
||||
---
|
||||
|
||||
## Credential flow (target mental model)
|
||||
|
||||
```text
|
||||
Development worker needs access
|
||||
|
|
||||
v
|
||||
ops-warden (steward / desk)
|
||||
|
|
||||
+-- SSH host / ops reachability? ----> warden sign / cert_command
|
||||
|
|
||||
+-- Runtime API / platform secret? --> OpenBao path (documented)
|
||||
|
|
||||
+-- Authorization required? ---------> flex-auth decision (future hook)
|
||||
|
|
||||
+-- Identity / MFA required? --------> key-cape / Keycloak path
|
||||
|
|
||||
+-- Tunnel only? --------------------> ops-bridge + cert_command
|
||||
```
|
||||
|
||||
Today the **steward desk** is primarily documentation, runbooks, and the
|
||||
implemented SSH CLI. Routing automation and policy-gated issuance are intentional
|
||||
follow-ups, not current promises.
|
||||
|
||||
---
|
||||
|
||||
## Relationship to NetKingdom
|
||||
|
||||
NetKingdom owns the **canonical security architecture** and meta-orchestration
|
||||
across orchestrated repos. ops-warden is a **custodian-domain execution repo**
|
||||
for one security lane plus operational guidance.
|
||||
|
||||
- NetKingdom defines *what the platform security model is*
|
||||
- ops-warden keeps *operational SSH access and worker routing* aligned with it
|
||||
- Railiance repos *deploy* what NetKingdom and component repos specify
|
||||
|
||||
ops-warden should appear in NetKingdom responsibility and pattern material as
|
||||
the **operational SSH credential authority**, not as a replacement for
|
||||
OpenBao or flex-auth.
|
||||
|
||||
---
|
||||
|
||||
## Success criteria
|
||||
|
||||
ops-warden is succeeding when:
|
||||
|
||||
1. A dev worker can determine **which subsystem** to use for a credential need
|
||||
without guessing or pasting secrets into agent sessions.
|
||||
2. SSH access for agents and operators is **short-lived, inventoried, and audited**.
|
||||
3. ops-bridge and other consumers integrate via **stable cert_command** without
|
||||
backend-specific branching.
|
||||
4. NetKingdom security evolution (OpenBao, IAM Profile, bootstrap lanes) is
|
||||
reflected in ops-warden docs within the same maintenance cycle.
|
||||
5. Non-SSH secrets remain **out of ops-warden storage** — only documented paths.
|
||||
|
||||
---
|
||||
|
||||
## Non-goals
|
||||
|
||||
- Universal credential broker for all secret types
|
||||
- Replacing OpenBao, flex-auth, key-cape, or railiance deployment ownership
|
||||
- Storing Inter-Hub, LLM provider, or other long-lived API keys
|
||||
- Host-side SSH configuration deployment
|
||||
- SSO / Teleport at scale (trigger per Access Management Directive §6.2)
|
||||
|
||||
---
|
||||
|
||||
## Evolution notes
|
||||
|
||||
The repository shipped the SSH CA CLI first (WARDEN-WP-0001–0003). The
|
||||
stewardship and NetKingdom-alignment mission is the **next stratum** — docs,
|
||||
routing canon, inventory standards, production OpenBao SSH engine alignment,
|
||||
flex-auth integration design, and NetKingdom cross-links — without collapsing
|
||||
platform boundaries.
|
||||
|
||||
See `history/2026-06-17-intent-scope-assessment.md` for the current SCOPE ↔
|
||||
INTENT gap analysis and `workplans/WARDEN-WP-0006-netkingdom-alignment-and-access-stewardship.md`
|
||||
for the active execution plan.
|
||||
Reference in New Issue
Block a user