generated from coulomb/repo-seed
Add security architecture workplans
This commit is contained in:
168
workplans/NK-WP-0007-object-storage-sts-credential-vending.md
Normal file
168
workplans/NK-WP-0007-object-storage-sts-credential-vending.md
Normal file
@@ -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.
|
||||||
@@ -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.
|
||||||
143
workplans/NK-WP-0009-netkingdom-security-pattern-tutorials.md
Normal file
143
workplans/NK-WP-0009-netkingdom-security-pattern-tutorials.md
Normal file
@@ -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.
|
||||||
Reference in New Issue
Block a user