Add OpenBao runtime secret authority; complete NK-WP-0006/0007/0008

Refine the recursive platform security architecture to make OpenBao the canonical runtime secret authority, with SOPS/age, K8s Secrets, and the emergency bundle reframed as bootstrap/delivery/break-glass mechanisms. - credential-management standard v0.2: add OpenBao runtime authority section, rotation rules, and prohibited patterns (OpenBao-as-PDP, tenant platform-root) - platform-identity-security-architecture: mark implemented; add flex-auth/Topaz implications, Coulomb onboarding path, and a production-readiness checklist - NK-WP-0004/0005: document bootstrap-to-OpenBao handoff boundary - NK-WP-0006/0007: status -> done with implementation reviews; add recursive platform/tenant split and OpenBao broker/audit role for object-storage STS vending - NK-WP-0008: status -> done; repoint corpus to infospace-bench - new ADR-0007 (orchestration boundary), ADR-0008 (STS vending boundary), and the object-storage STS credential-vending architecture Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
2026-05-20 22:51:20 +02:00
parent b49631acef
commit 7b211acd57
10 changed files with 1150 additions and 69 deletions
--- a/workplans/NK-WP-0004-credential-management-foundation.md
+++ b/workplans/NK-WP-0004-credential-management-foundation.md
@@ -8,7 +8,7 @@ status: done
 owner: custodian
 topic_slug: netkingdom
 created: "2026-03-20"
-updated: "2026-03-20"
+updated: "2026-05-18"
 state_hub_workstream_id: "d9cf7c4b-886b-4cd1-ad7b-99c4e1929c9e"
 ---

