Add security architecture pattern infospace

This commit is contained in:
2026-05-19 07:12:07 +02:00
parent 3ca891de4a
commit 5bb4b40b86
81 changed files with 6836 additions and 0 deletions

View File

@@ -0,0 +1,120 @@
# Pattern Admission And Review Criteria
Status: review checklist refreshed for NK-WP-0010
## Purpose
This checklist controls how new patterns enter and graduate inside the
security architecture pattern infospace.
NK-WP-0010 admitted every exact pattern named in the genesis catalogue as
`seed` or stronger. The next reviews should focus on evidence quality and
maturity promotion rather than admission.
## Lifecycle
```text
seed -> draft -> reviewed -> canonical -> deprecated
```
## Admission Criteria
### Seed
A pattern can enter as `seed` when:
- it describes a recurring security architecture problem;
- it has a source, observation, workplan, incident, or external reference;
- it is clearly not just a one-off implementation note.
### Draft
A pattern can move to `draft` when it has:
- problem;
- context;
- forces and tradeoffs;
- solution sketch;
- known failure modes;
- related capabilities;
- initial NetKingdom or ecosystem mapping.
### Reviewed
A pattern can move to `reviewed` when it has:
- threat-model clarity;
- vendor-neutral framing;
- at least one open-source or self-hosted implementation option when
possible;
- commercial/provider options where relevant;
- operability notes;
- audit hooks;
- failure-mode behavior;
- readiness-level fit;
- owning repo or component named;
- evidence needed for verification.
### Canonical
A pattern can move to `canonical` when:
- NetKingdom architecture accepts it as the recommended pattern;
- implementation anchors exist or are intentionally scheduled;
- one or more workplans, ADRs, tutorials, or runbooks point to it;
- the pattern has clear prohibited alternatives or anti-patterns;
- verification evidence has been captured at the intended readiness
level.
### Deprecated
A pattern moves to `deprecated` when:
- it is replaced by a stronger pattern;
- implementation experience shows the pattern is unsafe or too costly;
- platform direction changes;
- vendor or technology assumptions no longer hold.
Deprecated patterns remain visible with their reason and replacement.
## Review Checklist
| Criterion | Question |
| --- | --- |
| Vendor neutrality | Can the pattern be understood without committing to a single product? |
| Threat model | Does it name the realistic failures or attacks it reduces? |
| Ownership | Are platform, product, tenant, and provider responsibilities clear? |
| Operability | Can an operator deploy, monitor, rotate, and recover it? |
| Auditability | Are security-relevant events and correlation ids defined? |
| Failure behavior | Does it fail closed or document controlled exceptions? |
| Readiness fit | Is RL0-RL4 applicability explicit? |
| Evidence | What proves implementation is correct? |
| Anti-patterns | What common unsafe shortcuts are prohibited? |
| Tutorial handoff | Does NK-WP-0009 need a tutorial for it? |
## Current Canonical Candidates
- STS credential vending.
- Secret zero avoidance.
- Delegated authorization.
- Break-glass access.
- Short-lived credentials.
- Policy Decision Point / Policy Enforcement Point.
These are candidates, not automatically canonical. Each still needs the
checklist evidence before the infospace marks it canonical.
## NK-WP-0010 Review Backlog
Use `artifacts/generated/research-pattern-normalization.md` as the
backlog for maturity promotion. Strong first review candidates are:
- Central Identity Provider and Identity Broker, because they shape
key-cape/Keycloak integration.
- Tenant Membership Boundary and Tenant Context Propagation, because
they protect multi-tenant correctness.
- Policy-as-Code Admission Control, Pod Security Baseline/Restricted,
and Signed Image Admission, because they form the platform deployment
gate.
- Security Event Taxonomy and Tenant Audit Log View, because they define
what can become tenant-visible evidence.

View File

