ops-mason/workplans/MASON-WP-0007-tenant-engine-audit-core-sender-projection.md

id	type	title	domain	repo	status	flavor	owner	topic_slug	created	updated	state_hub_workstream_id
MASON-WP-0007	workplan	Project the tenant-engine audit-core sender token into its namespace	infotech	ops-mason	finished	planning	claude	netkingdom	2026-10-01	2026-10-09	60acab5e-8ee3-5449-bc1e-91b203e92262

MASON-WP-0007 — Project the tenant-engine audit-core sender token

Goal

Deliver the tenant-engine sender token, and only that token, as Secret tenant-engine-audit-core-sender key token in namespace tenant-engine, through External Secrets using Kubernetes auth (no login-token dependency), without any agent or founder handling the value.

Demand source: tenant-engine TEN-IN-0005; audit-core mint receipt audit-core/docs/evidence/2026-09-15-tenant-engine-sender-mint.json. Construction plan: plans/tenant-engine-audit-core-sender-projection.md (approved 2026-10-03). Routing entry: audit-core-senders.

Boundaries

• Plan approved 2026-10-03 for declaring rows 1-6 and 8 only; no apply and not the row-7 seed (attended founder step). No OpenBao write and no cluster apply happens in this workplan. No secret value is read or recorded anywhere.
• The registry path platform/workloads/audit-core/senders is audit-core's authority and is not widened. The existing openbao-tenant-engine-database store and its static token are not reused.
• Policy and role are declared by railiance-platform; the SA, store and ExternalSecret by the tenant-engine rApp manifests. ops-mason plans, verifies structure by metadata, and records evidence.

Tasks

Complete the live survey and review the plan

id: MASON-WP-0007-T01
status: done
priority: high
state_hub_task_id: "1819909b-3949-5c04-ae4e-c38e003a1707"

With a scoped ./scripts/bao-session.sh grant MASON-WP-0007-T01 session, confirm metadata only: platform/workloads/tenant-engine/ is unused, no conflicting policy/role names, auth/kubernetes role shape of email-connect-transactional-eso. Ask railiance-platform whether the CCR path or lanes.json is the right surface for a Kubernetes-auth role, and whether ESO may create SA tokens in tenant-engine. Then render build_spec and its digest if the ops-mason builder is to be used.

2026-10-03 (CUST-WP-0075): file-only part done. (a) Surface question answered by railiance-platform 2026-10-02: the attended script, not the CCR path or lanes.json (see T03). (b) Role shape of email-connect-transactional-eso, from railiance-platform RPF-WP-0045 (bao write auth/kubernetes/role/...): SA email-connect-eso, namespace email-connect, audience openbao, one exact policy, 15m ttl/max/explicit max, no default policy. The tenant-engine script declares the same shape. (c) The ops-mason builder is not used (plan §3: it cannot set audience, max/explicit max or no-default-policy), so no build_spec digest is rendered. (d) ESO token-create check: written down as a read-only command in railiance-platform docs/credential-lane-designs/tenant-engine-audit-core-sender-seed.md, carried by T06. Remaining live metadata (target path unused, no conflicting policy/role) is not surveyed with a bao-session grant here; the attended sequence checks it itself: the policy/role script exits 3 on any differing object, and the seed --dry-run reads only KV metadata and exits 6 if the target exists. Close T01 on that dry-run receipt, or run the scoped survey first if a separate pre-sitting check is wanted.

2026-10-03 done: the live metadata survey is answered by the attended run. The policy/role script did not report a conflicting object, and the seed receipts show target v1 equal to the registry (version 11). Closed on those receipts as proposed by CUST-WP-0075.

Approve the plan

id: MASON-WP-0007-T02
status: done
depends_on: [MASON-WP-0007-T01]
priority: high
state_hub_task_id: "18151439-0d9c-536f-93c8-2b113bf80c27"

Policy and Kubernetes-auth role declared by railiance-platform