@@ -68,10 +68,34 @@ Operator
      warns about time-sensitive steps like enckey-bootstrap)
 ```

+## NK-WP-0006 Runtime Secret Refinement
+
+This workplan remains the bootstrap credential foundation. With OpenBao in
+the platform stack, its outputs are not the final runtime secret model.
+They establish enough trust to bring up identity, MFA, and platform
+services safely.
+
+Trust-state mapping:
+
+- bare host and cluster trust are established by Railiance layers;
+- bootstrap secret trust is established by SOPS/age, encrypted bundles,
+  emergency material, and Kubernetes Secret injection;
+- bootstrap identity trust is established by local/key-cape/bootstrap
+  identity paths;
+- runtime secret trust begins only after OpenBao is deployed,
+  initialized, unsealed or auto-unsealed by the approved mechanism,
+  audited, backed up, and ready to issue scoped secrets or dynamic
+  credentials.
+
+After runtime secret trust exists, Kubernetes Secrets created here should
+be treated as bootstrap artifacts, delivery caches, or compatibility
+mechanisms. Long-lived workload secret authority belongs in OpenBao,
+governed by NetKingdom policy and Railiance platform operations.
+
 ## Dependency on canon standard

 All design decisions in this workplan follow
-`canon/standards/credential-management_v0.1.md`.
+`canon/standards/credential-management_v0.2.md`.
 The KeePassXC group structure, phase model, SOPS policy, and prohibited
 patterns defined there are normative. This workplan implements them.

--- a/workplans/NK-WP-0005-agent-driven-credential-bootstrap.md
+++ b/workplans/NK-WP-0005-agent-driven-credential-bootstrap.md
@@ -8,7 +8,7 @@ status: done
 owner: custodian
 topic_slug: netkingdom
 created: "2026-03-21"
-updated: "2026-03-21"
+updated: "2026-05-18"
 depends_on: NK-WP-0004
 state_hub_workstream_id: "75bc472b-cc0a-48f2-afb6-62b896f7cc19"
 ---
@@ -59,6 +59,33 @@ Agent                                       Human

 Everything else — service secrets, rotation, re-injection — is agent work.

+## NK-WP-0006 Runtime Secret Refinement
+
+With OpenBao in the platform stack, the agent-driven bootstrap is the
+handoff mechanism from bootstrap secrets to runtime secret authority.
+The agent may generate, encrypt, inject, and verify initial secrets, but
+OpenBao becomes the normal authority for platform and workload secret
+delivery once the control plane is alive.
+
+The bootstrap flow therefore has one additional boundary:
+
+1. SOPS/age and the emergency bundle establish bootstrap and recovery
+   authority.
+2. Kubernetes Secrets carry the minimum initial material needed to start
+   the identity, MFA, database, and OpenBao platform services.
+3. OpenBao is initialized, unsealed or auto-unsealed by the approved
+   mechanism, audit logging is enabled, backups are verified, and
+   workload auth methods are configured.
+4. Runtime workloads receive scoped secrets, dynamic credentials, or
+   synchronized Kubernetes Secrets from OpenBao. They do not consume
+   platform-root bootstrap material.
+
+OpenBao root tokens, unseal keys, or recovery keys are break-glass
+material. They must not be stored as ordinary tenant secrets or exposed
+to tenant administrators. If they are included in an emergency bundle,
+that bundle is platform-control-plane break-glass material and requires
+the strongest storage and review procedure available for the deployment.
+
 ## Design

 ### What changes from NK-WP-0004
--- a/workplans/NK-WP-0006-recursive-platform-identity-security-architecture.md
+++ b/workplans/NK-WP-0006-recursive-platform-identity-security-architecture.md
@@ -4,11 +4,11 @@ type: workplan
 title: Recursive platform identity and security architecture
 domain: netkingdom
 repo: net-kingdom
-status: proposed
+status: done
 owner: Bernd Worsch
 topic_slug: netkingdom
 created: 2026-05-17
-updated: 2026-05-17
+updated: 2026-05-18
 depends_on:
  - NK-WP-0001
  - NK-WP-0004
@@ -27,7 +27,7 @@ accidentally becoming the platform root of trust.
 The workplan turns the recursive insight into operational structure:
 bootstrap plane, platform control plane, tenant plane, IAM Profile,
 flex-auth authorization, Topaz runtime, privacyIDEA MFA/token handling,
-and safe orchestration boundaries.
+OpenBao runtime secret authority, and safe orchestration boundaries.

 ## Context

@@ -49,7 +49,7 @@ In scope:
 - document the three-plane architecture
 - define platform-root versus tenant authority
 - define how NetKingdom, key-cape, Keycloak, privacyIDEA, flex-auth,
-  Topaz, and Railiance relate
+  Topaz, OpenBao, and Railiance relate
 - define bootstrap-to-runtime trust states
 - update related workplans and ADRs when implementation details become
  concrete
@@ -59,6 +59,7 @@ Out of scope:

 - implementing flex-auth adapters
 - deploying Keycloak, key-cape, privacyIDEA, Topaz, or Railiance services
+- deploying OpenBao itself
 - designing customer-specific tenant policy
 - replacing existing Railiance layer ownership

@@ -84,7 +85,7 @@ to a stable decision.

 ```task
 id: NK-WP-0006-T3
-status: todo
+status: done
 priority: high
 state_hub_task_id: "842ba5a7-5199-490a-8af5-3150388e0d42"
 ```
@@ -94,7 +95,7 @@ scope, audit/explain records, and platform-root guardrails.

 ```task
 id: NK-WP-0006-T4
-status: todo
+status: done
 priority: high
 state_hub_task_id: "ce153339-f493-44ed-a2c5-befb578334fe"
 ```
@@ -104,7 +105,7 @@ runtime identity, runtime authorization, tenant onboarding.

 ```task
 id: NK-WP-0006-T5
-status: todo
+status: done
 priority: medium
 state_hub_task_id: "6c9a3561-4e63-4acd-87a7-bf0f374fa6b2"
 ```
@@ -114,7 +115,7 @@ audit readiness.

 ```task
 id: NK-WP-0006-T6
-status: todo
+status: done
 priority: medium
 state_hub_task_id: "27760e30-f773-4552-97f4-7fbe56507f9e"
 ```
@@ -123,7 +124,7 @@ a dedicated repo. Capture the decision as an ADR before implementation.

 ```task
 id: NK-WP-0006-T7
