ops-mason/workplans/MASON-WP-0010-security-case-materialization.md

id	type	title	domain	repo	status	flavor	owner	topic_slug	created	updated	depends_on	related_repos	state_hub_workstream_id
MASON-WP-0010	workplan	Materialize SecurityCases from their type, with acceptance as the only gate	infotech	ops-mason	ready	implementation	claude-code	netkingdom	2026-10-08	2026-10-08		net-kingdom ops-warden railiance-platform	eabf2c39-94bd-5a11-8f2e-76d7a95d1583

MASON-WP-0010 — Materialize SecurityCases from their type, with acceptance as the only gate

Why

NetKingdom is introducing SecurityCaseTypes (net-kingdom NK-WP-0048, canon security-case-types_v0.1, proposed). A type is designed once, with documentation, tests and an informed-decision. Each case of an implemented type is then light: it is accepted, ops-mason arranges it, and ops-warden follows through.

ops-mason's four phases (construction plan, review, executive summary, build) stay exactly as they are for new types and for structure that no type covers. For a KnownSecurityCase, the construction plan is rendered from the type's materialization templates, and the executive-summary gate collapses to the case acceptance, because the shape was decided when the type was acknowledged.

MASON-WP-0009 (a hand-built placement of a key-cape client secret) is the kind of work this replaces. It becomes a reference instance for the first type.

Tasks

id: MASON-WP-0010-T01
status: done
depends_on: [NK-WP-0048-T03]
priority: high
state_hub_task_id: "3382ea7b-65ca-59a9-97ae-273455af44c2"

T01 — Define the type's materialization section

Propose the materialization part of the SecurityCaseType schema together with net-kingdom: policy, role, KV path structure and catalog-entry templates over case parameters, with naming rules. These must respect ops-mason's existing "respect, extend or compact before adding" review, so that a type cannot template sprawl. Write it for the first type, oidc-browser-relying-party, from MASON-WP-0009 and the existing key-cape client custody paths.

Review (2026-10-08) of net-kingdom security-case-types/oidc-browser-relying-party/type.yaml 1.0. The structure (four items, all but the catalog entry conditional on confidential) is right. The names add three new families where existing ones cover the need, so they fail "respect, extend or compact before adding". Requested refinements, each from the live CCR-2026-0033 placement (plans/keycape-secrets-engine-openbao-client-custody.md):

1. Fix the path in the type. secret_ref should not be case-settable; a free pattern under platform/workloads/ lets every case pick its own layout. Derive it: platform/workloads/keycape/{client_id} (field CLIENT_SECRET), as for secrets-engine-openbao.
2. Reuse the policy family. Existing readers are workload-kv-read-keycape-<client>-<reader>. Rename keycape-client-{client_id}-read to workload-kv-read-keycape-{client_id}-eso (KeyCape reads its client secret only through ESO), and {consuming_service}-oidc-client-{client_id}-read to workload-kv-read-keycape-{client_id}-{consuming_service}. Update verification custody-allowed-to-consumer and rollback to match.
3. Template the policy body, not just its name. An openbao_policy item needs its rules (read on platform/data/workloads/keycape/{client_id}, nothing else: no metadata, list, parent or sibling), or the review cannot check invariant (ii) and a rendered plan is not buildable.
4. Add the missing ESO role. deliver-secret needs a Kubernetes-auth role external-secrets-keycape-{client_id} (kind openbao_role, bound to the ESO service account, policy from item 2, 15m TTL, no default policy), as the reference placement has.
5. Catalog naming. The one existing entry is rapp-qonto-keycape-client; prefer {consuming_service}-keycape-client over oidc-client-{client_id}.
6. Rollback order. mint-secret "destroy" and client-secret-path "remove" act on the same KV path; collapse to one step (metadata delete after the ExternalSecret is gone) so rollback cannot fail on a missing path.

With 1-4 applied, the section is acceptable to ops-mason for NK-WP-0048-T05.

id: MASON-WP-0010-T02
status: wait
depends_on: [MASON-WP-0010-T01, NK-WP-0048-T05]
blocking_reason: "Rendering waits for net-kingdom to fold in the T01 review and acknowledge the type (NK-WP-0048-T05)."
priority: high
state_hub_task_id: "fd385537-7378-5539-8a6e-f45851296f42"

T02 — Render a construction plan from a case

mason plan --case <case.yaml> validates the case against its implemented type, renders the construction plan from the type's templates, and runs the existing consistency review against current OpenBao structure (read-only, no values). The output is the usual plan, marked derived-from-type, plus the case-acceptance reference in place of a fresh executive summary.

Tests: render the reference case; refuse a case whose type is not implemented; refuse parameter values outside the type's validation; flag a collision with existing structure.

id: MASON-WP-0010-T03
status: wait
depends_on: [MASON-WP-0010-T02]
blocking_reason: "Building from an accepted case follows the rendering."
priority: high
state_hub_task_id: "56cea6be-c613-586c-80cd-125340b374da"

T03 — Build from an accepted case

mason build --case <case.yaml> builds a rendered plan when the case's acceptance record is present, with no separate executive-summary approval. Its audit trail names the case, the type version and the acceptance. It proposes the pointer-only ops-warden catalog entries the type defines, as today. Rollback removes exactly what this case created.

Acceptance: the Forgejo reference case (NK-WP-0048-T06) materializes through this path.

id: MASON-WP-0010-T04
status: wait
depends_on: [MASON-WP-0010-T03]
blocking_reason: "Adoption follows a working light path."
priority: medium
state_hub_task_id: "f6ad0d3c-8f47-5fdf-8115-6ca9d8a1fead"

T04 — Adopt MASON-WP-0009 as a case

Once oidc-browser-relying-party (or the confidential service client type) is implemented, express MASON-WP-0009's placement as a case of that type without changing the live structure, and close the hand-built path.