From 21f8b3754f4bbbbe71559c17b8b02947d74464bd Mon Sep 17 00:00:00 2001 From: tegwick Date: Sat, 3 Oct 2026 08:29:32 +0200 Subject: [PATCH] MASON-WP-0007: point T05 at the reviewed seed helper; T01 file-only survey (CUST-WP-0075) T05 now names railiance-platform scripts/tenant_engine_audit_core_sender_seed.py (e7eb9db) and the exact three-step attended sequence. T01 records the file-only answers; T06 carries the read-only ESO token-create can-i check. Co-Authored-By: Claude Opus 5.5 Assistant: claude-code Assistant-Model: opus Assistant-Process: 3775@bnt-lap001 Assistant-Session: cfacb6a5-ad5b-4f79-ac67-053e3b0d34a3 --- ...-WP-0007-tenant-engine-audit-core-sender-projection.md | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/workplans/MASON-WP-0007-tenant-engine-audit-core-sender-projection.md b/workplans/MASON-WP-0007-tenant-engine-audit-core-sender-projection.md index e77f1c9..cf7a96a 100644 --- a/workplans/MASON-WP-0007-tenant-engine-audit-core-sender-projection.md +++ b/workplans/MASON-WP-0007-tenant-engine-audit-core-sender-projection.md @@ -58,6 +58,8 @@ 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. + ## Approve the plan ```task @@ -118,7 +120,7 @@ id: MASON-WP-0007-T05 status: wait needs_human: true decision_id: 62aa95e4-3ccc-4867-8806-5e3db005b483 -blocking_reason: "Attended founder session: run railiance-platform scripts/openbao-tenant-engine-audit-core-sender-eso-attended.sh (policy + k8s-auth role) under warden openbao-platform-admin-login, then a wrapped platform-admin process copies the tenant-engine token from the registry document to platform/workloads/tenant-engine/audit-core-sender without printing it; ops-mason-build is denied value reads, so only an attended admin lane can do it." +blocking_reason: "Attended founder sitting, reviewed sequence in railiance-platform docs/credential-lane-designs/tenant-engine-audit-core-sender-seed.md (commit e7eb9db): 1) scripts/openbao-tenant-engine-audit-core-sender-eso-attended.sh (policy + k8s-auth role), 2) scripts/tenant_engine_audit_core_sender_seed.py --dry-run, 3) the same helper without --dry-run, each under warden openbao-platform-admin-login. Silent CAS-0 copy of the tenant-engine token from the registry; never overwrites. Founder approves as one memo." priority: high state_hub_task_id: "1bb05319-25a5-579f-8b63-897ec583bc3e" ``` @@ -134,6 +136,8 @@ 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). + ## Verify and hand off ```task @@ -154,3 +158,5 @@ an `auth can-i` check for that subresource there before the store goes live `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.