Reconcile infrastructure workplans and retire stale flex-auth references

Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a0e77d-47a4-7771-8e34-7339c7fac0e4
This commit is contained in:
tegwick 2026-09-28 12:40:03 +02:00
parent 019e8f21a7
commit 9383b94019
12 changed files with 494 additions and 149 deletions

View file

@ -11,7 +11,7 @@ topic_slug: netkingdom
planning_priority: medium
planning_order: 9
created: 2026-05-17
updated: 2026-07-08
updated: "2026-09-28"
depends_on:
- NK-WP-0008
state_hub_workstream_id: "d4d02dbf-3974-502d-8b87-b776fc63e17e"
@ -64,7 +64,7 @@ Out of scope:
- hiding provider-specific security differences behind one generic
command
## Tasks
## Create the tutorial template
```task
id: NK-WP-0009-T01
@ -77,6 +77,8 @@ Create a tutorial template with prerequisites, architecture context,
commands, manifests, verification, rollback, threat checks, and
cross-repo ownership notes.
## Demonstrate temporary object credentials
```task
id: NK-WP-0009-T02
status: todo
@ -89,6 +91,8 @@ NetKingdom identity token", covering key-cape/Keycloak identity,
flex-auth authorization, object-store STS exchange, and SDK consumer
configuration.
## Document the existing OpenBao operating path
```task
id: NK-WP-0009-T03
status: todo
@ -101,6 +105,8 @@ 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.
## Document SSH certificates and tunnels
```task
id: NK-WP-0009-T04
status: todo
@ -112,6 +118,8 @@ Write "Use short-lived SSH credentials for admins, agents, and
automations", using ops-warden and ops-bridge as the reference
implementation.
## Integrate a protected flex-auth consumer
```task
id: NK-WP-0009-T05
status: todo
@ -123,6 +131,8 @@ Write "Add a protected system to flex-auth", covering resource
manifests, action vocabulary, claim envelopes, policy packages,
decision envelopes, and delegated PDP options.
## Verify the tutorial outcomes
```task
id: NK-WP-0009-T06
status: todo
@ -142,3 +152,22 @@ clear "done when" outcome and does not become prose-only guidance.
step.
- Tutorials include verification and rollback guidance, not just happy
path commands.
## Infrastructure review — 2026-09-28
Keep this plan in backlog, with the first implementation slice T01 + T03 +
T04 + T06: document the paths already operated and capture safe verification
and recovery outcomes. OpenBao is already deployed and private; T03 should
teach consumption, attended access and recovery, with greenfield deployment
kept as an isolated lab exercise. Use the named `openbao-ui-railiance01`
tunnel and owner runbooks, not a public Bao URL or copied runtime manifest.
T02 is conditional on an owner-backed object-store STS issuer and refusal/lease
proof; ADR-0008 is architecture, not evidence that the endpoint is live. T05
must include projected caller identity, audience, binding and unauthorized
caller rejection: all six live consumers now enforce caller authentication.
Use accepted IAM v0.3 and owner package declarations under ADR-0015. T06
requires executable safe fixtures or repeatable outcome checks; never teach
operators to apply the stale tenant-engine reference YAML.
Evidence and cross-plan priorities: [estate review](../history/2026-09-28-open-workplan-infrastructure-review.md).

View file

