ops-mason/workplans/MASON-WP-0002-whitehat-foundational-plane.md
tegwick c26a6e59de build: provision and verify Whitehat foundational plane
Assistant: codex
Assistant-Model: gpt-5.6-sol
Assistant-Session: 01a02878-7c21-7692-bcd6-ce2838c4b448
2026-08-22 11:26:49 +02:00

8.2 KiB

id type title domain repo status owner topic_slug created updated origin origin_ref reviewed_at quality_dor quality_dor_at quality_dor_by quality_dor_note state_hub_workstream_id
MASON-WP-0002 workplan Provision the Whitehat foundational plane and reconcile intake drift infotech ops-mason active codex whitehat-foundational-plane 2026-08-22 2026-08-22 external-demand statehub-message:311a274e-9434-4fc3-bc52-8ea15ca68274 2026-08-22 DoR-Ok 2026-08-22 codex Outcome, scope, ownership, source revisions, dependencies, live-change boundary, verification, rollback, and requester/target-owner handoffs were reviewed against the repo and live read-only preflight. 9b34bf82-9d08-51e4-9204-8de5382a4153

Provision the Whitehat foundational plane and reconcile intake drift

Whitehat's governed live-test plane cannot admit a future engagement until its foundational Kubernetes boundary exists. whitehat-security requested that ops-mason provision only that boundary in State Hub message 311a274e-9434-4fc3-bc52-8ea15ca68274; audit-core explicitly confirmed the same bounded scope and asked Mason to proceed in message 7e0c1d68-1a68-4345-a845-44bd0dae8373.

The source contract is whitehat-security commit 4882c2d47a826a305d5c4e05aa7fcc1252c3887e. The plane implementation entered at commit 95129d7a35c8999be359b163b554853c9c6afa3a; its three selected files are unchanged through inspected HEAD 7e83a665735f11fccc4aac4904a510a18d759ce5. The requested NetworkPolicy file contains two objects, so the bounded live change is exactly four Kubernetes objects:

  • Namespace whitehat;
  • NetworkPolicies default-deny and allow-audit-core-e2;
  • ServiceAccount whitehat-runner with service-account token automount off.

This workplan does not authorize a runner Pod, credential Secret, identity projection, custody-broker connection, engagement approval, or target packet. The cancelled identifiers WH-ENG-20260821-AUDIT-E2 and WH-ENG-20260821-TENANT-E2 remain terminal.

The plan is ready as a structure. T01 and T04 are repository-local work. T02 is a bounded, reversible live-cluster change authorized by the requesting plane owner and confirmed by the target owner; its required read-only preflight is part of the task. T03 depends on successful T02 evidence. The README wording correction can proceed in parallel and is not authority to expand the apply set. No unresolved dependency makes the first implementation step guesswork.

Adopt and pin the bounded plane contract

id: MASON-WP-0002-T01
status: done
priority: high
state_hub_task_id: "067451e4-50f7-59d9-b804-50f348e22508"

Create an ops-mason-owned, source-pinned apply surface derived only from:

  • plane/namespace.yaml;
  • plane/network-policy.yaml;
  • plane/service-account.yaml.

Record both source revisions above and verify that the selected object content is unchanged. Do not copy or reference plane/runner-pod.yaml from an apply target. Validate the exact object set locally and against the Kubernetes API without persisting it.

Resolve the ordering contradiction in Whitehat's source documentation as a coordination correction: plane/README.md still says a new engagement must exist first, while the newer dated provision request says the foundation must exist before Whitehat drafts that engagement. Record the dated request and Audit-core confirmation as the operative construction authority, and ask Whitehat to align its README. Do not mint an engagement ID here.

Done when: the checked-in Mason render has provenance, contains exactly the four allowed objects, passes dry-run validation, and has an explicit exclusion list and rollback procedure.

