#3677 was the right call. networkPolicyEnforced was an operator claim with nothing behind it, and a flag that can be set on a cluster where nothing enforces reads like a check it is not. This asks for the option between that flag and a prerequisite: measure the fence.
The Kubernetes driver already fails closed on the policy object. validate_sandbox_runtime_fence compares the persisted spec, labels and annotations with the intended ones, and KubernetesOuterFenceEvidence::project then establishes DefaultDenyEgress, NoUnmanagedEgressPath, RevocationVerified and ControllerLossFailsClosed from the policy's UID and resourceVersion. All of that is control-plane state. The API server stores the same object when no CNI enforces it, so on that cluster the descriptor records all four guarantees and the sandbox starts.
The contract asks for more than that. from_enforcement_evidence "deliberately does not infer guarantees from the mere presence of evidence", and DefaultDenyEgress is defined as "No workload packet can leave without an explicit mediated decision". The Docker driver meets it by inspecting the running container, where the daemon that reports network_mode=none is the one enforcing it. Kubernetes has no equivalent, because the enforcer is the CNI and the API does not report on it.
Proposal, once per sandbox namespace before the boundary is confirmed:
- After the workload fence is validated, have a pod under that policy attempt one connection to a destination the empty-egress policy must drop.
- Project the four guarantees only if that attempt fails. Otherwise
validate() rejects the boundary, as it already does when a guarantee is missing.
- Cache the result per namespace, keyed to the policy UID and generation, so it is not a per-sandbox cost.
The open design question is the destination. It has to be reachable by the cluster network and dropped by the policy, which varies by cluster; a configurable target with a gateway-service default would work. docs/security/best-practices.mdx could carry the CNI caveat next to "enforce all network controls" in the meantime.
Happy to write the probe if the shape is wanted.
#3677 was the right call.
networkPolicyEnforcedwas an operator claim with nothing behind it, and a flag that can be set on a cluster where nothing enforces reads like a check it is not. This asks for the option between that flag and a prerequisite: measure the fence.The Kubernetes driver already fails closed on the policy object.
validate_sandbox_runtime_fencecompares the persisted spec, labels and annotations with the intended ones, andKubernetesOuterFenceEvidence::projectthen establishesDefaultDenyEgress,NoUnmanagedEgressPath,RevocationVerifiedandControllerLossFailsClosedfrom the policy's UID and resourceVersion. All of that is control-plane state. The API server stores the same object when no CNI enforces it, so on that cluster the descriptor records all four guarantees and the sandbox starts.The contract asks for more than that.
from_enforcement_evidence"deliberately does not infer guarantees from the mere presence of evidence", andDefaultDenyEgressis defined as "No workload packet can leave without an explicit mediated decision". The Docker driver meets it by inspecting the running container, where the daemon that reportsnetwork_mode=noneis the one enforcing it. Kubernetes has no equivalent, because the enforcer is the CNI and the API does not report on it.Proposal, once per sandbox namespace before the boundary is confirmed:
validate()rejects the boundary, as it already does when a guarantee is missing.The open design question is the destination. It has to be reachable by the cluster network and dropped by the policy, which varies by cluster; a configurable target with a gateway-service default would work.
docs/security/best-practices.mdxcould carry the CNI caveat next to "enforce all network controls" in the meantime.Happy to write the probe if the shape is wanted.