coulomb/ops-mason
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

build: add guarded Kubernetes plane executor

Browse source 
Assistant: codex
Assistant-Model: gpt-5.6-sol
Assistant-Session: 01a02878-7c21-7692-bcd6-ce2838c4b448
This commit is contained in:
tegwick 2026-08-22 11:23:38 +02:00
parent 1dd98b4f27
commit 2b318634b6
13 changed files with 1240 additions and 3 deletions
Download patch file Download diff file Expand all files Collapse all files

87
plans/whitehat-foundational-plane.md Normal file
View file

@ -0,0 +1,87 @@
---
id: whitehat-foundational-plane
demand_source: "statehub-message:311a274e-9434-4fc3-bc52-8ea15ca68274"
consumer_repo: whitehat-security
credential_type: kubernetes-foundational-plane
status: approved
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
Pending guarded apply and metadata-only verification.