Done (2026-08-22): added the byte-identical source pins, approved construction plan, declarative bundle, guarded CLI, safety documentation, and rollback generator. Thirty tests pass. Live read-only preflight reports all four objects absent and validates the matching audit-core Service/policy. Bundle digest: 9636f48f0b994118ff60a8c014e0099486945d66a2b3d3582dc57a09862b2035. Whitehat README alignment request: State Hub message 47032e07-5086-449f-8251-0f69df6cd934.

Provision and verify the foundational plane

id: MASON-WP-0002-T02
status: done
priority: high
state_hub_task_id: "23f78bc5-4185-5181-9f3c-fd718641d2a5"

Before apply, recheck the active Kubernetes context, creation authority, namespace absence or exact adoptability, Audit-core Service port 8080, and the matching target ingress policy. Apply only the T01 render.

Verify using metadata only:

  • Namespace whitehat has restricted Pod Security admission and the plane labels from the contract;
  • both NetworkPolicies have the exact selectors, destinations, and ports from the pinned render;
  • ServiceAccount whitehat-runner exists with automountServiceAccountToken: false;
  • the namespace contains no Pod, Secret created by this work, projected identity, engagement lease, or target traffic.

Rollback is object-scoped deletion of the two NetworkPolicies and the ServiceAccount. Delete the namespace only after proving that no later or unrelated object has entered it; if the namespace is still foundation-only, namespace deletion is the complete rollback. Never use an unresolved variable or broad selector for rollback.

Done when: all four objects are live and match the render, negative-scope checks are clean, and the exact rollback commands have been captured without executing them.

Done (2026-08-22): guarded apply created exactly the four approved objects. All desired fields re-verify as exact, every manifest passed server dry-run, whitehat-runner reports token automount false, and the namespace has zero Pods and zero Secrets. Evidence includes object UIDs/resource versions and rollback; no rollback command or target packet was executed.

Return evidence and bounded handoff

id: MASON-WP-0002-T03
status: progress
priority: high
state_hub_task_id: "a9c0844b-bf0a-5a53-b7e7-c0c2fbb842e6"

Write a non-secret evidence record with source revisions, apply time, object names, UIDs/resource versions where useful, verification output, exclusions, and rollback. Send pointer-only completion messages to whitehat-security and audit-core.

The handoff may state that Whitehat can draft a fresh engagement proposal. It must not approve that engagement, create credentials, connect the custody broker, deploy the runner, or exercise the target. Those are later governed records with new identifiers and their own approvals.

Done when: both requesters have apply evidence and rollback, State Hub has a progress record, and the next engagement remains explicitly separate.

Reconcile local intake and publication drift

id: MASON-WP-0002-T04
status: todo
priority: low
state_hub_task_id: "f71f5eee-9ae0-50a2-a38d-2119d5abd175"

Clean up the bounded repository drift discovered while triaging this request:

  • reconcile plans/rapp-qonto-openbao-approle-bridge.md frontmatter with its recorded successful revised build, without changing the live lane;
  • fetch and verify remote ancestry, review the existing local commit set, and publish only by a normal fast-forward push; never force-push;
  • obtain the canonical ops-mason classification through the Repo Manager workflow and add .repo-classification.yaml; do not invent classification values merely to silence C-24/C-35;
  • re-run repository tests and consistency checks after the record changes;
  • reconcile the legacy noncanonical MASON-0001-Txx task species and duplicate MASON-0001-T01 through the registrar-safe migration path; if that cannot be done without rewriting registered identity, create a residual instead of silently renumbering anything.

This task is repository hygiene only. It must not be used to broaden T01-T03, alter credentials, or modify live infrastructure.

Done when: plan status matches recorded build reality, committed work is published safely or an explicit blocker is recorded, and no unresolved consistency warning is hidden.

Workplan completion conditions

Finish this workplan only when T01-T04 are done or any genuine leftover has been handed off as a live residual record. Before marking finished, run the repo test suite, git diff --check, and statehub fix-consistency, then record the final evidence and handoff identifiers in State Hub.