id: MASON-WP-0007-T03
status: done
priority: high
state_hub_task_id: "aadb4beb-7cdd-56d1-8140-1dbe38ff5db7"

2026-10-03 (CUST-WP-0075 inbox sweep): railiance-platform replied 2026-10-02 that it declared both objects in railiance-platform commit 8c44256 (intake RPF-IN-0002; verified on origin/main 2026-10-03): policy openbao/policies/workload-kv-read-tenant-engine-audit-core-sender-eso.hcl (exact read of platform/data/workloads/tenant-engine/audit-core-sender plus token lookup-self/revoke-self) and the silent, idempotent attended script scripts/openbao-tenant-engine-audit-core-sender-eso-attended.sh, which writes the policy and Kubernetes-auth role tenant-engine-audit-core-sender-eso (SA tenant-engine/tenant-engine-eso, audience openbao, 15m ttl/max, no default policy). Surface is the attended script, not the CCR path or lanes.json. The declaration this task waited for exists, so T03 is done. Nothing is applied: running the script is an attended founder step and joins T05.

Manifests in the tenant-engine rApp repository

id: MASON-WP-0007-T04
status: done
priority: high
state_hub_task_id: "e56f0374-fede-5494-8266-a30f08896a6a"

2026-10-03 (CUST-WP-0075 inbox sweep): tenant-engine replied 2026-10-02 to the draft-plan message: the drain re-reads the token file on every delivery and treats a missing or empty file as a retry, so no rollout is needed after the first ESO sync and the Secret mount is optional. It will declare SA tenant-engine-eso, the ClusterSecretStore and the ExternalSecret in rapp-tenant-engine/manifests once the plan is approved. That reply predates ops-mason's approval notice (2026-10-02 22:17, message 207b94ce), which already tells it to proceed with rows 4-6 and not apply before the seed. No new question for ops-mason; still waiting on tenant-engine's declaration.

2026-10-09 done: declared in rapp-tenant-engine c160be2 (on origin/main), manifests/tenant-engine-audit-core-sender.yaml; checked field by field against plan rows 4-6 (SA without token automount, ClusterSecretStore on Kubernetes auth role tenant-engine-audit-core-sender-eso limited to namespace tenant-engine, ExternalSecret refresh 1h, key token). make test 15 passed, client dry-run clean. Correction: no ArgoCD Application covers rapp-tenant-engine; it is applied by the founder with make prerequisites-dry-run then make prerequisites. The OpenBao side (rows 1-3, 7) is already live (T03, T05), so the apply can go now.

Attended seed of the dedicated KV path

id: MASON-WP-0007-T05
status: done
priority: high
state_hub_task_id: "1bb05319-25a5-579f-8b63-897ec583bc3e"

2026-10-03: human gate routed to hub decision 62aa95e4-3ccc-4867-8806-5e3db005b483 (D1: Attended OpenBao provisioning window: one session clears the pending credential lanes) by CUST-WP-0075; resolving that decision raises C-40 here.

2026-10-03 (CUST-WP-0075 inbox sweep): railiance-platform's 2026-10-02 reply puts the policy/role apply in the same attended window: the founder runs BAO_ADDR=http://127.0.0.1:18200 VAULT_ADDR=http://127.0.0.1:18200 warden access openbao-platform-admin-login --exec -- sh scripts/openbao-tenant-engine-audit-core-sender-eso-attended.sh from railiance-platform (read warden's printed line, not its exit code; exit 3 means an existing object differs), then reads back the role. railiance-platform has no helper for the row-7 seed; use ops-mason's wrapped-seed technique per the plan. Blocking reason widened to cover both steps; gate unchanged (decision 62aa95e4).

