net-kingdom/workplans/NK-WP-0008-it-security-architecture-patterns-infospace.md

id, type, title, domain, repo, status, owner, topic_slug, planning_priority, planning_order, created, updated, depends_on, state_hub_workstream_id, execution_repo, infospace_path

id	type	title	domain	repo	status	owner	topic_slug	planning_priority	planning_order	created	updated	depends_on	state_hub_workstream_id	execution_repo	infospace_path
NK-WP-0008	workplan	IT Security Architecture Patterns Infospace	netkingdom	net-kingdom	done	codex	netkingdom	high	8	2026-05-17	2026-05-19	NK-WP-0006	053c6d96-9396-40c9-a2e5-c36531e7810d	infospace-bench	infospaces/patterns-of-it-securita-architecture

NK-WP-0008 - IT Security Architecture Patterns Infospace

Goal

Create a curated infospace of reusable IT security architecture patterns for NetKingdom-enabled infrastructures.

The infospace should be a reference library of patterns, tradeoffs, threats, implementation variants, and canonical NetKingdom mappings. It should help us recognize patterns such as STS credential vending, workload identity, secret zero avoidance, break-glass access, delegated authorization, short-lived certificates, and policy-as-code before they become scattered repo-local folklore.

Context

The platform now spans identity, MFA, policy, SSH certificates, reverse tunnels, object storage, artifact storage, Kubernetes platform services, and secrets management. Several patterns repeat across repos:

• key-cape and Keycloak implement OIDC identity contracts.
• flex-auth implements policy-as-code authorization decisions.
• ops-warden issues short-lived SSH certificates.
• ops-bridge consumes short-lived SSH credentials and records actor attribution.
• artifact-store consumes object storage and needs temporary S3 credential support.
• Railiance platform services need a canonical secrets manager and object-storage integration.

An infospace makes these repeatable architectural patterns explicit, searchable, comparable, and teachable.

Seeded Infospace

Bernd seeded the working corpus in infospace-bench:

/home/worsch/infospace-bench/infospaces/patterns-of-it-securita-architecture/

The current seed is:

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:

• 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

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

id: NK-WP-0008-T1
status: done
priority: high
state_hub_task_id: "d1b7213c-3315-49d2-90c9-efdf2bea3563"

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

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

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

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

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

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

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

id: NK-WP-0008-T5
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, failure-mode behavior, readiness-level fit, evidence quality, and ownership clarity.

Define when a pattern is allowed to graduate from:

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:

/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

• 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.