@ -9,7 +9,7 @@ flavor: implementation
owner: worsch
topic_slug: netkingdom
created: "2026-05-20"
updated: "2026-07-08"
updated: "2026-09-28"
state_hub_workstream_id: "1075448f-d533-5f9e-94b7-c3adfe151a07"
depends_on:
- NK-WP-0003
@ -53,10 +53,10 @@ Keycloak as the internal user store. None of those assumptions hold now:
| NK-WP-0001 assumption | Current reality | Effect on this plan |
|---|---|---|
| HashiCorp Vault, bootstrapped from KeePassXC | **OpenBao** is the runtime secret authority (NK-WP-0006); SOPS/age + agent bootstrap exist (NK-WP-0004/0005) | Keycloak DB + admin secrets come from OpenBao via ESO; no new vault bootstrap |
| PostgreSQL built from scratch | CloudNativePG running on RAILIANCE01 (NK-WP-0003) | Add `keycloak_db` to the existing operator, reuse backup pattern |
| PostgreSQL built from scratch | CloudNativePG running on RAILIANCE01 (NK-WP-0003) | Admit a database consumer through current platform owners; prove backup/restore |
| Keycloak is the internal source of truth (D2 hybrid) | KeyCape lightweight stack is the *deployed* IAM Profile issuer | Keycloak is a **broker/federation front-end**, not the primary user store |
| Authorization via Keycloak Authorization Services | flex-auth + Topaz is the canonical PDP (ADR-0006) | Keycloak AuthZ Services is at most an optional adapter, never canonical |
| Single-tenant Coulomb deployment | Recursive `tenant:platform` vs `tenant:coulomb` model (NK-WP-0006) | Realm-per-tenant; tenant admins must not receive platform-root |
| Single-tenant Coulomb deployment | Recursive `tenant:platform` vs `tenant:coulomb` model (NK-WP-0006) | Evaluate realm-per-tenant; tenant admins must not receive platform-root |
| MFA solely via privacyIDEA provider JAR | privacyIDEA deployed *and* upstream IdPs carry their own MFA | MFA assurance source becomes a decision, not a default |
## Architecture
@ -68,7 +68,7 @@ Keycloak as the internal user store. None of those assumptions hold now:
└──────────────┼──────────────┘
▼
[ Keycloak ] expanded-mode broker
│ realm-per-tenant; IAM Profile issuer
│ realm-per-tenant candidate; IAM Profile issuer
│ secrets ← OpenBao (ESO)
│ MFA ← privacyIDEA *or* upstream assurance
▼
@ -77,7 +77,7 @@ Keycloak as the internal user store. None of those assumptions hold now:
├──► applications (depend on the Profile, not the provider)
└──► flex-auth / Topaz ── authorization decision (PDP)
coexists with: KeyCape lightweight issuer (id.coulomb.social)
coexists with: KeyCape lightweight issuer (kc.coulomb.social)
```
Keycloak answers identity (who, how authenticated, coarse claims,
@ -90,10 +90,10 @@ OpenBao.
In scope:
- decision record for expanded-mode adoption: trigger, federation
topology (broker vs SAML SP), realm-per-tenant model, and coexistence
topology (broker vs SAML SP), realm isolation model, and coexistence
with the KeyCape lightweight issuer
- custom Keycloak image (privacyIDEA provider JAR if MFA is delegated to
privacyIDEA) and Helm deployment on RAILIANCE01
- owner-packaged Keycloak image (privacyIDEA provider JAR only if selected
and verified compatible) and managed deployment on railiance01
- upstream federation: Entra ID (OIDC), AD (LDAP), generic SAML 2.0 IdP
- claim mapping to the NetKingdom IAM Profile (issuer, audience, subject,
groups, tenant, assurance evidence) and IAM Profile conformance checks
@ -112,7 +112,7 @@ Out of scope:
- tenant-specific federation policy for tenants beyond `tenant:platform`
and `tenant:coulomb`
## Tasks
## Decide federation adoption and topology
```task
id: NK-WP-0011-T01
@ -125,11 +125,14 @@ priority: high
an ADR (ADR-0009) capturing: the concrete trigger for switching a tenant
from lightweight to expanded mode; whether Keycloak acts as an OIDC
identity broker, a SAML service provider, or both; the realm-per-tenant
mapping onto `tenant:platform` / `tenant:coulomb`; how the Keycloak issuer
coexists with the KeyCape issuer (`id.coulomb.social`) so applications
candidate and its alternatives mapped onto `tenant:platform` /
`tenant:coulomb`; how the Keycloak issuer
coexists with the KeyCape issuer (`kc.coulomb.social`) so applications
still target one IAM Profile contract; and the canonical hostname/issuer
for the broker. Resolve or supersede D2 from NK-WP-0001.
## Admit the database consumer
```task
id: NK-WP-0011-T02
state_hub_task_id: "2fe6f100-3a5d-563e-b033-7d7b846ae487"
@ -137,12 +140,15 @@ status: todo
priority: high
```
**PostgreSQL `keycloak_db` on the existing operator.** Add a `keycloak`
database and role to the CloudNativePG instance from NK-WP-0003 (do not
deploy a new database). Source credentials from OpenBao via ESO into a K8s
Secret. Confirm the existing backup schedule covers the new database and
**PostgreSQL `keycloak_db` on the existing operator.** Have railiance-platform
and rapp-postgres admit a named Keycloak database consumer against the current
database catalog and isolation needs. Do not assume the historical NK-WP-0003
instance is the correct placement. Source credentials from OpenBao via ESO
into a K8s Secret. Confirm the existing backup schedule covers the new database and
run a restore drill for `keycloak_db` specifically.
## Package the broker deployment
```task
id: NK-WP-0011-T03
state_hub_task_id: "32d1411b-10a4-5a8b-8f43-99ac46d83908"
@ -152,12 +158,15 @@ priority: high
**Deploy expanded-mode Keycloak.** Build a custom image
(`kc.sh build`, privacyIDEA provider JAR included only if T5 delegates MFA
to privacyIDEA). Deploy via plain Helm on RAILIANCE01 behind Traefik +
to privacyIDEA). Assign the package/runtime owner under ADR-0015 and deploy
through its managed declaration on railiance01 behind Traefik +
cert-manager at the issuer hostname from T1. Admin bootstrap secret and DB
secret come from OpenBao/ESO — never typed, never in git. Hostname
strictness + proxy headers configured for Traefik. Realm import is
GitOps-friendly (realm JSON/CR in git).
## Integrate an upstream identity provider
```task
id: NK-WP-0011-T04
state_hub_task_id: "6697a994-7343-5ea8-8b37-bc3b921e5a9b"
@ -172,6 +181,8 @@ audience, subject, groups, **tenant**, and assurance evidence. Define the
attribute/claim mappers and group→role mapping. Verify a federated login
end-to-end for at least the Entra ID path.
## Define federated assurance
```task
id: NK-WP-0011-T05
state_hub_task_id: "d845380d-3dbc-5e59-8f2b-5a4d1b32d89d"
@ -187,6 +198,8 @@ evidence in the token. Require step-up for admin console and
platform-root-sensitive clients. Ensure assurance evidence is carried in
the IAM Profile token so flex-auth can gate privileged actions on it.
## Verify IAM conformance and coexistence
```task
id: NK-WP-0011-T06
state_hub_task_id: "9cb7fd93-c16e-5102-83ce-195b3aa87446"
@ -199,9 +212,11 @@ conformance checks against the Keycloak issuer (discovery document, PKCE,
token/claim shape, JWKS, userinfo). Verify an application configured for
the IAM Profile can authenticate against either the KeyCape or the
Keycloak issuer per the T1 selection rule. Use the canonical
`canon/standards/iam-profile_v0.2.md` contract and the executable suite in
`canon/standards/iam-profile_v0.3.md` contract and the executable suite in
`tools/iam-profile-conformance/`. Document per-tenant issuer selection.
## Enforce tenant and platform boundaries
```task
id: NK-WP-0011-T07
state_hub_task_id: "38998c68-29bf-50d2-8c8d-0c75184d5833"
@ -209,14 +224,17 @@ status: todo
priority: high
```
**Recursive tenancy & authorization boundary.** Implement realm-per-tenant
with platform-root guardrails: tenant admins manage only their realm and
**Recursive tenancy & authorization boundary.** Implement T1's reviewed
realm/tenant topology with platform-root guardrails. If realm-per-tenant is
selected, tenant admins manage only their realm; in every topology they
must not be able to alter IAM Profile semantics, the platform realm,
federation trust, OpenBao platform mounts, or audit retention (per the
flex-auth/Topaz implications in the architecture doc). Confirm flex-auth +
Topaz remains the PDP; if a Keycloak Authorization Services adapter is
used at all, document it as a delegated, non-canonical adapter.
## Prove recovery and audit delivery
```task
id: NK-WP-0011-T08
state_hub_task_id: "e5f44ddc-9645-5f61-b84c-da5ab9cccb6d"
@ -224,8 +242,9 @@ status: todo
priority: medium
```
**Backups, DR, break-glass, monitoring, audit.** Realm exports to git; DB
backup + restore drill (T2); break-glass admin path disabled-by-default
**Backups, DR, break-glass, monitoring, audit.** Only sanitized declarative
realm configuration belongs in git; keep credential-bearing exports in
protected backup custody; DB backup + restore drill (T2); break-glass admin path disabled-by-default
with alerting on use; Prometheus/Grafana for auth success/failure, MFA
latency, federation errors. Ship Keycloak events to the durable platform
audit sink alongside flex-auth/Topaz/OpenBao records, with correlation
@ -235,7 +254,7 @@ production-readiness checklist.
## Acceptance Criteria
- An ADR records the expanded-mode trigger, federation topology,
realm-per-tenant model, and KeyCape/Keycloak issuer coexistence.
selected realm/tenant isolation model, and KeyCape/Keycloak issuer coexistence.
- A federated user from at least one enterprise IdP (Entra ID) can log in
and receive an IAM Profile-conformant token with tenant + assurance
claims.
@ -257,5 +276,25 @@ production-readiness checklist.
- **railiance-platform**: OpenBao must expose a Keycloak auth role / ESO
path before T3; unseal/break-glass story must be ready.
- **IAM Profile spec**: resolved by NK-WP-0012. T6 consumes
`canon/standards/iam-profile_v0.2.md` and
`canon/standards/iam-profile_v0.3.md` and
`tools/iam-profile-conformance/`.
## Infrastructure review — 2026-09-28
Keep in backlog until a named enterprise tenant, upstream IdP owner and
concrete federation need justify operating another issuer. No Keycloak
Deployment appears in today's cluster inventory. Realm-per-tenant remains a
proposal to evaluate in T01, not a requirement derived from current topology;
prove its mapping to tenant-engine's canonical identity/lifecycle contract.
The live issuer is `https://kc.coulomb.social`; IAM v0.3 is accepted and v0.4
step-up is proposed. T01/T05/T06 must coordinate with NK-WP-0042 and preserve
existing issuer/subject account bindings, audiences and session/revocation
behavior. Do not infer equivalent assurance from an upstream MFA claim without
a reviewed trust mapping. The single-node cluster and single-instance database
providers offer no automatic HA guarantee. T02/T08 must name backup ownership,
off-host custody and an isolated restore proof. OpenBao access is private via
the platform operator path. Resource placement, packaging and runtime
execution belong to their owners, not this canon repository.
Evidence and cross-plan priorities: [estate review](../history/2026-09-28-open-workplan-infrastructure-review.md).

