--- id: RAILIANCE-WP-0008 type: workplan title: "OpenBao Approved Automation Delegation" domain: financials repo: railiance-platform status: active owner: codex topic_slug: railiance planning_priority: high planning_order: 8 created: "2026-06-28" updated: "2026-06-28" depends_on_workplans: - RAIL-PL-WP-0002 - RAILIANCE-WP-0005 - RAILIANCE-WP-0006 - RAILIANCE-WP-0007 state_hub_workstream_id: "671898ef-2378-4814-b8f6-066148cdad46" --- # RAILIANCE-WP-0008 - OpenBao Approved Automation Delegation ## Goal Create a narrow OpenBao automation delegation path so approved credential and it-sec changes can be applied without handing broad `platform-admin` power to an agent, while still preserving different build, test, and production security requirements. This closes the current gap where reviewed CCRs can be approved and rendered, but live application still fails with `403 permission denied` on `sys/policies/acl/...` unless a human operator uses broad OpenBao admin privileges. ## Problem The current model has two bad modes: - fully manual OpenBao UI work, which can unblock one credential but is slow, hard to review, and easy to drift from the CCR; - broad `platform-admin`, which is too powerful for routine automation and too risky to hand to agents. The issue appears in multiple workstreams: - `RAILIANCE-WP-0005` token-grant apply failed on `sys/policies/acl/credential-broker-warden-sign-issuer`; - `RAILIANCE-WP-0007` whynot-design CCR apply failed on `sys/policies/acl/workload-kv-read-whynot-design-npm-publish`. Both are approved non-secret metadata changes. They should not require a human to hand-type OpenBao policy and auth-role writes once review is complete. ## Direction Add one or more constrained OpenBao applier identities that can apply only reviewed, generated metadata for approved change classes. The applier must not be a general `platform-admin` replacement. It should: - verify a resolved State Hub decision or CCR status before live mutation; - write only allowed policy names and auth role prefixes; - never read or print secret values; - record non-secret apply evidence; - keep production secret value provisioning under approved operator custody until a separate wrapped or dual-control flow is approved. ## Environment Model Build and development: - automation may apply approved sandbox metadata; - generated test secrets may be allowed only in non-production mounts; - approvals can be lightweight but still recorded. Test and staging: - automation may apply approved metadata after validation and owner review; - verification must include positive and negative access checks; - secret values should use wrapped delivery or operator custody depending on risk classification. Production: - automation may apply only approved non-secret metadata such as narrow ACL policies and auth roles; - production secret values remain out-of-band operator custody unless a later workplan creates a stronger wrapped or dual-control provisioning path; - activation requires verification evidence before ops-warden or another front door becomes resolvable. ## Proposed Policy Shape Start with one production candidate policy, for example `credential-change-prod-applier`, and keep it intentionally narrow: - allow `create`, `update`, and `read` on `sys/policies/acl/workload-kv-read-*`; - allow `create`, `update`, and `read` on approved credential-broker issuer policy names such as `credential-broker-*-issuer`; - allow `create`, `update`, and `read` on selected auth role prefixes such as `auth/netkingdom/role/*-workload-kv-read`, `auth/kubernetes/role/*`, and `auth/token/roles/credential-broker-*`; - allow read/list only where needed for idempotent verification; - deny broad `sys/*`, `auth/*`, `platform/*`, `identity/*`, `root`, and `platform-admin` semantics. Policy-name and role-name restrictions should be enforced in both OpenBao ACLs and the local applier script. ## Tasks ## T01 - Specify delegated applier policy boundaries ```task id: RAILIANCE-WP-0008-T01 status: todo priority: high state_hub_task_id: "d19fdfc5-addb-4813-8086-3aca2e948cea" ``` Define build, test, and production applier capabilities, including exact OpenBao paths, allowed name prefixes, denied paths, and required audit evidence. Acceptance: - A human reviewer can see which OpenBao paths each environment can mutate. - Production applier policy excludes secret value reads and broad admin paths. - The proposal covers both workload KV read lanes and credential broker issuer policies. ## T02 - Implement a CCR-aware applier dry-run ```task id: RAILIANCE-WP-0008-T02 status: todo priority: high state_hub_task_id: "2613f40d-fbd9-44f3-a864-85ec1d54e8f7" ``` Extend the credential-change tooling so a proposed applier can validate a CCR, check approval state, render the exact mutations, and refuse any out-of-policy policy name, auth role, mount, path, or environment. Acceptance: - Dry-run succeeds for `CCR-2026-0001`. - Dry-run refuses unapproved CCRs. - Dry-run refuses attempts to create `root`, `platform-admin`, wildcard, or unrelated policy names. ## T03 - Add non-production applier role first ```task id: RAILIANCE-WP-0008-T03 status: todo priority: medium state_hub_task_id: "ff927a19-50fb-4351-8db1-c60a0cce0995" ``` Create a build/test applier identity and prove it can apply approved metadata in a non-production lane without gaining unrelated OpenBao permissions. Acceptance: - Apply succeeds in a non-production mount or namespace. - Negative checks prove unrelated policy/auth/secret paths are denied. - Evidence is recorded without secret values. ## T04 - Add production metadata applier with human approval gate ```task id: RAILIANCE-WP-0008-T04 status: todo priority: high state_hub_task_id: "414abd65-22d3-420f-994d-f7fdd1302db5" ``` Create the production metadata applier path and require a resolved CCR/State Hub approval before mutation. Acceptance: - Approved `CCR-2026-0001` metadata can be applied without `platform-admin`. - Unapproved CCRs fail closed. - Secret value provisioning is still not automated in production. ## T05 - Close the whynot-design pilot ```task id: RAILIANCE-WP-0008-T05 status: wait priority: high state_hub_task_id: "18f34c95-4d2b-4a08-a5ad-5ab700ff9dfe" ``` Use the delegated production metadata applier to finish the whynot-design npm publish token lane after the actual token is provisioned through approved custody. Acceptance: - Policy and auth role are applied by the delegated applier. - `NPM_AUTH_TOKEN` is provisioned through approved custody. - Positive and negative verification pass without printing the token. - `CCR-2026-0001` can move to `active`. - ops-warden can mark `whynot-design-npm-publish` ready/resolvable. ## Exit Criteria - Routine approved OpenBao metadata changes no longer require broad `platform-admin`. - Production automation cannot read or exfiltrate managed secret values. - Build, test, and production each have distinct, documented security requirements. - CCR approval, apply, verification, and front-door activation form one reviewable chain.