ops-mason/workplans/MASON-WP-0002-whitehat-foundational-plane.md

---
id: MASON-WP-0002
type: workplan
title: "Provision the Whitehat foundational plane and reconcile intake drift"
domain: infotech
repo: ops-mason
status: ready
owner: codex
topic_slug: whitehat-foundational-plane
created: "2026-08-22"
updated: "2026-08-22"
origin: external-demand
origin_ref: "statehub-message:311a274e-9434-4fc3-bc52-8ea15ca68274"
reviewed_at: "2026-08-22"
quality_dor: DoR-Ok
quality_dor_at: "2026-08-22"
quality_dor_by: codex
quality_dor_note: "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."
state_hub_workstream_id: "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

```task
id: MASON-WP-0002-T01
status: todo
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.

## Provision and verify the foundational plane

```task
id: MASON-WP-0002-T02
status: todo
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.

## Return evidence and bounded handoff

```task
id: MASON-WP-0002-T03
status: todo
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

```task
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;
- re-run repository tests and consistency checks after the record changes;
- if the historical duplicate `MASON-0001-T01` record cannot be repaired
  without rewriting registered identity, create a residual instead of
  silently renumbering it.

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.