Context
A new restrictive NetworkPolicy does not necessarily remove access granted by another policy. Standard Kubernetes NetworkPolicies combine applicable allowances. An application can therefore remain reachable even when a newly added policy appears to allow only a narrow path. The review must consider the effective set, not one YAML file in isolation.
Imagine an illustrative namespace where a team adds a database restriction. A connection from an unexpected application still succeeds. The team assumes enforcement is broken, but an older broad allow policy also selects the database. Both policies are operating according to their combined semantics. The first task is to inventory every applicable policy and selector.
Understand the direction and union model
Kubernetes documents that NetworkPolicies are additive and that permitted traffic is the union of applicable allowances for a direction. For a connection between isolated Pods, the relevant source egress and destination ingress must both allow it. Enforcement also requires a network implementation that supports NetworkPolicy. 1
Create a simple flow inventory: source identity, destination identity, protocol, port, direction, and business purpose. Keep namespace labels and Pod labels in the record. A selector is meaningful only when it matches the actual labels in the live cluster.
Verify enforcement before tuning rules
Identify the CNI and policy capabilities in use. Standard NetworkPolicy does not describe every feature offered by a vendor's additional policy API, and the two should not be mixed casually in a review. Confirm the installed implementation and version support the controls the team expects.
Run a safe baseline test in a dedicated test context using the intended policy model. A manifest accepted by the API server is not proof that traffic is enforced. Preserve the source Pod, destination, protocol, result, and relevant policy state so the test can be repeated after a network upgrade.
Review all selectors that affect the flow
Inspect every policy selecting the source for egress and every policy selecting the destination for ingress. Check namespaceSelector and podSelector combinations carefully. Their placement in the YAML determines whether conditions are combined within one peer or expressed as separate alternatives.
Avoid relying on naming conventions as if they were selectors. A Pod named frontend is not selected by a role label unless the label exists. Also review who can change namespace or Pod labels, because those labels participate in the access boundary. The operational ownership of labels matters alongside the network rules.
Include DNS as an explicit dependency
An application may need DNS before it can connect to an approved service. Blocking the resolver path can make a narrow egress policy appear to block every external dependency. Identify the actual resolver architecture, including any node-local DNS component, before writing the allow rule.
Test the required UDP and TCP DNS paths as appropriate to the environment. A successful cached lookup is not enough; use a controlled uncached query or another suitable validation. Avoid broadly allowing all egress just to restore name resolution. Keep the resolver allowance separate from permission to connect to the resolved destination.
Test denied flows as well as allowed flows
A positive test proves one path works. An isolation claim also needs expected rejections. Use a small matrix with an approved source, an unapproved source, an approved port, and an unapproved port. Keep the tests within resources owned or authorized for the exercise.
Use new connections when testing policy changes, since existing-connection behaviour can depend on the implementation. Record whether a test involved direct Pod addressing, a Service, or another path. Address translation and policy evaluation details can affect how a particular implementation sees the traffic, so use its documentation for the deployed path.
Do not confuse network reachability with authorization
A permitted TCP connection does not grant application access. Databases and APIs still need authentication, tenant authorization, and appropriate encryption. Likewise, an application-level rejection can mean the network allowed the request successfully. Keep those outcomes separate in the test report.
For an illustrative internal API, the network test might confirm that only the worker namespace reaches port 8443, while the application test confirms that the worker identity can perform only its assigned operation. Each test addresses a different boundary. Neither should be presented as proof of the other.
Roll out restrictions with a recovery path
Map required flows before changing a busy namespace, then test a representative workload. Observe connection errors, DNS failures, and business outcomes after enforcement. Keep the previous policy version and a narrow recovery procedure available through the normal configuration source.
When an emergency allowance is necessary, record the missing dependency and an expiry or review checkpoint. A permanent broad exception added under pressure can erase the intended isolation while leaving the restrictive-looking policy in place. Periodic review should examine the effective union again, including exceptions.
Keep the policy inventory connected to releases
New dependencies, changed ports, and new namespace labels should trigger a network contract review. Include the connectivity matrix in onboarding and release checks so a service does not first discover a blocked dependency during production traffic.
A focused operator exercise: A four-flow isolation sample
Create an approved test source, an unapproved test source, and a destination exposing one intended test port. Check the approved source on the approved port, the approved source on another port, the unapproved source on the approved port, and required DNS resolution. Record the expected result for each before applying the policy.
Repeat with fresh connections after rollout and compare the effective policies selecting both endpoints. If an unexpected flow succeeds, inspect the full additive allowance rather than editing only the newest manifest. Keep the actual CNI and resolver design in the record so the sample remains meaningful after network upgrades or a move to node-local DNS.
Quick diagnostic map
| Evidence | Review | Acceptance boundary |
|---|---|---|
| Policy union | Inspect all policies selecting each Pod | Combine allowed ingress and egress correctly |
| DNS route | Test resolver access separately | Include the actual DNS destination and protocol |
| Isolation sample | Exercise allowed and forbidden flows | Confirm enforcement by the installed network plugin |
Frequently asked questions
Does the most restrictive policy win? Standard NetworkPolicy does not operate as a last-rule or most-restrictive firewall list. Review the applicable allowed union.
Clouvenix can map the effective flows and validate both permitted and denied connections, helping teams turn NetworkPolicy manifests into demonstrable application isolation.
For a scoped review of this workflow, discuss the relevant Clouvenix engineering service.