View file

@ -9,7 +9,7 @@ flavor: implementation
owner: codex
topic_slug: netkingdom
created: "2026-07-27"
updated: "2026-08-08"
updated: "2026-09-28"
depends_on:
- USER-WP-0020
- NK-WP-0023
@ -24,16 +24,18 @@ CoulombCore (`92.205.130.254`) to railiance01 (`92.205.62.239`) without
losing users, groups, MFA enrollments, signing/encryption material, or the
ability to roll back.
The two servers currently run independent copies of KeyCape, Authelia, LLDAP,
privacyIDEA, and `net-kingdom-pg`. Public KeyCape DNS already points to
railiance01, while Authelia, LLDAP, and privacyIDEA DNS still points to
CoulombCore. Retirement is forbidden until state equivalence, end-to-end
login, backup restoration, and an observed rollback window pass.
At the July 27 migration baseline, the two servers ran independent copies of
KeyCape, Authelia, LLDAP,
privacyIDEA, and `net-kingdom-pg`. At that baseline, public KeyCape DNS pointed to
railiance01 while other identity names still pointed to CoulombCore.
T06/T07 below supersede that topology: identity cutover and reversible
retirement completed on July 30 after the recorded migration gates passed.
Final deletion still requires the separate T08 recovery and approval gates.
This cutover intentionally waits until the reusable user onboarding portal
completes the Binky tenant-admin flow. That supplies the human login/MFA and
lifecycle evidence needed to judge which identity stack is authoritative
before state migration or retirement begins.
The original cutover intentionally waited for the reusable user onboarding
portal to complete the Binky tenant-admin flow. That supplied the human
login/MFA and lifecycle evidence used to establish identity authority before
state migration and reversible retirement.
## T01 - Freeze the migration contract and inventory both stacks
@ -313,11 +315,12 @@ runbooks. Run `statehub fix-consistency`.
Done when railiance01 is the sole authoritative identity stack, all evidence
is reconciled, and the workplan is marked finished.
Retention gate: keep the reversible CoulombCore identity resources through at
least 2026-08-29. The workplan is blocked until that review date, when T08 can
be checked for readiness to finish. Reaching the date does not authorize
deletion or completion: T08 still requires a successful railiance01
restore/restart drill and new explicit approval for destructive deletion.
Retention minimum: 2026-08-29 has passed. The plan is no longer date-blocked.
T08 remains blocked on a scoped retained-resource inventory, a successful
identity restore/restart receipt, and explicit destructive approval.
Elapsed retention alone does not authorize deletion or completion: T08 still
requires a successful railiance01 restore/restart drill and new explicit
approval for destructive deletion.
## Safety gates
@ -328,3 +331,15 @@ restore/restart drill and new explicit approval for destructive deletion.
- No PVC/database/Secret deletion as part of the reversible retirement step.
- Final deletion always requires an explicit human approval distinct from DNS
cutover approval.
## Infrastructure review — 2026-09-28
Live read-only inventory confirms the identity services on railiance01 are
ready. CoulombCore was not inspected in this review; do not infer that its
retained resources have been deleted. Recheck the exact retained identity
resources and backup custody before preparing the T08 deletion list. A generic
platform-pg recovery drill is not a restore of LLDAP, Authelia, privacyIDEA
with its encryption material, and identity database state. Whole-host retirement
and other owners' workloads remain outside this identity-only deletion gate.
Evidence and cross-plan priorities: [estate review](../history/2026-09-28-open-workplan-infrastructure-review.md).

