railiance-platform/credential-change-requests/CCR-2026-0055-net-kingdom-privacyidea-bind.yaml
codex ca2b5e3385
All checks were successful
CCR intake gate / gate (push) Successful in 10s
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Successful in 1s
CCR-2026-0055: verified (setup, verify and attended write-through passed; net-kingdom ad7d1cd)
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 896183@bnt-lap001
Assistant-Session: 3a18c01a-3205-4d02-94db-9efff25649a2
2026-10-31 11:19:36 +01:00

109 lines
4.7 KiB
YAML

id: CCR-2026-0055
kind: credential-change-request
schema_version: 1
request_type: attended-service-credential-delivery
title: NetKingdom privacyIDEA resolver directory bind (svc-privacyidea) custody
status: verified
created: '2026-10-31'
updated: '2026-10-31'
requester:
agent: claude-code
reason: 'NK-WP-0056-T04, fourth lane (after CCR-2026-0052/0053/0054): move the svc-privacyidea
LLDAP bind out of the founder''s personal SOPS custody into platform custody.
privacyIDEA stores the resolver password encrypted in its own database and accepts
it only through its pi-admin API; an unattended writer would need pi-admin''s
password standing in the cluster, so no workload reads it: delivery is an attended
write-through.'
review:
required: true
required_approvers:
- platform-owner
- net-kingdom-owner
comments:
- at: '2026-10-31T10:10:37+00:00'
reviewer: platform-owner
decision: approved
comment: 'Approved as proposed: svc-privacyidea held in OpenBao, no workload reader,
attended write-through.'
- at: '2026-10-31T10:10:44+00:00'
reviewer: net-kingdom-owner
decision: approved
comment: Approved as proposed for NK-WP-0056-T04.
target:
domain: infotech
tenant: platform
workload: net-kingdom-privacyidea
environment: production
purpose: Hold the svc-privacyidea LLDAP bind password in platform custody so that
its rotation needs no decrypted custody copy; privacyIDEA receives it only through
the attended resolver write. No other privacyIDEA, LLDAP or service credential.
openbao:
mount: platform
kv_path: platform/workloads/net-kingdom/directory-binds/svc-privacyidea
fields:
- LDAP_BIND_PASSWORD
auth:
method: attended-oidc
mount: netkingdom
role: platform-admin
runtime_access: false
initial_cas: 0
access_frontdoor:
type: attended-service-config
catalog_id: openbao-platform-admin-login
readiness: pending-review
resolvable: false
lifecycle:
deactivate: Delete the KV entry only after the founder custody copy is confirmed
current; privacyIDEA keeps its stored resolver password.
rotate: Change the svc-privacyidea password in LLDAP, write the next KV version
with CAS on the current version, then run realm_bootstrap.py --rotate-bind --from-openbao
(attended pi-admin; --verify-user MFA login required) and verify with an OTP login.
Founder-run.
compromised: Reset svc-privacyidea in LLDAP first (read-only bind, lldap_strict_readonly),
then rotate as above.
delivery:
surface: attended-service-config
service: privacyIDEA (sso), LDAP resolver netkingdom-lldap
target: resolver BINDPW, stored encrypted in the privacyIDEA database
procedure: net-kingdom sso-mfa/k8s/privacyidea/realm_bootstrap.py --rotate-bind
--from-openbao
gate: attended platform-admin (aal2) OpenBao session, attended pi-admin password,
and a fresh MFA login through the resolver (--verify-user) that proves the write
risk:
classification: medium
notes:
- svc-privacyidea is a read-only directory bind (lldap_strict_readonly); a leak
exposes directory attributes, not write access.
- No workload, Kubernetes or ESO reader exists; only the attended platform-admin
session reads the value, in memory.
- Initial KV write is CAS=0 from custody after the value is proven current by an
LLDAP sign-in as svc-privacyidea; no rotation happens in this request.
- Coding agents are fenced from the data and metadata paths in agent-high-risk-boundary
before the first write.
verification:
positive:
- The KV value signs in to LLDAP as svc-privacyidea (current password), compared
without display
- An OTP login resolves the user through the resolver after any write-through
negative:
- Coding-agent boundary denies data and metadata of the path
- No auth role or policy grants the path to a workload
activation_conditions:
- Explicit platform-owner and net-kingdom-owner approval of this exact request (sha256-bound
by the setup tool).
- Attended platform-admin (aal2) session; the founder runs setup with the decrypted
custody copy and the write-through with pi-admin and an MFA login through the
resolver.
- Positive and negative results recorded in value-free receipts.
evidence:
- at: '2026-10-31T10:19:36+00:00'
actor: founder (attended), claude-code guiding
kind: verifier_custody_and_write_through
result: passed
details:
- '2026-10-31: bind-lane.py setup (custody signs in to LLDAP as svc-privacyidea,
coding agents fenced, KV v1 CAS=0, no workload role) and verify passed; realm_bootstrap.py
--rotate-bind --from-openbao wrote BINDPW from OpenBao and admin passed token-backed
MFA through the resolver. Evidence: net-kingdom docs/evidence/2026-10-31-nk56-svc-privacyidea-bind/
(ad7d1cd).'