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

Propose WH-ENG-20260822-AUDIT-E2-01 without authorizing traffic

Browse source 
Align plane ordering with Mason's apply, record the fresh audit-core
engagement as proposed, and keep offline admission fail-closed until
operator approval and owner acknowledgement exist.

Assistant: grok
Assistant-Session: 01a02670-3345-76f2-a014-70fde8e2a2bb
This commit is contained in:
tegwick 2026-08-22 11:46:58 +02:00
parent 7e83a66573
commit 5082f86c61
12 changed files with 176 additions and 19 deletions
Download patch file Download diff file Expand all files Collapse all files

31
plane/README.md
View file

@ -1,10 +1,25 @@
# Governed test plane
Contract only. This repository does not apply cluster objects, request
credentials, or send packets. `ops-mason` provisions from these files after a
**new, unretired** engagement ID exists. Cancelled IDs
This repository does not apply cluster objects, request credentials, or send
packets. `ops-mason` provisions the foundational plane from these files
**before** a fresh engagement is proposed. Cancelled IDs
`WH-ENG-20260821-AUDIT-E2` and `WH-ENG-20260821-TENANT-E2` are terminal.
## Ordering
1. Foundational plane: Namespace `whitehat`, default-deny NetworkPolicy,
audit-core egress NetworkPolicy, ServiceAccount `whitehat-runner` with
`automountServiceAccountToken: false`.
2. A **new** unretired engagement proposal (`status: proposed`).
3. Operator approval and target-owner acknowledgement.
4. Custody projection of two short-lived identities into the runner mount.
5. `whitehat admit-plane`, then a runner pod. Not before.
ops-mason applied step 1 on 2026-08-22 (evidence `c26a6e5`, bundle digest
`9636f48f0b994118ff60a8c014e0099486945d66a2b3d3582dc57a09862b2035`). The
namespace had zero Pods and zero Secrets at apply. That apply authorizes no
runner, credential, engagement or traffic.
## Controls
1. Namespace `whitehat`, default-deny networking, explicit target egress.
@ -20,8 +35,8 @@ credentials, or send packets. `ops-mason` provisions from these files after a
## Standing versus live
`fixture-e2` is the in-process class already permitted by the rules of
engagement. `live-e2` still needs a dated engagement, target-owner
acknowledgement, plane namespace, pinned digest and a connected custody
broker. `e3` and `capacity` are separate approval classes and will not be
admitted by the E2 plane.
`fixture-e2`, `fixture-e3` and `fixture-capacity` are in-process classes
already permitted by the rules of engagement. `live-e2` still needs a dated
engagement, target-owner acknowledgement, the provisioned plane namespace, a
pinned digest and a connected custody broker. Live `e3` and `capacity` keep
separate approval classes and extra envelope fields.