View file

@ -10,7 +10,7 @@ owner: net-kingdom
topic_slug: netkingdom
planning_priority: P1
created: "2026-08-19"
updated: "2026-08-22"
updated: "2026-09-28"
state_hub_workstream_id: "965ad365-6b81-50a1-a2a3-2d0c1fcce0b4"
---
@ -250,3 +250,20 @@ ordinary next input.
authoritative workload ids and fail-safe exception evaluation
- `docs/reef-posture-provider-contract.md` — concrete T02/T03 carrier and join
proposal awaiting reef-owner agreement
## Infrastructure review — 2026-09-28
The current `reef-railiance/declarations/reef.yaml` still has no
`posture_provider` block. Its `ownership_repo` is `railiance-infra`: involve
that substrate owner alongside repo-manager (carrier/schema) in T02. The live
cluster has one Ready node; all eight CNPG clusters report one instance. This
supports retaining the single-failure-domain constraint, not assigning a new
V level from replica counts. T02/T03 stay `wait`.
InfoTechCanon Data Model §11.23 explicitly lists `public`; ops-warden
`registry/policy/security-posture.yaml` still has no public maturity floor.
The missing artifact is an owner-agreed mapping separating disclosure class
from synthetic provenance, not proof that public exists. T06 stays `wait`;
no `public -> synthetic` alias or guessed M1 floor is permitted.
Evidence and cross-plan priorities: [estate review](../history/2026-09-28-open-workplan-infrastructure-review.md).

