coulomb/ops-warden
4
0
Fork 0
Code Issues Pull requests Projects Releases 2 Packages Wiki Activity Actions
ops-warden/wiki/playbooks/net-kingdom-sso-bind-credentials.md
tegwick c374d41a49
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
Details
CI Smoke / container-smoke (push) Successful in 1s
Details
Add NetKingdom SSO credential routing lanes 
Assistant: codex
Assistant-Model: gpt-5.6-sol
Assistant-Session: 01a0217e-8c4c-7383-be6b-f50a6e485306
2026-08-23 21:43:12 +02:00

2.5 KiB
Raw Blame History

NetKingdom SSO/MFA bind credentials

Pointer playbook for the two high-risk credentials used by the NetKingdom LLDAP/privacyIDEA control plane. ops-warden routes these needs; it does not own, read, store, or execute either credential flow.

Ownership

Credential lane Custody/update owner Provider procedure Current consumer use
net-kingdom-lldap-bind-credential railiance-platform / OpenBao net-kingdom's approved LLDAP and resolver reconciliation runbook identity-provisioner and privacyIDEA's persisted lldap-coulomb resolver
net-kingdom-privacyidea-admin-token railiance-platform / OpenBao net-kingdom's attended privacyIDEA reconciliation runbook attended resolver repair and provider-admin verification

The credentials are intentionally separate. Rotating the LLDAP bind credential requires coordinated consumer reload/reconciliation; rotating the privacyIDEA admin token is a provider-admin action with its own expiry and revocation semantics. Neither lane authorizes a general bundle export or a read of the live Kubernetes Secret.

Worker checklist

  1. Run warden route show <lane-id> and confirm the current owner and blocked fields. The lane is a pointer, not a value-vending operation.
  2. Obtain the exact approved action and attended execution window from the owner. Do not request either value in chat, State Hub, Git, command arguments, or normal logs.
  3. Use the railiance-platform custody path once its concrete OpenBao mount, policy, field names, and consumer delivery contract are published.
  4. Execute provider-specific reconciliation only through the net-kingdom owner-controlled runbook. The resolver repair must use protected temporary input, explicit --apply, predecessor denial checks, readiness checks, and sanitized evidence.
  5. Retain only non-secret rotation metadata: approval/action id, revision, provider rollout status, public fingerprints where applicable, predecessor rejection/expiry outcome, and cleanup receipt.

Current gate

The routing entries are active so workers can find the ownership boundary, but they are not yet resolvable fetch lanes. railiance-platform must publish the concrete OpenBao paths/fields and owner-facing update contract before any warden access --fetch or proxy execution is enabled. NetKingdom's NK-WP-0033 T03/T05 attended reconciliation and sanitized proof remain the provider acceptance gate.

Canonical provider context: net-kingdom/workplans/NK-WP-0033-keycape-secret-exposure-rotation.md.