Segmentation controls permitted connections at a boundary

Consider Kubernetes NetworkPolicy as one concrete policy model, assuming a network implementation that supports and enforces it. A selected pod can be isolated for ingress, egress, or both according to applicable policy. For a new pod-to-pod connection, the source's egress policy and the destination's ingress policy must both permit it when those directions are isolated. Permitting only the destination's ingress does not override a source egress restriction. Routing, listening services, and other controls must still make the allowed connection possible.

Standard NetworkPolicy allow rules combine additively within a direction. A broad allow in one applicable policy is not canceled by placing a narrower allow elsewhere. A default-deny style policy establishes isolation with no allowed peers for its selected direction; subsequent policies can add permissions. Understand selector composition as well: namespace and pod selectors within one peer can constrain the same peer together, while separate peer list items express alternatives. Test the resulting selected population, not just the visual appearance of a manifest.

A layer-three/four rule can permit a source population to reach a destination port without understanding which user requested an object or what the encrypted request means. Mutual TLS can authenticate a workload on that connection, while application policy decides its actions and resource scope. These controls complement one another, but their evidence is not interchangeable. Demonstrating that an unrelated pod cannot connect to a database does not prove that an allowed frontend enforces tenant authorization correctly.

Necessary dependencies complicate minimal policies. Name resolution, telemetry, control-plane access, and certificate renewal may need scoped connectivity. Allowing an entire namespace or unrestricted egress merely to restore DNS can defeat the intended reduction. Conversely, blocking renewal can create an outage days after a seemingly successful segmentation change. Inventory the dependencies and test their actual addresses, ports, and identity boundaries. Established-connection behavior after a rule change can depend on the implementation, so explicitly test fresh connections rather than assuming immediate termination of all prior state.

Run paired tests from allowed and denied sources to the same destination and port. A timeout alone may reflect a missing listener or broken route rather than policy enforcement, so keep a positive control and inspect the enforcement system's available evidence. Then test that a label change or newly created workload does not escape the intended selection scope. Policy behavior must be assessed at the real interfaces and supported protocols; do not extrapolate pod-traffic results to every host-network or infrastructure path without checking documented coverage.

The probability lab examines a synthetic test-selection limitation. Reset, set both p=0.1 for an independently selected forbidden case exposing a mistaken allow and n=20, predict zero detections, then Play or Step. It does not enforce policy or construct a topology. Real forbidden cases often share selectors, ports, and namespaces, so random independence can fail badly. Use the explicit connection matrix to cover each meaningful boundary, including required DNS and renewal paths, rather than accepting a small clean sample as proof of complete segmentation.