@@ -0,0 +1,91 @@
# Research Pattern Normalization
Status: complete coverage map for NK-WP-0010
## Purpose
The genesis exploration contains a broad security architecture pattern
catalogue. NK-WP-0010 promotes every exact pattern name from that
catalogue into a first-class infospace artifact while preserving the
earlier NetKingdom-specific umbrella patterns created during NK-WP-0008.
## Completion Rule
- Every exact pattern name in `genesis/InitialExploration.md` has a
discoverable `artifacts/entities/pattern-*.md` artifact.
- Umbrella NetKingdom patterns remain when they describe a canonical
platform shape that spans multiple exact genesis patterns.
- The generated index and ownership map link both exact and umbrella
artifacts, but the exact genesis list is the completion baseline for
this workplan.
## Completion Matrix
| Family | Exact genesis pattern | Artifact | Current status |
| --- | --- | --- | --- |
| Identity and access | Central Identity Provider | `artifacts/entities/pattern-central-identity-provider.md` | seed |
| Identity and access | Identity Broker | `artifacts/entities/pattern-identity-broker.md` | seed |
| Identity and access | Tenant Membership Boundary | `artifacts/entities/pattern-tenant-membership-boundary.md` | seed |
| Identity and access | Role Composition | `artifacts/entities/pattern-role-composition.md` | seed |
| Identity and access | Policy Decision Point / Policy Enforcement Point | `artifacts/entities/pattern-policy-decision-point-policy-enforcement-point.md` | reviewed |
| Identity and access | Time-boxed Privilege Elevation | `artifacts/entities/pattern-time-boxed-privilege-elevation.md` | seed |
| Identity and access | Break-glass Access | `artifacts/entities/pattern-break-glass-access.md` | reviewed |
| Identity and access | Human/Agent Identity Split | `artifacts/entities/pattern-human-agent-identity-split.md` | draft |
| Tenant isolation | Namespace-per-Tenant | `artifacts/entities/pattern-namespace-per-tenant.md` | seed |
| Tenant isolation | Cluster-per-Tenant | `artifacts/entities/pattern-cluster-per-tenant.md` | seed |
| Tenant isolation | Cell-based Architecture | `artifacts/entities/pattern-cell-based-architecture.md` | seed |
| Tenant isolation | Shared Control Plane, Isolated Data Plane | `artifacts/entities/pattern-shared-control-plane-isolated-data-plane.md` | seed |
| Tenant isolation | Tenant Context Propagation | `artifacts/entities/pattern-tenant-context-propagation.md` | draft |
| Tenant isolation | Tenant Data Partitioning | `artifacts/entities/pattern-tenant-data-partitioning.md` | seed |
| Kubernetes and platform | Secure Cluster Baseline | `artifacts/entities/pattern-secure-cluster-baseline.md` | seed |
| Kubernetes and platform | Policy-as-Code Admission Control | `artifacts/entities/pattern-policy-as-code-admission-control.md` | seed |
| Kubernetes and platform | Pod Security Baseline/Restricted | `artifacts/entities/pattern-pod-security-baseline-restricted.md` | seed |
| Kubernetes and platform | Network Default Deny | `artifacts/entities/pattern-network-default-deny.md` | seed |
| Kubernetes and platform | Signed Image Admission | `artifacts/entities/pattern-signed-image-admission.md` | seed |
| Kubernetes and platform | GitOps with Guardrails | `artifacts/entities/pattern-gitops-with-guardrails.md` | seed |
| Kubernetes and platform | Runtime Threat Detection | `artifacts/entities/pattern-runtime-threat-detection.md` | seed |
| Secrets and cryptography | External Secrets Operator | `artifacts/entities/pattern-external-secrets-operator.md` | seed |
| Secrets and cryptography | Sealed Secret / Encrypted Git Secret | `artifacts/entities/pattern-sealed-secret-encrypted-git-secret.md` | seed |
| Secrets and cryptography | Short-lived Credentials | `artifacts/entities/pattern-short-lived-credentials.md` | reviewed |
| Secrets and cryptography | Key-per-Tenant | `artifacts/entities/pattern-key-per-tenant.md` | seed |
| Secrets and cryptography | Certificate Automation | `artifacts/entities/pattern-certificate-automation.md` | seed |
| Application/API security | API Gateway as Security Boundary | `artifacts/entities/pattern-api-gateway-as-security-boundary.md` | seed |
| Application/API security | Backend-for-Frontend | `artifacts/entities/pattern-backend-for-frontend.md` | seed |
| Application/API security | Object-Level Authorization Check | `artifacts/entities/pattern-object-level-authorization-check.md` | draft |
| Application/API security | Schema-First API Security | `artifacts/entities/pattern-schema-first-api-security.md` | seed |
| Application/API security | Idempotent Command API | `artifacts/entities/pattern-idempotent-command-api.md` | seed |
| Application/API security | Secure File Upload Pipeline | `artifacts/entities/pattern-secure-file-upload-pipeline.md` | seed |
| Supply chain | Protected Main Branch | `artifacts/entities/pattern-protected-main-branch.md` | seed |
| Supply chain | Dependency Update Bot | `artifacts/entities/pattern-dependency-update-bot.md` | seed |
| Supply chain | SBOM-per-Release | `artifacts/entities/pattern-sbom-per-release.md` | seed |
| Supply chain | SLSA Build Provenance | `artifacts/entities/pattern-slsa-build-provenance.md` | seed |
| Supply chain | Signed Container Images | `artifacts/entities/pattern-signed-container-images.md` | seed |
| Supply chain | Quarantined Build Runner | `artifacts/entities/pattern-quarantined-build-runner.md` | seed |
| Detection and response | Security Event Taxonomy | `artifacts/entities/pattern-security-event-taxonomy.md` | seed |
| Detection and response | Central Audit Ledger | `artifacts/entities/pattern-central-audit-ledger.md` | seed |
| Detection and response | Tenant Audit Log View | `artifacts/entities/pattern-tenant-audit-log-view.md` | seed |
| Detection and response | Incident Runbook Library | `artifacts/entities/pattern-incident-runbook-library.md` | seed |
| Detection and response | Kill Switch / Tenant Freeze | `artifacts/entities/pattern-kill-switch-tenant-freeze.md` | seed |
| Detection and response | Token Revocation Sweep | `artifacts/entities/pattern-token-revocation-sweep.md` | seed |
## NetKingdom Umbrella Patterns
These artifacts remain first-class because they capture NetKingdom
platform-specific architecture that spans multiple exact seed patterns:
| Umbrella pattern | Artifact | Covers |
| --- | --- | --- |
| STS credential vending | `artifacts/entities/pattern-sts-credential-vending.md` | short-lived object-storage credentials, delegated authorization, OpenBao broker/audit support |
| Workload identity | `artifacts/entities/pattern-workload-identity.md` | service identities, workload secret injection, tenant context |
| Secret zero avoidance | `artifacts/entities/pattern-secret-zero-avoidance.md` | encrypted Git secrets, bootstrap, break-glass, OpenBao handoff |
| Dynamic secrets | `artifacts/entities/pattern-dynamic-secrets.md` | short-lived credentials, leases, rotation, revocation |
| Short-lived SSH certificates | `artifacts/entities/pattern-short-lived-ssh-certificates.md` | time-boxed privilege, agent/admin access, SSH audit |
| Delegated authorization | `artifacts/entities/pattern-delegated-authorization.md` | PDP/PEP, flex-auth, Topaz, decision envelopes |
| Tenant isolation | `artifacts/entities/pattern-tenant-isolation.md` | namespace, cluster, cell, data, and control-plane isolation |
| Policy-as-code admission | `artifacts/entities/pattern-policy-as-code-admission.md` | admission control, pod security, image trust, GitOps guardrails |
| Supply-chain provenance | `artifacts/entities/pattern-supply-chain-provenance.md` | SBOMs, SLSA, signed images, protected branches, trusted runners |
## Completion Result
No exact genesis pattern remains unaccounted. Future work should improve
maturity and evidence quality, not create missing seed placeholders.