View file

@ -10,7 +10,7 @@ owner: codex
topic_slug: netkingdom
planning_priority: P1
created: "2026-08-23"
updated: "2026-08-23"
updated: "2026-09-28"
state_hub_workstream_id: "9d7b04f9-3803-5613-b7a5-8bd606c77f5a"
---
@ -116,3 +116,20 @@ Verification on 2026-08-23:
Local implementation is complete. The workplan remains blocked only on T04's
externally owned audit-core declaration adoption.
## Infrastructure review — 2026-09-28
`audit-core/tenancy.yaml` still lacks machine-readable authoritative owner
and E2 freshness metadata. Its E2 prose retains the August 22 receipt and
24-hour replacement deadline; report freshness as `unknown` until the required
fields exist, without renewing that evidence from prose. The September 24
receiver/database recreate evidence supports V1 only and cannot refresh E2.
T04 remains `wait`; request the source declaration update and evaluate it with
an explicit current `--as-of` before closure.
The same declaration still describes flex-auth as unauthenticated A0, whereas
today all six live flex-auth Deployments pass `--caller-auth-mode enforce`.
The audit-core owner should reconcile that rationale against actual caller
bindings and policy evidence; deployment flags alone do not prove a new A level.
Evidence and cross-plan priorities: [estate review](../history/2026-09-28-open-workplan-infrastructure-review.md).

