the-custodian/docs/changes/CUST-WP-0073/credential-boundary-r1/PROPOSAL.md
codex 02e69269c8
Some checks failed
CI Smoke / host-smoke (push) Successful in 1s
CI Smoke / container-smoke (push) Successful in 2s
Reject generated-only commits / generated-commit-guard (push) Successful in 11s
Python Tests / pytest (push) Failing after 28s
Adopt staged generation and prepare weekly sizing and credential isolation
2026-10-19 12:42:11 +02:00

92 lines
6.1 KiB
Markdown

# 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.