2026-10-03 (CUST-WP-0075): re-qualified. The reviewed silent seed helper now exists: railiance-platform scripts/tenant_engine_audit_core_sender_seed.py (commit e7eb9db, offline fake-bao tests in tests/test_tenant_engine_audit_core_sender_seed.py). It is the user-engine wrap-migrate technique: one platform-admin process reads the registry, selects sender tenant-engine (refuses unless exactly one token and write-only), and writes {token} to platform/workloads/tenant-engine/audit-core-sender with CAS 0. No output, value only on the bao child's stdin, receipt holds versions and booleans. Exit 0 ok/identical, 2 precondition refused, 3 target differs, 4 write failed, 5 verify failed, 6 dry-run target present. Exact founder commands are in the lane doc. No dependency remains besides the human gate (decision 62aa95e4).

2026-10-03: founder approved the three-child sequence in the custodian session ("APPROVE MASON-WP-0007-T05"); recorded in railiance-platform docs/credential-lane-designs/tenant-engine-audit-core-sender-seed.md. What remains is the attended run. Close T05 on the final seed receipt; T01 can close on the dry-run receipt.

2026-10-03 done: the founder ran the approved attended sequence. The policy/role script reported no failure. The seed dry-run exited 6 (target already present at v1). The seed run exited 0 with outcome already_identical: the existing value equals the registry token, so nothing was written. Receipts in railiance-platform docs/evidence/tenant-engine-sender-seed-dry-run.json (e60c6fb) and tenant-engine-sender-seed.json (790aab0); 0 credential values emitted. Who first seeded v1 is not recorded.

Verify and hand off

2026-10-09: founder applied rapp-tenant-engine (make prerequisites). Checked without touching the Secret: SA tenant-engine/tenant-engine-eso exists; ClusterSecretStore openbao-tenant-engine-audit-core-sender Ready=True (Valid); ExternalSecret tenant-engine/tenant-engine-audit-core-sender Ready=True (SecretSynced), which means ESO wrote the target. A direct presence check on the Secret was refused by the guard-secret-reads hook, as intended; the founder runs it if wanted. The declared policy grants exactly read on platform/data/workloads/tenant-engine/audit-core-sender plus self lookup/revoke, so it cannot reach the registry path; comparing it with the live policy needs a survey grant.

2026-10-09 done (grant claude-MASON-WP-0007-T06, revoked after): live policy workload-kv-read-tenant-engine-audit-core-sender-eso is byte-identical to the railiance-platform file and never names the registry path; Kubernetes role tenant-engine-audit-core-sender-eso is bound to tenant-engine/tenant-engine-eso, audience openbao, 15m/15m, no default policy, that policy only; KV entry at version 1 and described. Secret presence rests on ESO's SecretSynced (agents do not read Secrets). Handed off: ops-warden adds and activates the pointer under audit-core-senders (message e7e866bf, its own catalog act); tenant-engine told it is live (message d4641c47). No residuals.

id: MASON-WP-0007-T06
status: done
depends_on: [MASON-WP-0007-T03, MASON-WP-0007-T04, MASON-WP-0007-T05]
priority: medium
state_hub_task_id: "84576093-9133-5708-b724-2266db434407"

2026-10-03 (CUST-WP-0075 inbox sweep): railiance-platform notes that ESO's controller SA may create serviceaccounts/token in activity-core and email-connect but this is not yet checked for namespace tenant-engine; run an auth can-i check for that subresource there before the store goes live (a railiance-cluster matter if it fails). Separately, the existing openbao-tenant-engine-database store stays on a periodic token renewed by eso-token-renewer (RPF-WP-0046); confirming it was re-minted as periodic before ~2026-10-25 is outside this workplan.

2026-10-03 (CUST-WP-0075): the ESO check is written down in railiance-platform docs/credential-lane-designs/tenant-engine-audit-core-sender-seed.md. The operator runs it (read-only SubjectAccessReview, after confirming node IP 92.205.62.239): kubectl auth can-i create serviceaccounts --subresource=token -n tenant-engine --as=system:serviceaccount:external-secrets:external-secrets. yes is required. Not run.

2026-10-03: T03 and T05 are done; T06 now waits only on T04 (tenant-engine manifests). The non-standard blocked_on: other-task was removed because depends_on carries the gate.