-status: todo
+status: done
 priority: medium
 state_hub_task_id: "f09519ac-cf97-4f8b-8a7b-6ff828bbd8d9"
 ```
@@ -131,6 +132,33 @@ Define production readiness checks for the security platform: MFA state,
 secret rotation state, flex-auth policy state, Topaz health, audit sink,
 and break-glass verification.

+## Implementation Review - 2026-05-18
+
+The recursive architecture remains the right framing. The refinement from
+the current stack is that OpenBao is now part of the platform control
+plane as the runtime secret authority. SOPS/age and emergency bundles
+remain bootstrap and recovery mechanisms; they must not become the
+long-lived runtime authority for every workload secret once OpenBao is
+available.
+
+Implemented refinements:
+
+- `docs/platform-identity-security-architecture.md` now includes explicit
+  flex-auth/Topaz implications, Coulomb tenant onboarding, production
+  readiness checks, and OpenBao secret authority boundaries.
+- `docs/adr/ADR-0007-security-orchestration-boundary.md` records that
+  orchestration stays in Railiance playbooks for now; a dedicated repo is
+  deferred until sequencing has a stable, cross-repo product surface.
+- `workplans/NK-WP-0007-object-storage-sts-credential-vending.md` now
+  treats OpenBao as the runtime broker/audit option without letting it
+  replace flex-auth authorization or storage-native STS semantics.
+- `workplans/NK-WP-0004-credential-management-foundation.md`,
+  `workplans/NK-WP-0005-agent-driven-credential-bootstrap.md`, and
+  `canon/standards/credential-management_v0.2.md` now distinguish
+  bootstrap credential handling from the OpenBao runtime-secret handoff.
+
+State Hub task statuses should be synchronized to match this workplan.
+
 ## Acceptance Criteria

 - Architecture docs distinguish bootstrap plane, platform control plane,
@@ -138,7 +166,7 @@ and break-glass verification.
 - Coulomb is represented as tenant zero/reference tenant, not platform
  root.
 - The role of NetKingdom, key-cape, Keycloak, privacyIDEA, flex-auth,
-  Topaz, and Railiance is clear.
+  Topaz, OpenBao, and Railiance is clear.
 - Follow-up workplans identify where flex-auth and bootstrap work need to
  adapt.
 - Any future orchestration repo is justified by an ADR before it is
--- a/workplans/NK-WP-0007-object-storage-sts-credential-vending.md
+++ b/workplans/NK-WP-0007-object-storage-sts-credential-vending.md
@@ -4,13 +4,13 @@ type: workplan
 title: Object Storage STS Credential Vending
 domain: netkingdom
 repo: net-kingdom
-status: proposed
+status: done
 owner: codex
 topic_slug: netkingdom
 planning_priority: high
 planning_order: 7
 created: 2026-05-17
-updated: 2026-05-17
+updated: 2026-05-18
 depends_on:
  - NK-WP-0004
  - NK-WP-0005
@@ -50,6 +50,11 @@ security architecture. The surrounding ecosystem matters:
  lightweight stack, not object-storage policy owners.
 - flex-auth owns policy-as-code decisions, resource/action vocabulary,
  decision envelopes, delegated PDP adapters, and audit semantics.
+- OpenBao is now part of the platform stack as the runtime secret
+  authority, dynamic credential broker where appropriate, and audit
+  source for secret access. It can broker or store credential material,
+  but it does not replace flex-auth authorization or provider-native STS
+  semantics.
 - ops-warden and ops-bridge provide a useful precedent for short-lived
  credentials and actor attribution, but they are SSH-specific and
  should not be overloaded with object-storage credentials.
@@ -80,12 +85,38 @@ Out of scope:
 - replacing flex-auth with provider-specific bucket policies
 - putting object-storage policy inside key-cape, ops-warden, or
  ops-bridge
+- letting OpenBao root/admin authority become the object-storage policy
+  model
+
+## Recursive Platform Implications
+
+This workplan depends on NK-WP-0006, so object-storage credential vending
+must honor the platform/tenant split:
+
+- `tenant:platform` may administer the vending service, OpenBao mounts,
+  storage backends, policy import pipeline, and audit retention.
+- `tenant:coulomb` and future tenants may request scoped credentials only
+  for registered tenant resources.
+- flex-auth decision envelopes must include tenant id, protected-system
+  id, bucket or prefix, action set, TTL, assurance evidence, obligations,
+  deny reasons, and audit correlation ids.
+- CARING descriptors must mark whether a request is platform-scoped or
+  tenant-scoped; platform-scoped descriptor use is rare, reviewed, and
+  auditable.
+- Topaz is the first delegated PDP runtime behind flex-auth. Its data and
+  policy loading must not give a tenant administrator control over
+  platform policies.
+- OpenBao may broker, lease, audit, or store temporary credential
+  material after flex-auth approval. OpenBao must not become the source of
+  object-storage authorization policy, and tenants must not receive
+  OpenBao root tokens, unseal/recovery material, platform mounts, or
+  global auth-method control.

 ## Tasks

 ```task
 id: NK-WP-0007-T1
