ops-mason/plans/whitehat-foundational-plane.md

id	demand_source	consumer_repo	credential_type	status	approved_by	approved_at	created	updated
whitehat-foundational-plane	statehub-message:311a274e-9434-4fc3-bc52-8ea15ca68274	whitehat-security	kubernetes-foundational-plane	approved	Bernd Worsch	2026-08-22	2026-08-22	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

Pending guarded apply and metadata-only verification.