---
id: whitehat-foundational-plane
demand_source: "statehub-message:311a274e-9434-4fc3-bc52-8ea15ca68274"
consumer_repo: whitehat-security
credential_type: kubernetes-foundational-plane
status: built
approved_by: "Bernd Worsch"
approved_at: "2026-08-22"
created: "2026-08-22"
updated: "2026-08-22"
---

# Construction plan: Whitehat foundational plane

## 1. Demand

Provision the non-running Kubernetes foundation requested by
`whitehat-security` and confirmed by `audit-core`: Namespace `whitehat`, a
default deny boundary, exact audit-core/DNS egress for future labelled runner
Pods, and a no-token `whitehat-runner` ServiceAccount. This is foundation for a
later governed engagement, not an engagement or packet itself.

## 2. Existing-structure survey

Read-only inspection on 2026-08-22 found no `whitehat` Namespace. The active
Kubernetes identity can create all four object types. Audit-core Service
`audit-core` listens on TCP 8080 and its `audit-core-whitehat-ingress` policy
already admits only Namespace `whitehat` Pods labelled both
`whitehat.security/plane=true` and `whitehat.security/target=audit-core`.

The selected Whitehat manifests entered at implementation revision `95129d7`
and are unchanged at requested coordination revision `4882c2d`. Reuse those
objects exactly; do not design a parallel policy shape.

## 3. Proposed changes

| # | Action | Object | Reason |
|---|---|---|---|
| 1 | create | Namespace `whitehat` | Dedicated restricted security boundary |
| 2 | create | NetworkPolicy `default-deny` | Deny ingress and egress by default |
| 3 | create | NetworkPolicy `allow-audit-core-e2` | Exact future-runner egress to audit-core:8080 and DNS only |
| 4 | create | ServiceAccount `whitehat-runner` | Stable name with token automount disabled |

No Pod, Secret, credential, projected identity, custody lease, engagement ID,
or target traffic is created. The two 2026-08-21 engagement IDs remain
cancelled and are never reused.

## 4. Review notes

- **Reuse:** source and target policies already agree; no redundant policy is
  introduced.
- **Scope:** the egress allow selects only future Pods labelled for audit-core.
- **Identity:** the ServiceAccount cannot receive an automatic API token.
- **Reversal:** delete the two policies and ServiceAccount; delete the
  Namespace only after proving it remains foundation-only.
- **Automation:** apply is gated by this approval, an immutable bundle digest,
  exact object allowlist, committed inputs, current context, RBAC, dependency
  assertions, server dry-run, and metadata-only verification.

## 5. Executive summary

**One-line ask:** create a dormant, restricted Whitehat namespace boundary that
can later host a separately approved audit-core E2 runner.

**Who/what gets access:** no running workload gets access now. A future Pod must
carry the exact audit-core target label before the egress allow selects it.

**To what:** TCP 8080 in Namespace `audit-core`, plus TCP/UDP 53 in
`kube-system`. All other ingress and egress remains denied.

**For how long:** the foundation is standing infrastructure. Any future
credential or runner remains separately time-bounded by its engagement.

**Blast radius:** a wrongly labelled future Pod could reach audit-core:8080 and
DNS, but no other namespace/port through these policies. This plan creates no
credential and sends no request.

**Cost to reverse:** delete three namespaced objects, inventory the Namespace,
then delete it only if it contains no later or unrelated resources.

**Decision:** approved by Bernd Worsch on 2026-08-22 via the explicit operator
instruction to implement MASON-WP-0002. Approval is limited to the four objects
above and does not extend to a runner, credential, engagement, or traffic.

## 6. Build result

Built and verified on 2026-08-22 with the guarded executor introduced in
ops-mason commit `2b31863` and immutable bundle digest
`9636f48f0b994118ff60a8c014e0099486945d66a2b3d3582dc57a09862b2035`.

- created Namespace `whitehat` with restricted Pod Security enforcement;
- created NetworkPolicies `default-deny` and `allow-audit-core-e2`;
- created ServiceAccount `whitehat-runner` with token automount disabled;
- server-dry-ran every manifest before persistence;
- independently re-verified all desired fields and found zero live drift;
- found zero Pods and zero Secrets in the namespace;
- generated object-scoped rollback plus a separately conditional Namespace
  rollback; no rollback command was executed.

Kubernetes automatically created only its normal `default` ServiceAccount and
`kube-root-ca.crt` ConfigMap alongside the four governed objects. No runner,
credential, projected identity, lease, engagement, or target request exists.
Evidence: `docs/evidence/whitehat-foundational-plane.json` and `.md`.