# Security Architecture Pattern Catalog

Status: completed genesis pattern catalog for NK-WP-0010
Owner: NetKingdom architecture, maintained in infospace-bench

## Purpose

This catalog collects reusable security architecture patterns for
NetKingdom-enabled infrastructures. Patterns describe recurring
implementation shapes, tradeoffs, failure modes, and verification
signals.

Patterns are not tutorials, ADRs, or vendor docs. A tutorial shows how to
do a concrete implementation. An ADR records a decision. A vendor doc
describes a product. A pattern captures a reusable architecture idea and
how NetKingdom maps it into its platform.

## Pattern Template

```text
Problem
Context
Forces
Solution
Implementation sketch
Failure modes
Related capabilities
Maturity
Verification
References
```

## Initial Pattern Set

| Pattern | Capability group | Maturity | Canonical NetKingdom mapping |
| --- | --- | --- | --- |
| STS credential vending | Secrets, authorization, data access | reviewed | IAM Profile + flex-auth + backend STS, OpenBao broker/audit where useful |
| Workload identity | Identity and secrets | draft | Kubernetes service account identity, IAM Profile mapping, OpenBao Kubernetes auth |
| Secret zero avoidance | Secrets and bootstrap | reviewed | SOPS/age bootstrap, emergency bundle, OpenBao runtime handoff |
| Dynamic secrets | Secrets and credentials | draft | OpenBao dynamic credentials with leases and revocation |
| Short-lived SSH certificates | Privileged access | draft | ops-warden issues certificates, ops-bridge consumes and audits |
| Delegated authorization | Authorization | reviewed | flex-auth as canonical boundary, Topaz as first delegated PDP |
| Break-glass access | Recovery and incident response | reviewed | emergency bundle, limited principals, audit and post-event review |
| Tenant isolation | Tenant boundary | draft | tenant ids, tenant-scoped resources, control-plane guardrails |
| Central audit ledger | Detection and audit | seed | identity, flex-auth, Topaz, OpenBao, Kubernetes, workload correlation |
| Policy-as-code admission | Kubernetes hardening | seed | deployment gates and reviewable policy packages |
| Supply-chain provenance | Supply chain | seed | SBOM, signed images, SLSA-style provenance |
| Network default deny | Network security | seed | Kubernetes NetworkPolicy and explicit service communication |
| Object-level authorization check | Application and API security | draft | every resource access includes tenant/resource/action decision |
| Human/agent identity split | Agent access control | draft | agents have explicit identities, scopes, and audit trails |
| Tenant context propagation | Tenant isolation | draft | every request and background job carries tenant context |

## First-Class Pattern Artifacts

The genesis catalogue now has one first-class artifact per exact pattern
name. The authoritative completion matrix is
`artifacts/generated/research-pattern-normalization.md`.

| Family | Exact pattern artifacts |
| --- | --- |
| Identity and access | Central Identity Provider; Identity Broker; Tenant Membership Boundary; Role Composition; Policy Decision Point / Policy Enforcement Point; Time-boxed Privilege Elevation; Break-glass Access; Human/Agent Identity Split |
| Tenant isolation | Namespace-per-Tenant; Cluster-per-Tenant; Cell-based Architecture; Shared Control Plane, Isolated Data Plane; Tenant Context Propagation; Tenant Data Partitioning |
| Kubernetes and platform | Secure Cluster Baseline; Policy-as-Code Admission Control; Pod Security Baseline/Restricted; Network Default Deny; Signed Image Admission; GitOps with Guardrails; Runtime Threat Detection |
| Secrets and cryptography | External Secrets Operator; Sealed Secret / Encrypted Git Secret; Short-lived Credentials; Key-per-Tenant; Certificate Automation |
| Application/API security | API Gateway as Security Boundary; Backend-for-Frontend; Object-Level Authorization Check; Schema-First API Security; Idempotent Command API; Secure File Upload Pipeline |
| Supply chain | Protected Main Branch; Dependency Update Bot; SBOM-per-Release; SLSA Build Provenance; Signed Container Images; Quarantined Build Runner |
| Detection and response | Security Event Taxonomy; Central Audit Ledger; Tenant Audit Log View; Incident Runbook Library; Kill Switch / Tenant Freeze; Token Revocation Sweep |

The NetKingdom umbrella artifacts created during NK-WP-0008 remain in
the infospace where they describe platform-specific compositions, such
as STS credential vending, workload identity, dynamic secrets, delegated
authorization, tenant isolation, policy-as-code admission, and
supply-chain provenance.

## Pattern Notes

### STS Credential Vending

Problem: applications need object-storage access without holding
long-lived root credentials.

Solution: use IAM Profile tokens to identify the actor, flex-auth to
authorize bucket/prefix/action/TTL, provider-native STS or temporary
credential APIs to mint credentials, and OpenBao for parent material,
lease, broker configuration, and audit where needed.

Verification: credentials include session token and expiration; deny
paths produce stable reason codes; consumers refresh before expiration.

### Secret Zero Avoidance

Problem: runtime secret managers need initial trust without creating a
worse unmanaged secret.

Solution: use SOPS/age and emergency bundles for bootstrap and recovery,
then hand runtime workload secret authority to OpenBao once initialized,
audited, backed up, and governed.

Verification: OpenBao root and recovery material are treated as
platform-root break-glass material; workloads do not consume bootstrap
root material.

### Delegated Authorization

Problem: identity providers and application code should not become the
canonical home for every resource-specific authorization decision.

Solution: flex-auth owns the canonical request/decision envelope,
resource/action vocabulary, CARING descriptors, audit/explain records,
and backend adapter boundary. Topaz is the first delegated PDP runtime.

Verification: policy packages distinguish `tenant:platform` from tenant
packages; decision envelopes include tenant, protected-system, resource,
action, assurance, obligations, deny reasons, and audit correlation.

### Break-Glass Access

Problem: operators need recovery access when normal identity, policy, or
cluster services are unavailable.

Solution: define a minimal emergency path with scoped credentials,
separate storage, event logging where possible, and mandatory post-event
review.

Verification: break-glass is tested in drills and never grants ordinary
tenant administrators platform-root authority.