-status: todo
+status: done
 priority: high
 state_hub_task_id: "3b50c48f-1ab2-4631-b176-d49d9d705f1e"
 ```
@@ -97,7 +128,7 @@ flow, and failure modes.

 ```task
 id: NK-WP-0007-T2
-status: todo
+status: done
 priority: high
 state_hub_task_id: "5b942d22-6f29-4975-88fb-e3e5bcaf4029"
 ```
@@ -109,7 +140,7 @@ multipart operations), TTL limits, obligations, and deny reasons.

 ```task
 id: NK-WP-0007-T3
-status: todo
+status: done
 priority: high
 state_hub_task_id: "8d27e5b4-9bbb-4a53-a079-0df1047d755e"
 ```
@@ -121,30 +152,31 @@ issuer restrictions.

 ```task
 id: NK-WP-0007-T4
-status: todo
+status: done
 priority: medium
 state_hub_task_id: "c0c4f297-6cff-419b-9ce3-be5537c92e93"
 ```

 Assess backend STS implementations and write a decision record covering
 Ceph RGW STS, MinIO/AIStor STS, AWS STS, Cloudflare R2 temporary
-credentials, and whether OpenBao/Vault should broker any of these
-directly.
+credentials, and when OpenBao should broker, lease, audit, or store the
+resulting credential material.

 ```task
 id: NK-WP-0007-T5
-status: todo
+status: done
 priority: medium
 state_hub_task_id: "ccb10b2d-6378-4824-90b1-c31bd882d93d"
 ```

 Prototype the smallest credential-vending interface: CLI or HTTP
 request shape, normalized response shape, lease metadata, audit event,
-and a `credential_process`-compatible option for SDK consumers.
+OpenBao lease/audit metadata where used, and a
+`credential_process`-compatible option for SDK consumers.

 ```task
 id: NK-WP-0007-T6
