plan: govern Whitehat foundational plane provisioning

Assistant: codex
Assistant-Model: gpt-5.6-sol
Assistant-Session: 01a02878-7c21-7692-bcd6-ce2838c4b448
This commit is contained in:
tegwick 2026-08-22 10:05:42 +02:00
parent 24c6b433ed
commit c7fd599546
2 changed files with 159 additions and 0 deletions

View file

@ -10,6 +10,7 @@
| --- | --- | --- | --- | --- |
| workplan | MASON-0001 | finished | — | workplans/MASON-0001-statehub-bootstrap.md |
| workplan | MASON-WP-0001 | finished | — | workplans/MASON-WP-0001-foundation.md |
| workplan | MASON-WP-0002 | ready | — | workplans/MASON-WP-0002-whitehat-foundational-plane.md |
| task | MASON-0001-T01 | done | — | workplans/MASON-0001-statehub-bootstrap.md |
| task | MASON-0001-T01 | done | — | workplans/MASON-0001-statehub-bootstrap.md |
| task | MASON-0001-T02 | done | — | workplans/MASON-0001-statehub-bootstrap.md |
@ -19,3 +20,7 @@
| task | MASON-WP-0001-T03 | done | — | workplans/MASON-WP-0001-foundation.md |
| task | MASON-WP-0001-T04 | done | — | workplans/MASON-WP-0001-foundation.md |
| task | MASON-WP-0001-T05 | done | — | workplans/MASON-WP-0001-foundation.md |
| task | MASON-WP-0002-T01 | todo | — | workplans/MASON-WP-0002-whitehat-foundational-plane.md |
| task | MASON-WP-0002-T02 | todo | — | workplans/MASON-WP-0002-whitehat-foundational-plane.md |
| task | MASON-WP-0002-T03 | todo | — | workplans/MASON-WP-0002-whitehat-foundational-plane.md |
| task | MASON-WP-0002-T04 | todo | — | workplans/MASON-WP-0002-whitehat-foundational-plane.md |

View file

@ -0,0 +1,154 @@
---
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"
---
# 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.
## Adopt and pin the bounded plane contract
```task
id: MASON-WP-0002-T01
status: todo
priority: high
```
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
```
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
```
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
```
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.