the-custodian/docs/changes/CUST-WP-0073/credential-boundary-r1/PROPOSAL.md

CUST-WP-0073 credential boundary — source proposal revision 2

Status: preparation; no execution authorization. Supervisor: Bernd Worsch. Assignment: custodian-codex; supervised, autopilot disabled. Stable proposal ID: CUST73-CREDENTIAL-BOUNDARY-R1. Original source inputs are pinned in source-pins.json. SHA256SUMS binds the current review packet; original-revision-1.SHA256SUMS retains the original digest inventory. Revision 2 fixes the negative verifier after review found aggregate namespace denial insufficient. This is refinement of the same proposal, not another success or any execution approval.

This packet narrows the remaining implementation choices. It is not executable as a complete cutover: exact current host configuration, workstation assignment launch and approved privileged executor inputs remain owner review gates.

Prepared source and owners

• Platform: identity-rbac.yaml proposes a dedicated ServiceAccount and explicit GET-only version/health observation allowlist. No raw resource observation is granted. Workload observations must use sanitized supervisor-returned results. Issue short-lived credentials through the existing owner custody path; do not create legacy static ServiceAccount token Secrets. Other existing RBAC bindings must be tested; this manifest alone cannot prove effective denial.
• Cluster: cluster-bootstrap.patch removes mode 644 and unconditional transfer of the admin kubeconfig into the controller account. It changes future install flags to 600 and converges file ownership/mode. The actual source owner is railiance-cluster, not railiance-enablement. The existing installer has a creates guard: on an installed node it does NOT update the systemd launch flags. The owner must capture sanitized effective mode/flag evidence and supply an exact persistent override/restart diff; applying this patch alone would permit the old 644 unit flag to restore exposure on restart. Do not run the broad bootstrap playbook for this narrow cutover.
• Infra: host-identity.candidate.yaml specifies a separate locked-password custodian-agt account and agt-custodian-codex principal. Use the existing ssh_ca_host inventory mechanism, never map this principal to tegwick. No sudo, privileged groups, agent forwarding, port forwarding, user RC/env or raw keys. Existing agt-task-bridge and agt-interhub-bootstrap mappings have other consumers; do not remove them blindly. Prove the assignment cannot use their identities.
• Warden: issue only the scoped new SSH principal under its existing issuance contract after host mapping review. No secret retrieval through Warden.
• Harness: reuse installed f599 and successful revision-3 offline rehearsal; finish existing native admission gates. The actual interactive session must enter the restricted profile before any model/tool process can observe the host account, external connectors or inherited credentials. A child sandbox inside the current admin-capable parent does not migrate this assignment.

Exact cutover packet still required before approval

Record the concrete host and workstation account IDs; resolved SSH policy; public principal mapping; sanitized effective sudo/group/ACL decisions; pinned restricted kubeconfig context and API endpoint; trusted executor identity and allowlisted exact command digest; issuer TTL/audience; existing credential/file, agent socket, GitOps and external-tool inventory; safe staging and retirement order. Bind all of these plus owner reviews and verification/rollback digests into a new exact revision, preserving this original packet. Do not ask for a blanket approval of placeholders.

Kubernetes and SSH identity issuance do not solve workstation credential reach: old admin kubeconfigs, SSH agent sockets, writable trusted executor/runtime files, GitOps write credentials, container sockets, OpenBao tokens and inherited connector authority must all be absent from the actual agent account/profile. Privileged executor must live outside the same writable account and bind exact approved action/target/revision; a readable approval JSON is not enforcement.

Verification and rollback

1. Owner renders/reviews manifests and source diff without activation. Check effective existing RBAC and host override sources before finalizing.
2. Supervisor retains separate attended recovery access, then stages the new identity. Never remove the last working human admin path.
3. Run verify_agent_denials.py inside the actual new account/profile with its explicit context and supervisor-supplied complete current namespace inventory. Inventory JSON requires cluster="railiance01", complete=true, a nonempty unique namespaces list and supervisor_receipt_ref; its canonical SHA256 is bound in the result. Its authenticity/completeness must be checked by the supervisor. Aggregate --all-namespaces checks are retained, with every namespaced permission also checked in every listed namespace; cluster-scoped privileges are checked separately. Empty inventory refuses before any command. It refuses the old account/identity, uses only auth reviews and access checks, suppresses raw command output, and reports partial proof.
4. Supervisor independently verifies sudoers/ACLs, old admin SSH refusal, complete workstation/external-tool isolation, and positive sanitized execution of one approved action plus refusal of changed, unapproved, expired and replayed actions. Bind results to the actual runtime and assignment, not a fixture.
5. Only then document the admitted T02/T04 path. On any incomplete/failed probe, stop assignment admission, revoke only newly issued identities, and use the retained human path for recovery. Restore exact predecessor configuration only under the scoped recovery decision; never silently restore world-readable admin credentials. Preserve failed receipts. No automatic privilege fallback.

Cost estimate: no new infrastructure allocation; owner review and one attended window required. Risk estimate: potential loss of administrative access and single-node interruption during k3s restart; monetary loss is not quantified. This is not an autopilot grant. T05 rotation deferral remains unchanged.