View file

@ -4,12 +4,12 @@ type: workplan
title: "Admit the operator-tunneled OpenBao browser callback"
domain: infotech
repo: net-kingdom
status: blocked
status: finished
flavor: implementation
owner: codex
topic_slug: net-kingdom
created: "2026-08-23"
updated: "2026-08-23"
updated: "2026-09-28"
related:
- RMASTER-WP-0020-T09
- RAILIANCE-WP-0027-T03
@ -68,7 +68,7 @@ or Secret value was observed.
```task
id: NK-WP-0032-T03
status: wait
status: done
priority: high
state_hub_task_id: "73b77110-2d4f-527e-98eb-2ec33897681e"
```
@ -82,7 +82,7 @@ query, browser storage, or role response body.
```task
id: NK-WP-0032-T04
status: wait
status: done
priority: high
state_hub_task_id: "f62bda4a-7607-5c50-9e04-664cc1b829ac"
```
@ -91,3 +91,24 @@ After T02 and T03 pass, perform one attended MFA login through
`http://127.0.0.1:18200` and return only the success/failure outcome. This task
does not authorize public Ingress retraction; Railiance Platform retains that
separate guarded hold point.
## Infrastructure review — 2026-09-28
T03 and T04 are complete from existing owner evidence; no new attended login
or role write is needed for this reconciliation. Railiance Platform
`docs/evidence/2026-09-15-openbao-loopback-callback-already-present.json`
proves the exact callback already present, Warden exit 0 and session revocation.
`docs/evidence/2026-09-15-openbao-public-listener-retract.json` records successful
operator loopback MFA, private HTTP 200, gateway readiness and public Ingress
retraction. `RPF-WP-0025` closure on September 22 records the handoff to
Railiance Master. These receipts discharge the original role and login gates.
Today the gateway and OpenBao are ready, their Services are ClusterIP, and the
openbao namespace has no Ingress. The September 24 callback-prune receipt
retired the public callbacks; current NetKingdom client source also forbids
their return. T01's bounded rollback requirement is historical, not an
instruction to restore public callbacks. DNS withdrawal remains the
railiance-infra owner residual described by RPF-WP-0025; this review does not
claim it is complete or authorize a listener change.
Evidence and cross-plan priorities: [estate review](../history/2026-09-28-open-workplan-infrastructure-review.md).

View file