-status: todo
+status: done
 priority: medium
 state_hub_task_id: "63c6859b-980e-44da-a5a6-b92a8a3225dd"
 ```
@@ -154,12 +186,32 @@ environment variables, `AWS_SESSION_TOKEN`, refresh behavior, sidecar or
 controller refresh options, and prohibited patterns such as long-lived
 root access keys.

+## Implementation Review - 2026-05-18
+
+Implemented as architecture and decision artifacts:
+
+- `docs/object-storage-sts-credential-vending.md` defines the target
+  architecture, actors, trust boundaries, token flow, flex-auth
+  vocabulary, IAM Profile requirements, backend assessment, OpenBao
+  role, request/response prototype, audit event, failure modes, and
+  consumer guidance.
+- `docs/adr/ADR-0008-object-storage-sts-credential-vending.md` records
+  the decision to use a provider-neutral NetKingdom vending boundary with
+  provider-native temporary credential mechanisms where possible.
+
+The implementation deliberately stops before building a live vending
+service. Service implementation belongs in a follow-up workplan once
+artifact-store has session-token/refresh support and the Railiance
+OpenBao bootstrap/unseal/break-glass work is ready.
+
 ## Acceptance Criteria

 - NetKingdom has a canonical, provider-neutral pattern for object-storage
  STS credential vending.
 - flex-auth is the policy decision point for bucket/prefix/action/TTL
  authorization.
+- OpenBao is treated as runtime secret/lease infrastructure where useful,
+  not as the canonical authorization policy engine.
 - key-cape and Keycloak are treated as IAM Profile implementations, not
  object-storage policy engines.
 - ops-warden and ops-bridge remain SSH/tunnel-specific but their
--- a/workplans/NK-WP-0008-it-security-architecture-patterns-infospace.md
+++ b/workplans/NK-WP-0008-it-security-architecture-patterns-infospace.md
@@ -4,16 +4,18 @@ type: workplan
 title: IT Security Architecture Patterns Infospace
 domain: netkingdom
 repo: net-kingdom
-status: proposed
+status: done
 owner: codex
 topic_slug: netkingdom
 planning_priority: high
 planning_order: 8
 created: 2026-05-17
-updated: 2026-05-17
+updated: 2026-05-19
 depends_on:
  - NK-WP-0006
 state_hub_workstream_id: "053c6d96-9396-40c9-a2e5-c36531e7810d"
+execution_repo: infospace-bench
+infospace_path: infospaces/patterns-of-it-securita-architecture
 ---

 # NK-WP-0008 - IT Security Architecture Patterns Infospace
@@ -49,13 +51,40 @@ and secrets management. Several patterns repeat across repos:
 An infospace makes these repeatable architectural patterns explicit,
 searchable, comparable, and teachable.

+## Seeded Infospace
+
+Bernd seeded the working corpus in `infospace-bench`:
+
+```text
+/home/worsch/infospace-bench/infospaces/patterns-of-it-securita-architecture/
+```
+
+The current seed is:
+
+```text
+genesis/InitialExploration.md
+```
+
+That file already sketches the two intended collections: a security
+capability catalog and a security architecture pattern catalog, with
+readiness levels and mappings to standards such as NIST CSF, CIS, OWASP,
+SLSA, and OpenSSF.
+
+NK-WP-0008 will therefore use `infospace-bench` as the canonical working
+space instead of creating a separate `docs/security-patterns/` tree in
+`net-kingdom`. `net-kingdom` remains the owner of the NetKingdom security
+architecture mapping; `infospace-bench` owns the concrete infospace
+artifact lifecycle, manifests, evaluation reports, and exports.
+
 ## Scope

 In scope:

- define a pattern document template
- create an infospace directory under `docs/security-patterns/`
- capture initial patterns and their NetKingdom mapping
+- promote the seeded directory into a valid `infospace-bench` infospace
+  with `infospace.yaml`, `artifacts/index.yaml`, and the standard layout
+- import `genesis/InitialExploration.md` as the seed source artifact
+- define capability and pattern document templates inside the infospace
+- capture initial capability, pattern, readiness, and mapping artifacts
 - record source references and current product/tool options
 - connect patterns to implementation repos and workplans
 - distinguish canonical patterns from experiments and anti-patterns
@@ -63,74 +92,195 @@ In scope:
 Out of scope:

 - implementing every pattern
+- building new lower-level `infospace-bench` engine features
 - replacing ADRs
 - duplicating vendor documentation
+- using `net-kingdom/docs/security-patterns/` as the primary corpus
 - writing full tutorials; tutorials are handled by NK-WP-0009

 ## Tasks

+### T01 - Promote The Seed Into A Valid Infospace
+
 ```task
 id: NK-WP-0008-T1
