The orchestration-layer analog of the IAM Profile, realizing the
playbook-contract dependency named in ADR-0007's meta-orchestration
refinement. NetKingdom owns the contract schema (consumer-defines-contract,
IAM Profile precedent); Railiance authors playbooks and publishes
conformant declarations; execution stays in Railiance (ADR-0007 unchanged).
Six tasks: ownership ADR + versioning; capability vocabulary (aligned to
the C0-C6 ladder + responsibility-map resource kinds); parameter format
(defaults, constraints, security-sensitivity); responsibility/trust-state
claims; catalog + consumption model + conformance validator; reference
adoption with one Railiance playbook. Status proposed; not yet registered.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Plan to make net-kingdom the canonical owner of the IAM Profile. A v0.1
draft exists in the-custodian canon (all-hubs, Custodian-flavored,
Keycloak as reference provider); this workplan relocates ownership and
evolves it to a provider-neutral, platform-neutral v0.2 that is tenant-
and agent-aware, carries explicit assurance evidence, specifies the claim
contract flex-auth consumes, and ships an executable conformance check.
Enables NK-WP-0011 (T6 conformance) and depends on NK-WP-0006 (recursive
tenant model). Status: proposed; not yet registered in the hub.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Create docs/responsibility-map.md: the single home for NetKingdom's
orchestration relationships, kept out of the orchestrated repos' intents
per ADR-0010. Records the classification criterion, the current
minimal-foundation scope, and per orchestrated repo (railiance-infra,
railiance-cluster, railiance-platform, key-cape, flex-auth) the resources
held, what the repo owns (execution), and what NetKingdom orchestrates
(meta). Lists dependencies and out-of-scope repos so the scoping decision
is explicit and revisitable.
Update ADR-0010 to point at the now-created map.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Record two foundational principles that emerged while aligning ecosystem
INTENT.md files:
1. Orchestration != dependency. NetKingdom orchestrates a repo when that
repo holds resources NetKingdom must manage (users, roles, scopes,
policies, infra resources). It depends on a repo when it merely uses it
as a tool. Defining question: does the repo hold resources NetKingdom
needs to orchestrate? (railiance-fabric = dependency;
railiance-infra/cluster/platform = orchestrated.)
2. Intent is self-coherent. A repo's INTENT.md describes its own purpose
abstractly; it must not reference NetKingdom, sister projects' intents,
or even dependencies. Relationships live in the responsibility map /
ADRs / interface contracts, not in intent.
Rejects the earlier "place in the NetKingdom landscape" block idea as a
Principle 2 violation.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
- ADR-0007: refine (not overturn) the orchestration boundary with the
two-layer model — Railiance executes parametrized playbooks, NetKingdom
does meta-orchestration (scenario->playbook selection, parametrization,
responsibility map). Add the playbook/capability-contract dependency as
the prerequisite, analogous to the IAM Profile.
- INTENT.md: add "Why NetKingdom" (the kingdom metaphor: governed,
defended, living/evolving, tended by its people); Principle 7
(Meta-Orchestration over Re-Implementation); an Operating Model section
(kaizen-agent workforce for recurring duties + change/improvement); and
matching Direction-of-Evolution entries.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Make the lightweight->expanded decision explicitly capability-driven (not
scale-driven) and capture the turn-key, capability-selectable framework
ambition.
- arch doc: add capability-driven rationale to the identity-mode choice;
add a "Capability Progression (Start Small -> Enterprise)" ladder
(C0 bootstrap -> C6 self-optimizing), including the C2a/C2b 2FA split
(Authelia built-in vs privacyIDEA); answer the lightweight/expanded
open question as capability-driven
- INTENT.md: recast Progressive Expansion as capability-driven with a
no-structural-breaks guarantee; add capability-selection + turn-key
orchestration to the mission and identity
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Set NK-WP-0001 status to canonical 'archived' (was non-canonical
'deferred', which the hub rejected). Backfill NK-WP-0011 workstream and
task ids from State Hub registration.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
NK-WP-0001-T04 (privacyIDEA, Keycloak path) -> cancelled, superseded by
NK-WP-0003-T04 in the deployed KeyCape stack. T05-T08 (Keycloak SSO,
realm/MFA flow, user mgmt, DR) -> cancelled and migrated to NK-WP-0011.
NK-WP-0011 reframes the deferred Keycloak work as expanded-mode enterprise
federation: Keycloak as an identity broker for Entra ID / AD / SAML that
issues IAM Profile-conformant tokens, refined against the current stack
(OpenBao runtime secrets, CloudNativePG, flex-auth/Topaz PDP, recursive
platform/tenant model) rather than the original greenfield assumptions.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Refine the recursive platform security architecture to make OpenBao the
canonical runtime secret authority, with SOPS/age, K8s Secrets, and the
emergency bundle reframed as bootstrap/delivery/break-glass mechanisms.
- credential-management standard v0.2: add OpenBao runtime authority
section, rotation rules, and prohibited patterns (OpenBao-as-PDP,
tenant platform-root)
- platform-identity-security-architecture: mark implemented; add
flex-auth/Topaz implications, Coulomb onboarding path, and a
production-readiness checklist
- NK-WP-0004/0005: document bootstrap-to-OpenBao handoff boundary
- NK-WP-0006/0007: status -> done with implementation reviews; add
recursive platform/tenant split and OpenBao broker/audit role for
object-storage STS vending
- NK-WP-0008: status -> done; repoint corpus to infospace-bench
- new ADR-0007 (orchestration boundary), ADR-0008 (STS vending
boundary), and the object-storage STS credential-vending architecture
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Three fixes:
1. gql() default vars '${2:-{}}' — bash parsed first '}' as closing the
parameter expansion, appending a stray '}' to every caller's vars.
Fixed by storing '{}' in a local variable first.
2. make_vars() — add VAR_INT_KEYS support so groupId is emitted as a
JSON integer (Int!) rather than a string, matching LLDAP's schema.
3. Password setting — LLDAP has no GraphQL mutation for admin password
reset. Replace the broken resetUserPasswordFromAdmin mutation with
an RFC 3062 LDAP Password Modify operation via kubectl port-forward
to the in-cluster LLDAP service, using ldap3.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
--test derives the password from the display name (spaces → hyphens, append -Pwd),
e.g. "Test User" → "Test-User-Pwd". Skips the interactive prompt.
Useful for provisioning test accounts in a non-interactive flow.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Pass GraphQL query/variables and group names via environment variables
to python3 instead of shell argument interpolation. Prevents breakage
when display names, emails, or passwords contain quotes or spaces.
Also adds --admin flag support and interactive password prompt.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Creates a user in LLDAP via GraphQL, adds them to net-kingdom-users,
optionally net-kingdom-admins (--admin flag), and sets a password interactively.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Once any admin policy exists, PI enforces it for all admins. Without an
explicit policy, pi-admin is locked out of the REST API after trigger-admin-rights
is created. Add pi-admin-all-rights (scope=admin, action=*) via pi-manage
(in-pod) as step 5, before the REST-based trigger-admin-rights step.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