@ -9,7 +9,7 @@ flavor: implementation
owner: claude-code
topic_slug: netkingdom
created: "2026-09-23"
updated: "2026-09-23"
updated: "2026-09-28"
related: [FLEX-WP-0020, FLEX-DEC-2026-013, NK-WP-0026]
state_hub_workstream_id: "284a8ac2-61dc-5bee-b74a-0a62d9808edb"
---
@ -40,7 +40,7 @@ Read-only check on railiance01 (node `92.205.62.239`) on 2026-09-23. The
`flex-auth-`. Every one pulls
`forgejo.coulomb.social/coulomb/flex-auth@sha256:…`.
NetKingdom declares two of them in `sso-mfa/k8s/tenant-engine/runtime.yaml`
At the September 23 inventory, NetKingdom declared two of them in `sso-mfa/k8s/tenant-engine/runtime.yaml`
(`flex-auth-tenant-engine`, `flex-auth-user-engine`). Everything else under
`sso-mfa/k8s/**` that names flex-auth is a runtime name that stays: the
namespace, Service DNS `flex-auth-user-engine.flex-auth.svc.cluster.local`,
@ -63,8 +63,8 @@ Resolved 2026-09-23 (flex-auth reply `28d9c6ca`): live is correct. `05a03a87`
was promoted 2026-09-11 for NK-WP-0036-T03 (flex-auth evidence
`docs/evidence/2026-09-11-user-portal-tenant-policy.md`); `138aa347` has been
live since 2026-08-19 (FLEX-WP-0015-T02). flex-auth's source of truth is
`values/<consumer>.yaml` in flex-auth. `runtime.yaml` now declares the live
digests. See T04 for the rest of the drift.
`values/<consumer>.yaml` in flex-auth. `runtime.yaml` was updated to those live
digests. T04 later removes the obsolete flex-auth reference objects entirely.
## Confirm the image-pull path survives the rename
@ -98,17 +98,16 @@ priority: medium
state_hub_task_id: "6e62919d-117d-57ab-b55b-1b437a105402"
```
Once flex-auth announces that `coulomb/access-engine` resolves, update
references to the repository coordinate. If the image coordinate
changes, update the two image pins in `sso-mfa/k8s/tenant-engine/runtime.yaml`
in the same change as the digest reconciliation from T01. Applying that live
needs the founder's go-ahead. Leave runtime names and historical records
unchanged.
Once flex-auth announces that `coulomb/access-engine` resolves, verify
repository-coordinate references against the retained runtime/package contract.
T02 confirms image coordinates stay unchanged; do not schedule image-pin
changes or a rollout as part of this rename. Leave historical records intact.
After T02, no in-repo coordinate reference needs to change: the image pins
stay, and NK-WP-0026 is a historical record. This task waits only for
flex-auth's announcement that `access-engine` resolves, which confirms that
nothing else moved.
T04 now introduces explicit owner-repository links in
`sso-mfa/k8s/tenant-engine/README.md` and a repository coordinate in the YAML
header. After the rename announcement, update these pointers to the confirmed
new repository/checkout, verify both value-file paths resolve and preserve the
runtime/package names. NK-WP-0026 remains a historical record.
## Retire or reconcile the stale flex-auth/tenant-engine reference manifest
@ -119,7 +118,7 @@ priority: high
state_hub_task_id: "2541f523-e433-5900-b119-5825f0e71ef3"
```
**Waiting 2026-09-27.** Routed the retire-vs-reconcile question to flex-auth
**Historical hold, superseded in part by the September 28 review below.** Routed the retire-vs-reconcile question to flex-auth
(`2c637dc9-14ad-4815-aeb4-43254d01280c`) and tenant-engine
(`9fc740da-1966-4d39-a28a-79fd4870edb1`). NetKingdom will act on whichever
answer comes back (retire and point to their authoritative declarations, or
@ -137,3 +136,42 @@ would drop caller-auth enforcement.
Decide with flex-auth and tenant-engine whether NetKingdom keeps a reference
copy. The recommendation is to replace it with pointers to the owners'
declarations (ADR-0015) rather than reconcile it field by field.
### Implementation — 2026-09-28
The approved flex-auth portion is complete. Removed seven reference objects:
the flex-auth Namespace and both consumers' Deployment, Service and
NetworkPolicy objects. Added exact links to `flex-auth/values/tenant-engine.yaml`,
`flex-auth/values/user-engine.yaml` and `charts/flex-auth` in the adjacent README.
Their caller enforcement and bindings stay owned by those declarations.
The five tenant-engine objects are structurally unchanged and retain the
DO-NOT-APPLY header. Repository script/workflow/Makefile searches found no
consumer of this combined manifest; the user-engine verifier uses its own
separate runtime file. Parsed before/after YAML proves only the seven approved
objects were removed. Owner links resolve locally and both value files declare
`callerAuth.mode: enforce`. No cluster apply, rollout or runtime rename occurred.
T04 returns to `wait` solely for tenant-engine's disposition of its remaining
objects; T03 waits for the repository rename. With no remaining locally
executable task in this plan, its status is `blocked` again.
## Infrastructure review — 2026-09-28
Flex-auth replied September 27 in message
`77b26d1e-550b-4926-9610-44fc3a566273`: no objection to replacing its
reference objects with pointers to authoritative `values/<consumer>.yaml`.
At the review baseline, T04 had a locally actionable flex-auth portion and
was `todo`; the plan was `active`. The implementation above supersedes that
status. Preserve the DO-NOT-APPLY guard. Retire only those flex-auth reference
objects when implementing that portion, with exact owner pointers and a check
that no application path consumes them. Tenant-engine's portion still awaits
its owner answer; do not treat flex-auth's response as authority over it.
T04 closes only when both portions are resolved.
Live read-only checks confirm all six flex-auth Deployments are ready and
enforce caller authentication. Applying the stale reference would risk losing
that protection. FLEX-WP-0020 still holds rename execution at T06; T03 stays
`wait`, independently of this reference cleanup.
Evidence and cross-plan priorities: [estate review](../history/2026-09-28-open-workplan-infrastructure-review.md).

View file

@ -9,7 +9,7 @@ flavor: planning
owner: claude-code
topic_slug: netkingdom
created: "2026-09-23"
updated: "2026-09-24"
updated: "2026-09-28"
related: [RCLK-WP-0002]
state_hub_workstream_id: "e2533f3a-aa43-59b3-bff3-8e64b6149487"
---
@ -75,3 +75,20 @@ agreement) and Railiance (emitter confirmation) via State Hub messages
`4f1c67bc-8de2-483f-bcac-dbdf107ce95a`. NetKingdom adds the schema and
validator once both reply; nothing here can be finished unilaterally
without pre-empting their agreement.
## Infrastructure review — 2026-09-28
Use accepted IAM Profile v0.3 and Playbook Capability Contract v0.1 as the
current baseline. Proposed IAM v0.4 and Playbook v0.2 are not deployed
capabilities. RCLK-WP-0002 still explicitly names this receipt as its dependency
on September 28. T02 remains `wait` for emitter and evidence-holder agreement.
Require the agreed schema to preserve unknown actor/delegation and clock
bounds explicitly, correlate decision/approval/run/artifact identities, and
distinguish durable receipt ingestion from attribution proof. Reuse audit-core
sender custody and reconciliation contracts rather than create another audit
sink. Acceptance needs an actual Railiance-emitted receipt and audit-core
readback, plus invalid/missing attribution cases; schema validation alone
cannot establish end-to-end attribution.
Evidence and cross-plan priorities: [estate review](../history/2026-09-28-open-workplan-infrastructure-review.md).