-status: todo
+status: done
 priority: high
 state_hub_task_id: "d1b7213c-3315-49d2-90c9-efdf2bea3563"
 ```

-Define the security-pattern infospace structure and template:
-problem, forces, applicability, threat model, canonical NetKingdom
-mapping, implementation variants, operational checks, audit hooks,
-anti-patterns, and references.
+Promote
+`/home/worsch/infospace-bench/infospaces/patterns-of-it-securita-architecture`
+from a genesis note into a valid `infospace-bench` project: create
+`infospace.yaml`, `artifacts/index.yaml`, the required artifact/output
+directories, and a manifest entry for `genesis/InitialExploration.md`.
+
+Define the initial artifact taxonomy for:
+
+- capabilities
+- patterns
+- readiness levels
+- mappings
+- source references
+- generated reports
+
+### T02 - Extract The Initial Capability And Pattern Catalogs

 ```task
 id: NK-WP-0008-T2
-status: todo
+status: done
 priority: high
 state_hub_task_id: "59966187-27f1-4b9c-9dfc-e59d11ff115c"
 ```

-Create initial pattern entries for: STS credential vending, workload
-identity, secret zero avoidance, dynamic secrets, short-lived SSH
-certificates, delegated authorization, break-glass access, and
-policy-as-code.
+Extract the first structured artifacts from the seeded exploration:
+
+- a security capability catalog
+- a security architecture pattern catalog
+- readiness levels RL0-RL4
+- a production readiness baseline
+
+Initial patterns must include STS credential vending, workload identity,
+secret zero avoidance, dynamic secrets, short-lived SSH certificates,
+delegated authorization, break-glass access, tenant isolation, central
+audit ledger, policy-as-code admission, and supply-chain provenance.
+
+Each pattern artifact should use a repeatable template: problem, context,
+forces, solution, implementation sketch, failure modes, related
+capabilities, maturity, verification, and references.
+
+### T03 - Map Patterns To NetKingdom And Ecosystem Ownership

 ```task
 id: NK-WP-0008-T3
-status: todo
+status: done
 priority: medium
 state_hub_task_id: "927c08a5-1a7e-4634-a514-0f562e286708"
 ```

-Map each pattern to NetKingdom/Railiance repos and components:
-net-kingdom, key-cape, flex-auth, ops-warden, ops-bridge,
-railiance-platform, artifact-store, Keycloak, Authelia, LLDAP,
-privacyIDEA, OpenBao, Ceph RGW, and MinIO-compatible stores.
+Map each capability and pattern to the owning repos, components, and
+workplans:
+
+- `net-kingdom`, NK-WP-0006, NK-WP-0007, NK-WP-0008, NK-WP-0009
+- `key-cape`, Keycloak, Authelia, LLDAP, privacyIDEA
+- `flex-auth`, Topaz, CARING descriptors, decision envelopes
+- `railiance-platform`, OpenBao, Ceph RGW, MinIO-compatible stores
+- `ops-warden`, `ops-bridge`, short-lived SSH and agent access
+- `artifact-store`, object storage, STS consumers, artifact integrity
+- relevant standards and references from the seed document
+
+This mapping should distinguish platform ownership, product/application
+ownership, tenant responsibility, and external provider responsibility.
+
+### T04 - Build The Index, Maturity Matrix, And Report

 ```task
 id: NK-WP-0008-T4
-status: todo
+status: done
 priority: medium
 state_hub_task_id: "884626ea-243e-4806-9267-77ef643158b7"
 ```

-Create an index page with pattern status, maturity, owning repo,
-implementation links, and open decisions.
+Create the first infospace index/report with capability status, pattern
+maturity, owning repo, implementation links, open decisions, and gaps.
+
+The report should make it easy to answer:
+
+- which patterns are canonical versus experimental
+- which patterns already have NetKingdom/Railiance implementation anchors
+- which patterns need ADRs, workplans, or tutorials
+- which patterns feed NK-WP-0009 tutorials
+
+### T05 - Define Admission And Review Criteria

 ```task
 id: NK-WP-0008-T5
