diff --git a/workplans/NK-WP-0007-object-storage-sts-credential-vending.md b/workplans/NK-WP-0007-object-storage-sts-credential-vending.md new file mode 100644 index 0000000..54b43ee --- /dev/null +++ b/workplans/NK-WP-0007-object-storage-sts-credential-vending.md @@ -0,0 +1,168 @@ +--- +id: NK-WP-0007 +type: workplan +title: Object Storage STS Credential Vending +domain: netkingdom +repo: net-kingdom +status: proposed +owner: codex +topic_slug: netkingdom +planning_priority: high +planning_order: 7 +created: 2026-05-17 +updated: 2026-05-17 +depends_on: + - NK-WP-0004 + - NK-WP-0005 + - NK-WP-0006 +state_hub_workstream_id: "3cbc81ec-7ad5-46cf-a4a0-fc5fe9873695" +--- + +# NK-WP-0007 - Object Storage STS Credential Vending + +## Goal + +Define and implement the canonical NetKingdom pattern for vending +short-lived object-storage credentials from verified identity and +policy decisions. + +The intended runtime shape is: + +1. key-cape or Keycloak issues and verifies NetKingdom IAM Profile + tokens. +2. flex-auth evaluates whether the subject may receive temporary S3 + credentials for a specific bucket, prefix, action set, TTL, and + assurance level. +3. A small object-storage credential-vending service exchanges the + approved identity for storage-native temporary credentials. +4. Consumers such as artifact-store use temporary credentials without + owning the security policy. + +## Context + +Artifact-store needs to consume S3-compatible credentials, but the +credential-vending authority belongs to NetKingdom's identity and +security architecture. The surrounding ecosystem matters: + +- key-cape is the lightweight NetKingdom IAM Profile implementation. +- Keycloak is the expanded-mode IAM implementation. +- Authelia, LLDAP, and privacyIDEA are backing components in the + lightweight stack, not object-storage policy owners. +- flex-auth owns policy-as-code decisions, resource/action vocabulary, + decision envelopes, delegated PDP adapters, and audit semantics. +- ops-warden and ops-bridge provide a useful precedent for short-lived + credentials and actor attribution, but they are SSH-specific and + should not be overloaded with object-storage credentials. +- Ceph RGW, MinIO/AIStor, AWS STS, and Cloudflare R2 are candidate + object-storage credential issuers. + +## Scope + +In scope: + +- define the object-storage credential-vending trust model +- define resource/action vocabulary for flex-auth +- define claim, audience, assurance, actor, tenant, bucket, prefix, + action, TTL, revocation, and audit requirements +- define lightweight-mode behavior with key-cape plus Authelia, LLDAP, + and privacyIDEA +- define expanded-mode behavior with Keycloak +- compare native STS paths for Ceph RGW, MinIO/AIStor, AWS STS, and + Cloudflare R2 +- decide whether the vendor is a standalone NetKingdom service, a small + controller, or a reusable library plus CLI +- create consumer guidance for artifact-store and other S3 clients + +Out of scope: + +- implementing artifact-store S3 adapter refresh behavior +- deploying the object-storage backend itself +- replacing flex-auth with provider-specific bucket policies +- putting object-storage policy inside key-cape, ops-warden, or + ops-bridge + +## Tasks + +```task +id: NK-WP-0007-T1 +status: todo +priority: high +state_hub_task_id: "3b50c48f-1ab2-4631-b176-d49d9d705f1e" +``` + +Document the target architecture in +`docs/object-storage-sts-credential-vending.md`, including actors, +trust boundaries, token flow, policy decision flow, credential lease +flow, and failure modes. + +```task +id: NK-WP-0007-T2 +status: todo +priority: high +state_hub_task_id: "5b942d22-6f29-4975-88fb-e3e5bcaf4029" +``` + +Define the flex-auth resource/action model for object storage: +protected-system id, bucket resources, prefix resources, actions +(`s3:GetObject`, `s3:PutObject`, `s3:DeleteObject`, listing, +multipart operations), TTL limits, obligations, and deny reasons. + +```task +id: NK-WP-0007-T3 +status: todo +priority: high +state_hub_task_id: "8d27e5b4-9bbb-4a53-a079-0df1047d755e" +``` + +Define the IAM Profile requirements for credential vending: +accepted issuers, audiences, service-account subjects, human/admin +subjects, MFA/assurance claims, emergency principals, and local-dev +issuer restrictions. + +```task +id: NK-WP-0007-T4 +status: todo +priority: medium +state_hub_task_id: "c0c4f297-6cff-419b-9ce3-be5537c92e93" +``` + +Assess backend STS implementations and write a decision record covering +Ceph RGW STS, MinIO/AIStor STS, AWS STS, Cloudflare R2 temporary +credentials, and whether OpenBao/Vault should broker any of these +directly. + +```task +id: NK-WP-0007-T5 +status: todo +priority: medium +state_hub_task_id: "ccb10b2d-6378-4824-90b1-c31bd882d93d" +``` + +Prototype the smallest credential-vending interface: CLI or HTTP +request shape, normalized response shape, lease metadata, audit event, +and a `credential_process`-compatible option for SDK consumers. + +```task +id: NK-WP-0007-T6 +status: todo +priority: medium +state_hub_task_id: "63c6859b-980e-44da-a5a6-b92a8a3225dd" +``` + +Create integration guidance for artifact-store and other consumers: +environment variables, `AWS_SESSION_TOKEN`, refresh behavior, sidecar or +controller refresh options, and prohibited patterns such as long-lived +root access keys. + +## Acceptance Criteria + +- NetKingdom has a canonical, provider-neutral pattern for object-storage + STS credential vending. +- flex-auth is the policy decision point for bucket/prefix/action/TTL + authorization. +- key-cape and Keycloak are treated as IAM Profile implementations, not + object-storage policy engines. +- ops-warden and ops-bridge remain SSH/tunnel-specific but their + short-lived credential lessons are reused where appropriate. +- artifact-store has enough guidance to consume temporary credentials + without owning the vending authority. diff --git a/workplans/NK-WP-0008-it-security-architecture-patterns-infospace.md b/workplans/NK-WP-0008-it-security-architecture-patterns-infospace.md new file mode 100644 index 0000000..3e1ee1f --- /dev/null +++ b/workplans/NK-WP-0008-it-security-architecture-patterns-infospace.md @@ -0,0 +1,136 @@ +--- +id: NK-WP-0008 +type: workplan +title: IT Security Architecture Patterns Infospace +domain: netkingdom +repo: net-kingdom +status: proposed +owner: codex +topic_slug: netkingdom +planning_priority: high +planning_order: 8 +created: 2026-05-17 +updated: 2026-05-17 +depends_on: + - NK-WP-0006 +state_hub_workstream_id: "053c6d96-9396-40c9-a2e5-c36531e7810d" +--- + +# 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. + +## Scope + +In scope: + +- define a pattern document template +- create an infospace directory under `docs/security-patterns/` +- capture initial patterns and their NetKingdom mapping +- 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 +- replacing ADRs +- duplicating vendor documentation +- writing full tutorials; tutorials are handled by NK-WP-0009 + +## Tasks + +```task +id: NK-WP-0008-T1 +status: todo +priority: high +state_hub_task_id: "d1b7213c-3315-49d2-90c9-efdf2bea3563" +``` + +Define the security-pattern infospace structure and template: +problem, forces, applicability, threat model, canonical NetKingdom +mapping, implementation variants, operational checks, audit hooks, +anti-patterns, and references. + +```task +id: NK-WP-0008-T2 +status: todo +priority: high +state_hub_task_id: "59966187-27f1-4b9c-9dfc-e59d11ff115c" +``` + +Create initial pattern entries for: STS credential vending, workload +identity, secret zero avoidance, dynamic secrets, short-lived SSH +certificates, delegated authorization, break-glass access, and +policy-as-code. + +```task +id: NK-WP-0008-T3 +status: todo +priority: medium +state_hub_task_id: "927c08a5-1a7e-4634-a514-0f562e286708" +``` + +Map each pattern to NetKingdom/Railiance repos and components: +net-kingdom, key-cape, flex-auth, ops-warden, ops-bridge, +railiance-platform, artifact-store, Keycloak, Authelia, LLDAP, +privacyIDEA, OpenBao, Ceph RGW, and MinIO-compatible stores. + +```task +id: NK-WP-0008-T4 +status: todo +priority: medium +state_hub_task_id: "884626ea-243e-4806-9267-77ef643158b7" +``` + +Create an index page with pattern status, maturity, owning repo, +implementation links, and open decisions. + +```task +id: NK-WP-0008-T5 +status: todo +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, and failure-mode behavior. + +## Acceptance Criteria + +- `docs/security-patterns/` exists with a repeatable pattern template. +- 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. diff --git a/workplans/NK-WP-0009-netkingdom-security-pattern-tutorials.md b/workplans/NK-WP-0009-netkingdom-security-pattern-tutorials.md new file mode 100644 index 0000000..9fe60a8 --- /dev/null +++ b/workplans/NK-WP-0009-netkingdom-security-pattern-tutorials.md @@ -0,0 +1,143 @@ +--- +id: NK-WP-0009 +type: workplan +title: NetKingdom Security Pattern Tutorials +domain: netkingdom +repo: net-kingdom +status: proposed +owner: codex +topic_slug: netkingdom +planning_priority: medium +planning_order: 9 +created: 2026-05-17 +updated: 2026-05-17 +depends_on: + - NK-WP-0008 +state_hub_workstream_id: "66c9f1e9-6b2f-454b-a6d4-04e5fe42385a" +--- + +# NK-WP-0009 - NetKingdom Security Pattern Tutorials + +## Goal + +Build practical tutorials that show operators and developers how to +implement canonical NetKingdom security architecture patterns in +NetKingdom-enabled IT infrastructures. + +Where NK-WP-0008 is the pattern library, this workplan is the hands-on +path: runnable examples, checklists, commands, manifests, verification +steps, and failure-mode exercises. + +## Context + +The platform needs more than architecture statements. A new deployment +should be able to answer: + +- How do I issue identity tokens in lightweight mode versus expanded + mode? +- How do I ask flex-auth for a resource decision? +- How do I vend temporary object-storage credentials? +- How do I deploy OpenBao and avoid secret zero traps? +- How do I use short-lived SSH certificates for agents and automations? +- How do I verify audit records and break-glass behavior? + +Tutorials turn canonical patterns into repeatable implementation +practice without forcing every application repo to rediscover the same +steps. + +## Scope + +In scope: + +- tutorial structure and style guide +- runnable or copy-pasteable examples +- local/dev and production variants where appropriate +- verification and rollback steps +- integration references to key-cape, flex-auth, ops-warden, + ops-bridge, railiance-platform, and artifact-store + +Out of scope: + +- deploying live services directly from this repo +- replacing repo-specific operator runbooks +- hiding provider-specific security differences behind one generic + command + +## Tasks + +```task +id: NK-WP-0009-T1 +status: todo +priority: high +state_hub_task_id: "79150b07-f25d-4407-a118-e08b6e588d37" +``` + +Create a tutorial template with prerequisites, architecture context, +commands, manifests, verification, rollback, threat checks, and +cross-repo ownership notes. + +```task +id: NK-WP-0009-T2 +status: todo +priority: high +state_hub_task_id: "07647ba6-90e1-4569-947a-ebccce7a2d5e" +``` + +Write the first tutorial: "Vend temporary S3 credentials from a +NetKingdom identity token", covering key-cape/Keycloak identity, +flex-auth authorization, object-store STS exchange, and SDK consumer +configuration. + +```task +id: NK-WP-0009-T3 +status: todo +priority: high +state_hub_task_id: "0f34eda3-f1f3-4c49-9eba-36167b6c5ea9" +``` + +Write "Deploy OpenBao as the canonical secrets manager for a +NetKingdom-enabled Railiance platform", linking to the Railiance +Platform workplan and covering auth methods, secret engines, CSI/ESO +integration, leases, unseal, backup, and break-glass. + +```task +id: NK-WP-0009-T4 +status: todo +priority: medium +state_hub_task_id: "3c17d1ac-3232-43b4-b541-ea6538da2afb" +``` + +Write "Use short-lived SSH credentials for admins, agents, and +automations", using ops-warden and ops-bridge as the reference +implementation. + +```task +id: NK-WP-0009-T5 +status: todo +priority: medium +state_hub_task_id: "aff82173-0b8e-4216-855a-887ac68b63e0" +``` + +Write "Add a protected system to flex-auth", covering resource +manifests, action vocabulary, claim envelopes, policy packages, +decision envelopes, and delegated PDP options. + +```task +id: NK-WP-0009-T6 +status: todo +priority: medium +state_hub_task_id: "df427aa3-233f-4479-aed9-706676f8e87d" +``` + +Add tutorial verification fixtures or checklists so each tutorial has a +clear "done when" outcome and does not become prose-only guidance. + +## Acceptance Criteria + +- Tutorials are grouped under a stable docs path with a repeatable + format. +- Each tutorial maps back to one or more NK-WP-0008 patterns. +- Tutorials name the owning repo for every concrete implementation + step. +- Tutorials include verification and rollback guidance, not just happy + path commands.