generated from coulomb/repo-seed
Add security architecture pattern infospace
This commit is contained in:
@@ -0,0 +1,78 @@
|
||||
# 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?
|
||||
@@ -0,0 +1,58 @@
|
||||
# STS Credential Vending Relationship Map
|
||||
|
||||
Status: draft
|
||||
|
||||
## Purpose
|
||||
|
||||
This relation artifact spells out how the STS credential-vending pattern
|
||||
connects NetKingdom, Railiance, flex-auth, OpenBao, artifact-store, and
|
||||
future tutorials.
|
||||
|
||||
## Relationship Summary
|
||||
|
||||
```text
|
||||
IAM Profile
|
||||
identifies caller
|
||||
-> flex-auth
|
||||
authorizes tenant/resource/action/TTL
|
||||
-> credential-vending service
|
||||
normalizes backend-specific temporary credential exchange
|
||||
-> OpenBao
|
||||
protects parent material and audit/lease evidence where used
|
||||
-> object-storage backend
|
||||
issues temporary credentials
|
||||
-> artifact-store or other consumer
|
||||
refreshes and uses scoped credentials
|
||||
```
|
||||
|
||||
## Handoffs
|
||||
|
||||
| From | To | Handoff | Evidence |
|
||||
| --- | --- | --- | --- |
|
||||
| NetKingdom IAM Profile | credential-vending service | issuer, audience, subject, tenant, assurance claims | token validation test |
|
||||
| credential-vending service | flex-auth | protected system, bucket, prefix, action set, TTL, context | decision envelope |
|
||||
| flex-auth | Topaz | delegated PDP evaluation where used | policy load and decision log |
|
||||
| credential-vending service | OpenBao | parent credential access, broker config, lease/audit metadata | OpenBao audit event |
|
||||
| credential-vending service | backend STS/API | approved temporary credential request | backend response with expiration |
|
||||
| credential-vending service | artifact-store | normalized temporary credentials | `AWS_SESSION_TOKEN` and expiration-aware refresh |
|
||||
| artifact-store | audit sink | workload storage event with correlation id | workload audit record |
|
||||
| pattern catalog | NK-WP-0009 | tutorial candidate | tutorial backlog item |
|
||||
|
||||
## Required Edges In The Infospace Graph
|
||||
|
||||
- STS source docs seed the STS pattern.
|
||||
- STS pattern implements object-storage access capability.
|
||||
- STS pattern uses delegated authorization.
|
||||
- STS pattern uses OpenBao runtime secret authority.
|
||||
- STS pattern requires artifact-store session-token support.
|
||||
- STS pattern feeds NK-WP-0009 tutorial work.
|
||||
|
||||
## Open Questions
|
||||
|
||||
- Which backend is the first live exchange target: MinIO/AIStor, Ceph
|
||||
RGW, AWS, or Cloudflare R2?
|
||||
- Does the first implementation use a standalone service, controller, or
|
||||
CLI plus `credential_process`?
|
||||
- Where does durable cross-system audit correlation land?
|
||||
- Which claim shape should become the IAM Profile minimum for workload
|
||||
object-storage access?
|
||||
Reference in New Issue
Block a user