View File

@@ -0,0 +1,72 @@
# Security Pattern Index And Maturity Matrix
Status: generated index refreshed for NK-WP-0010
## Capability Index
| Capability group | Initial status | Primary owner | Gaps |
| --- | --- | --- | --- |
| Security governance and readiness | draft | NetKingdom, State Hub | risk register and readiness gates need formalization |
| Identity and user management | partial | NetKingdom, key-cape, Keycloak | lifecycle and federation evidence incomplete |
| Authorization and access control | partial | flex-auth, NetKingdom | policy package lifecycle and Topaz runtime checks need implementation |
| Tenant isolation | draft | NetKingdom, Railiance, product repos | isolation patterns now exist; product conformance tests remain |
| Secrets, keys, and credentials | partial | NetKingdom, Railiance platform, OpenBao | OpenBao drills and certificate lifecycle evidence pending |
| Network and edge security | seed | Railiance, product repos | default-deny and gateway patterns need concrete manifests |
| Platform and Kubernetes hardening | seed | Railiance | baseline, pod-security, and admission patterns need implementation evidence |
| Application and API security | seed | product repos, NetKingdom | object-level, schema, BFF, command, and upload patterns need product adoption |
| Data protection and privacy | seed | product repos, platform | tenant data partitioning and key-per-tenant need storage-specific decisions |
| Software supply chain security | seed | Railiance, artifact-store, product repos | SBOM/provenance/signature pipeline needs implementation anchors |
| Observability, detection, and audit | draft | Railiance, NetKingdom, State Hub | event taxonomy and tenant audit projection need storage decision |
| Incident response and recovery | draft | Railiance, NetKingdom | runbooks, tenant freeze, and revocation sweep need drills |
## Genesis Pattern Coverage
| Family | Exact patterns | Artifact coverage | Maturity spread |
| --- | ---: | --- | --- |
| Identity and access | 8 | complete | seed to reviewed |
| Tenant isolation | 6 | complete | seed to draft |
| Kubernetes and platform | 7 | complete | seed |
| Secrets and cryptography | 5 | complete | seed to reviewed |
| Application/API security | 6 | complete | seed to draft |
| Supply chain | 6 | complete | seed |
| Detection and response | 6 | complete | seed |
The authoritative per-pattern completion matrix is
`artifacts/generated/research-pattern-normalization.md`.
## NetKingdom Umbrella Pattern Index
| Pattern | Maturity | Owner | Implementation links |
| --- | --- | --- | --- |
| STS credential vending | reviewed | NetKingdom, flex-auth, Railiance platform | NK-WP-0007, ADR-0008, artifact-store follow-up |
| Workload identity | draft | Railiance platform, NetKingdom | IAM Profile, OpenBao Kubernetes auth |
| Secret zero avoidance | reviewed | NetKingdom, Railiance platform | NK-WP-0004, NK-WP-0005, Railiance OpenBao |
| Dynamic secrets | draft | OpenBao, Railiance platform | OpenBao leases and revocation |
| Short-lived SSH certificates | draft | ops-warden, ops-bridge, NetKingdom | SSH certificate issuance and audit |
| Delegated authorization | reviewed | flex-auth, NetKingdom | flex-auth, Topaz, CARING descriptors |
| Tenant isolation | draft | NetKingdom, Railiance platform, product repos | namespace, cluster, cell, data, and control-plane isolation |
| Policy-as-code admission | seed | Railiance platform, NetKingdom | admission policy, pod security, image trust |
| Supply-chain provenance | seed | Railiance platform, artifact-store, product repos | SBOM, signatures, SLSA provenance |
## Tutorial Handoff To NK-WP-0009
High-value tutorial candidates after NK-WP-0010 completion:
1. Vend temporary S3 credentials from a NetKingdom identity token.
2. Deploy OpenBao as canonical Railiance platform secrets manager.
3. Use short-lived SSH credentials for admins, agents, and automations.
4. Add a protected system to flex-auth using PDP/PEP boundaries.
5. Apply secret-zero avoidance from bootstrap to runtime OpenBao.
6. Build tenant audit visibility from the central audit ledger.
7. Add policy-as-code admission with pod-security and signed-image gates.
8. Produce SBOM, signature, and SLSA-style provenance for a release.
## Open Decisions And Gaps
- Decide durable audit ledger storage and tenant-visible audit boundary.
- Decide which seed patterns should graduate to reviewed before tutorial
writing starts.
- Decide how machine-readable capability and pattern status should be
represented.
- Decide which pattern families need product-specific conformance tests
before being marked canonical.

