generated from coulomb/repo-seed
- Align agent files with on-disk workplan prefixes (infer from workplan ids) - Set workplan domain to registered domain_slug; add topic_slug where applicable - Repair frontmatter delimiter formatting; migrate legacy task status literals - Regenerate AGENTS.md, CLAUDE.md, and .claude/rules from State Hub templates
10 KiB
10 KiB
id: NK-WP-0008
type: workplan
title: IT Security Architecture Patterns Infospace
domain: infotech
repo: net-kingdom
status: done
owner: codex
topic_slug: netkingdom
planning_priority: high
planning_order: 8
created: 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
## 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:
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:
- 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
task 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
task 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
task 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
task 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
task 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:
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
- 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.