-status: todo
+status: done
 priority: medium
 state_hub_task_id: "d3b29f3d-0da5-43b5-a93a-d95fb8a0ceef"
 ```

 Add review criteria for admitting new patterns: vendor neutrality,
 threat-model clarity, open-source/commercial implementation options,
-operability, auditability, and failure-mode behavior.
+operability, auditability, failure-mode behavior, readiness-level fit,
+evidence quality, and ownership clarity.
+
+Define when a pattern is allowed to graduate from:
+
+```text
+seed -> draft -> reviewed -> canonical -> deprecated
+```
+
+The criteria should be expressed as an infospace evaluation/checklist so
+future pattern additions can be reviewed consistently.
+
+## Implementation Review - 2026-05-19
+
+NK-WP-0008 has been implemented in `infospace-bench` at:
+
+```text
+/home/worsch/infospace-bench/infospaces/patterns-of-it-securita-architecture/
+```
+
+Created artifacts:
+
+- `infospace.yaml`
+- `artifacts/index.yaml`
+- `artifacts/entities/security-capability-catalog.md`
+- `artifacts/entities/security-architecture-pattern-catalog.md`
+- `artifacts/entities/security-readiness-levels.md`
+- `artifacts/relations/netkingdom-ownership-map.md`
+- `artifacts/generated/security-pattern-index.md`
+- `artifacts/generated/pattern-admission-review.md`
+- `reports/initial-security-pattern-report.md`
+
+Population pass:
+
+- copied the NetKingdom object-storage STS credential-vending document,
+  platform identity/security architecture document, ADR-0008, and
+  Railiance OpenBao platform secrets service note into
+  `artifacts/sources/`
+- added `artifacts/entities/capability-object-storage-access.md`
+- added `artifacts/entities/pattern-sts-credential-vending.md`
+- added `artifacts/relations/sts-credential-vending-relationship-map.md`
+- added `artifacts/generated/sts-credential-vending-extraction.md`
+- registered the new STS/OpenBao evidence, capability, pattern, relation
+  map, extraction, index, and report edges in `artifacts/index.yaml`
+- normalized relationship direction so the infospace graph remains
+  connected and acyclic
+
+Catalogue population pass:
+
+- added first-class pattern artifacts for the initial NetKingdom pattern
+  set beyond STS credential vending: workload identity, secret zero
+  avoidance, dynamic secrets, short-lived SSH certificates, delegated
+  authorization, break-glass access, tenant isolation, central audit
+  ledger, policy-as-code admission, supply-chain provenance, network
+  default deny, object-level authorization check, human/agent identity
+  split, and tenant context propagation
+- added `artifacts/generated/research-pattern-normalization.md` to map
+  the broader `genesis/InitialExploration.md` research tables into the
+  first-class pattern set and future promotion candidates
+- registered the pattern artifacts in `artifacts/index.yaml` with source
+  seed, catalog inclusion, ownership map, admission review, readiness,
+  and index summary relationships
+
+Verification:
+
+- `.venv/bin/python -m infospace_bench inspect infospaces/patterns-of-it-securita-architecture`
+- `.venv/bin/python -m infospace_bench validate infospaces/patterns-of-it-securita-architecture`
+- `.venv/bin/python -m infospace_bench metrics infospaces/patterns-of-it-securita-architecture` passed viability in snapshot `502d0933` with 16 artifacts, 100% coverage, one connected component, and zero consistency cycles
+- `.venv/bin/python -m infospace_bench graph infospaces/patterns-of-it-securita-architecture --format mermaid`
+- `.venv/bin/python -m pytest` passed with 179 passed, 2 skipped

 ## Acceptance Criteria

- `docs/security-patterns/` exists with a repeatable pattern template.
+- `infospace-bench/infospaces/patterns-of-it-securita-architecture/`
+  is a valid infospace-bench project with a manifest and standard layout.
 - Initial high-value security patterns are documented in a consistent
  shape.
 - Each pattern names the canonical NetKingdom mapping and the repos that
  own implementation.
 - The infospace distinguishes patterns, tutorials, ADRs, and vendor docs.
+- State Hub task titles and descriptions reflect the concrete
+  infospace-bench workflow instead of generic placeholder task names.