# NetKingdom Security Pattern Ownership Map

Status: ownership mapping refreshed for NK-WP-0010

## Purpose

This map connects capabilities and patterns to the repos, components,
workplans, and responsibilities that own implementation or governance.

## Responsibility Split

| Area | Platform responsibility | Product/application responsibility | Tenant responsibility |
| --- | --- | --- | --- |
| Identity | NetKingdom IAM Profile, key-cape/Keycloak integration | consume OIDC/IAM Profile correctly | manage tenant users and groups where delegated |
| Authorization | flex-auth model, CARING descriptors, Topaz boundary | enforce decisions locally | request/administer tenant-scoped access only |
| Secrets | SOPS/age bootstrap, OpenBao runtime authority | consume scoped secrets and rotate safely | manage tenant-scoped secrets where allowed |
| Object storage | STS vending policy and backend broker boundary | support temporary credentials and refresh | request credentials for registered resources |
| SSH/admin access | ops-warden/ops-bridge short-lived access paths | avoid direct unmanaged admin paths | no platform-root access |
| Audit | central audit taxonomy and durable sinks | emit workload events and correlation ids | review tenant-visible events where offered |
| Deployment | Railiance stack layers and readiness checks | app manifests and release posture | tenant configuration within guardrails |

## Component Mapping

| Component or repo | Role in this infospace | Related patterns |
| --- | --- | --- |
| `net-kingdom` | canonical security architecture, IAM Profile, workplans, ADRs | IAM Profile, recursive platform identity, STS vending, secret-zero avoidance |
| `key-cape` | lightweight IAM Profile implementation | central identity provider, lightweight identity, MFA integration |
| Keycloak | expanded IAM implementation and federation | central identity provider, identity broker |
| Authelia | lightweight SSO backing component | central identity provider, SSO boundary |
| LLDAP | lightweight directory backing component | user lifecycle, group mapping |
| privacyIDEA | MFA and token lifecycle | privileged MFA, break-glass controls |
| `flex-auth` | authorization control plane | delegated authorization, policy-as-code, decision envelopes |
| Topaz | delegated PDP runtime | policy decision runtime |
| OpenBao | runtime secret authority | dynamic secrets, secret zero avoidance, STS broker/audit support |
| `railiance-platform` | platform service deployment | OpenBao, object storage, databases, platform secret delivery |
| Ceph RGW | candidate object-storage backend | STS credential vending |
| MinIO-compatible stores | candidate object-storage backend | STS credential vending |
| `artifact-store` | S3 consumer and artifact integrity owner | STS credential consumer, supply-chain evidence |
| `ops-warden` | short-lived SSH certificate issuer | privileged access, short-lived credentials |
| `ops-bridge` | SSH/tunnel access consumer and audit path | human/agent access, auditability |
| State Hub | cross-repo workstream and decision read model | security readiness tracking, progress evidence |

## First-Class Pattern Ownership

| Pattern family | Primary ownership | Notes |
| --- | --- | --- |
| Identity and access | NetKingdom, key-cape, Keycloak, flex-auth | IdP, broker, membership, role, PDP/PEP, elevation, break-glass, human/agent split |
| Tenant isolation | NetKingdom, Railiance platform, product repos | namespace, cluster, cell, shared-control/isolated-data, tenant context, data partitioning |
| Kubernetes and platform | Railiance platform, NetKingdom, product repos | secure baseline, admission, pod security, network, image, GitOps, runtime detection |
| Secrets and cryptography | NetKingdom, Railiance platform, OpenBao, product repos | external secrets, encrypted Git secrets, short-lived credentials, tenant keys, certificates |
| Application/API security | product repos, NetKingdom, flex-auth, artifact-store | gateway, BFF, object auth, schema-first APIs, idempotent commands, file uploads |
| Supply chain | Railiance platform, artifact-store, product repos | protected branches, dependency updates, SBOMs, SLSA provenance, signatures, build runners |
| Detection and response | NetKingdom, Railiance platform, State Hub, product repos | event taxonomy, central audit, tenant audit, runbooks, freeze, revocation |
| NetKingdom umbrella patterns | NetKingdom plus implementing repos | STS vending, workload identity, secret-zero avoidance, dynamic secrets, SSH certificates, delegated authorization, tenant isolation, policy-as-code admission, supply-chain provenance |

The exact per-pattern artifact coverage is maintained in
`artifacts/generated/research-pattern-normalization.md`.

## Workplan Mapping

| Workplan | Relationship |
| --- | --- |
| NK-WP-0006 | platform, tenant, bootstrap, identity, authorization, and OpenBao architecture baseline |
| NK-WP-0007 | object-storage STS credential-vending pattern baseline |
| NK-WP-0008 | this infospace and pattern catalog |
| NK-WP-0010 | complete first-class artifacts for every exact genesis pattern |
| NK-WP-0009 | tutorials derived from canonical patterns |
| RAIL-PL-WP-0002 | OpenBao deployment, unseal, break-glass, audit, backup, and workload integration |
| ARTIFACT-STORE-WP-0007 | S3 compatibility and temporary credential consumer behavior |

## Open Mapping Questions

- Which patterns should become NetKingdom internal standards versus
  Railiance operational runbooks?
- Which patterns require external customer-facing documentation?
- Which audit events are platform-only and which become tenant-visible?
- Which patterns need machine-readable status in State Hub or a future
  capability registry?