View file

@ -9,7 +9,7 @@ flavor: planning
owner: claude-code
topic_slug: netkingdom
created: "2026-09-23"
updated: "2026-09-24"
updated: "2026-09-28"
related: [NK-ADR-0016, NK-WP-0037]
state_hub_workstream_id: "3f702215-704b-5788-8ca0-b8b9ba2dd3f8"
---
@ -72,3 +72,23 @@ on.
asking for a proposed pilot workload and U06 touchpoints. This is a
UX/product agreement across two repos and a pilot workload owner; NetKingdom
cannot decide it unilaterally.
## Infrastructure review — 2026-09-28
Build T02 on the already completed USER-WP-0033 and KEY-WP-0035 P06 work.
Their September 14 release evidence records optional-after-enrollment policy
for `user-engine-portal` and `vergabe-demo-company`, privileged MFA guards,
confirmed enrollment/cancellation and old-session checks. Do not rebuild
those capabilities or interpret this plan as the first delivery of MFA policy.
The residual is workload-level interoperability and an accepted pilot journey:
agree the pilot owner, reuse U06 recovery, prove no-factor enrollment and
return to the protected action, and test stale AAL1, refusal and provider
unavailability. Existing scoped policy does not prove arbitrary-client
`acr_values` support or acceptance of IAM v0.4. KeyCape owns issuer enforcement;
user-engine owns the journey; the workload and flex-auth enforce the issued
assurance at the protected action. T02 remains `wait` for that agreement and
actual-user acceptance, coordinated with KEY-WP-0034 / USER-WP-0028 /
VERGABE-WP-0019, without reopening their completed provider work.
Evidence and cross-plan priorities: [estate review](../history/2026-09-28-open-workplan-infrastructure-review.md).