railiance-platform/docs/credential-lane-designs/bounded-executor.md

# Bounded executor: OpenBao lanes and audit sender (owner answer, NK-WP-0056-T02)

Owner answer from railiance-platform to NetKingdom's request
(net-kingdom `docs/proposals/2026-10-31-nk56-t02-owner-requests.md` §railiance-platform;
State Hub message `9d08288d`). Basis: Bounded Execution Admission v0.1 (proposed) and its pilot
example `bind-rotation-svc-authelia.yaml`. Workplan: `workplans/RPF-WP-0069-bounded-executor-lanes.md`.

Everything here is source and proposals. No role, policy, Secret or KV value was created or read.
CCR-2026-0058 is `proposed`; approvals and the founder's choices below stay open.

## Q1. Kubernetes auth role for `sso/nk-bind-executor`: which request types?

**Answer: one role per lane, all bound to the one ServiceAccount, two request types.**

The existing `workload-kv-read` contract requires a role to carry exactly its own policy
(`scripts/credential-change.py` `validate_workload_kv_read`, "openbao.auth.policies must contain exactly
the policy used by the auth method"; applier check "must contain only openbao.policy_name"). We keep that
rule. The executor logs in once per lane with the same projected ServiceAccount token (audience
`openbao`); each token carries one policy and lives at most 15 minutes. A combined role would make every
lane's review depend on every other lane.

| Executor need | Request type | Status |
| --- | --- | --- |
| Write the next version of `platform/workloads/net-kingdom/directory-binds/svc-authelia` (CAS) and read it for checks/revert (T06) | `workload-kv-write-next-version` (**new**, `scripts/workload_kv_write_next_version.py`) | Type in source; CCR-2026-0058 `proposed` |
| Read `platform/workloads/net-kingdom/synthetic-journey/syn-journey` (`PASSWORD`, `TOTP_SEED`) for the journey (T10) | `workload-kv-read`, native workload login (`token_self_lifecycle: true`, `metadata_read: false`), as the native reader proof in CCR-2026-0053 | Not drafted; see below |
| LLDAP credential to set `svc-authelia`'s password | `workload-kv-read` of a new custody entry, after secrets-engine answers its Q2 | Not drafted |
| audit-core sender bearer (receipts) | `workload-kv-read` with ESO delivery, as CCR-2026-0021/0022 | Not drafted; see Q2 |

### The new type `workload-kv-write-next-version`

Prepared the way `attended-service-credential-delivery` was added: module
`scripts/workload_kv_write_next_version.py`, tests `tests/test_workload_kv_write_next_version.py`, dispatch in
`scripts/credential-change.py` (validate, plan, operator-commands, runbook). It is **contract-only**: there
is no delegated applier (it is not in `LANE_MODULES`). The attended platform-admin applies policy and role
from a reviewed commit, like CCR-2026-0052..0055.

The contract refuses anything wider than:

- one exact `platform/workloads/...` path on mount `platform`; no wildcard, no sibling;
- policy (generated by `policy_hcl`, artifact `openbao/policies/<policy>.hcl`):
  `read` + `update` on `platform/data/<path>` only (no `required_parameters`: OpenBao applies it to reads too, NK-WP-0056-T12),
  `allowed_parameters = {data, options}`; plus `lookup-self`/`revoke-self`. No `create` (a missing path is
  refused, so the executor cannot mint new entries), no `metadata/`, `delete/`, `destroy/`, `undelete/`, list;
- key-level `cas_required = true`, set by the attended platform-admin at setup. The engine then refuses
  every write that does not name the version it replaces; races and replays fail closed in OpenBao, not in
  executor code. (`required_parameters = ["options"]` alone cannot force `options.cas`; the key setting does.)
- Kubernetes auth: one ServiceAccount, one namespace, audience `openbao`, `ttl`/`token_max_ttl`/
  `token_explicit_max_ttl` = 15m, `token_no_default_policy: true`, exactly one policy;
- `access_frontdoor.resolvable: false`; `agent_fence.data_and_metadata_denied: true` (coding agents fenced);
- `admission` names the standard and executor identity; full `verification` and `lifecycle`; explicit
  approval by every `review.required_approvers` role from `approved` onward.

Revert (`restore-kv` in the example) is a further next-version write of the prior value with CAS. Reading
an older version is a `read` on `data/<path>?version=N`, which the policy already grants; no extra
capability is needed.

**What the role does not do.** OpenBao does not evaluate the admission. The role is standing: a compromised
`nk-bind-executor` ServiceAccount can replace the svc-authelia bind (sign-in outage on Authelia's next
restart) but reach nothing else. The admission window, consume-once and plan digest are enforced by the
executor, approval-engine and access-engine. If that is not enough, the founder can choose a
window-scoped role instead (created by the attended platform-admin at the window start, removed after);
that removes the "unattended" property of T06 for the platform side. Recommendation: standing role for the
pilot, because the reachable damage is one read-only directory bind already covered by an attended
recovery path (CCR-2026-0053 `lifecycle.compromised`).

### Journey secrets (T10)

CCR-2026-0057 is `attended-service-credential-delivery` with `runtime_access: false`; its contract forbids
any role or policy on that path. A `workload-kv-read` request for the executor therefore changes
CCR-2026-0057's stated boundary. It must say so, cite CCR-2026-0057, and be approved by both
platform-owner and net-kingdom-owner. CCR-2026-0057's attended procedure stays valid. Shape: role
`net-kingdom-bind-executor-syn-journey-read`, policy `read` on the data path only, native login, 15m.
Draft it when T10 is scheduled and the ServiceAccount exists.

## Q2. Can the executor pod receive an ESO-projected audit-core sender bearer?

**Yes, with the CCR-2026-0021/0022 shape, once audit-core admits the sender.** The receipt is an event to
audit-core; per RPF-WP-0067-T01 the wire is `POST /v1/events` to
`http://audit-core.audit-core.svc.cluster.local:8080`, with a per-sender bearer from the registry at
`platform/workloads/audit-core/senders`. `Idempotency-Key` is the envelope `id` and `correlation_id` is the
`run_id`. The envelope `source` equals the sender name.

Shape (as `docs/credential-lane-designs/factory-audit-senders-review.md`):

- custody `platform/workloads/net-kingdom/bounded-executor/audit-sender` (`AUDIT_TOKEN`), generated CAS=0 in
  the attended platform process and merged into the registry as one exact sender (proposed name
  `nk-bounded-executor`, `tenant:platform`, write true, read false, `evidence_kind: load-bearing`,
  `secret_policy: redact`); no existing sender changes;
- exact-path policy, Kubernetes role for `external-secrets/external-secrets` only, ClusterSecretStore
  restricted to namespace `sso`; ExternalSecret into `sso/nk-bind-executor-audit` key `audit-token`,
  mounted as a file in the executor pod;
- coding-agent fence on the new data and metadata paths.

The bearer lets the executor append its own receipts only. It is not an OpenBao identity. The ESO
manifests belong in the `rapp-*` package, as in CCR-2026-0053, which points to net-kingdom
`bind-eso.yaml`. Prerequisites: audit-core says yes to its Q1 (net-kingdom request §audit-core) and
names the sender. Then a `workload-kv-read` CCR follows here.

## Open items for the founder and other owners

1. Review and approve or change CCR-2026-0058 (platform-owner, net-kingdom-owner). It stays `proposed`.
2. Standing vs window-scoped write role (recommendation: standing for the pilot).
3. Accept that a journey-read CCR widens CCR-2026-0057's `runtime_access: false`.
4. secrets-engine: the LLDAP credential lane shape (its Q2) before a custody CCR can be drafted.
5. audit-core: sender admission and name, before the sender CCR.
6. railiance-apps / rapp package: the ServiceAccount `sso/nk-bind-executor` must exist before
   `bound_claims_confirmed` can be set.