View File

@@ -0,0 +1,49 @@
# STS Credential Vending Extraction
Status: generated extraction from NetKingdom and Railiance source docs
## Extracted Claims
1. Object-storage credential vending must be identity-backed and
policy-approved before backend exchange.
2. flex-auth is the canonical authorization decision point for bucket,
prefix, action, TTL, tenant, and assurance decisions.
3. Provider-native temporary credentials are preferred when mature.
4. OpenBao may protect parent credentials, broker configuration, leases,
and audit records, but must not decide object-storage authorization.
5. Consumers must support session tokens and expiration-aware refresh.
6. Long-lived static credentials are transitional only.
7. Tenant administrators must not receive platform-root object-store or
OpenBao authority.
## Extracted Anti-Patterns
- object-store root credentials in application pods;
- access-key/secret-key-only production consumers with no session token;
- application repos as canonical bucket policy owners;
- OpenBao used as a substitute for flex-auth decisions;
- local-identity tokens accepted by production object-storage backends;
- fallback to root credentials when STS or flex-auth is unavailable.
## Extracted Evidence Needs
- IAM Profile issuer/audience validation.
- flex-auth decision record with stable reason codes.
- backend credential response with session token and expiration.
- OpenBao audit event where parent material or broker config is used.
- artifact-store or consumer refresh test.
- denial tests for wrong tenant, unregistered prefix, and excessive TTL.
## Candidate Tutorial
Title: Vend temporary S3 credentials from a NetKingdom identity token.
Tutorial path:
1. issue or obtain an IAM Profile token;
2. register protected system, bucket, and prefix in flex-auth;
3. request credentials from the vending service;
4. observe backend temporary credential response;
5. configure `artifact-store` or an SDK with session token;
6. verify refresh and audit correlation;
7. exercise deny cases.