Review Kubernetes NetworkPolicy Changes in Coding-Agent Patches

Last reviewed: November 6, 2026 (Asia/Shanghai); official references checked November 5 UTC.

Direct answer

A Kubernetes NetworkPolicy review should establish which Pods the rendered policy selects, which direction it isolates, and which connections every applicable policy permits. Check namespace and Pod selectors together, specify protocols and ports, and verify the installed network plugin enforces NetworkPolicy. Then test fresh connections from both approved and unapproved peers in a disposable environment that represents the target cluster.

Two details deserve particular attention in an agent-written diff. A namespaceSelector and podSelector in the same peer entry combine as AND; putting them in separate list entries creates alternatives. Policies also combine additively: a default-deny policy cannot subtract access granted by another policy. The Kubernetes Network Policies reference defines both behaviors. A small indentation change or a forgotten allow-all policy can therefore defeat the intended restriction while leaving valid YAML.

Who this is for

Use this workflow when a coding agent edits application NetworkPolicies, Helm values, Kustomize overlays, or workload labels used by policy selectors. It is intended for maintainers reviewing communication between ordinary Pod-network workloads. Platform-specific policies and hostNetwork workloads need review against their implementation’s documented behavior.

Give the agent the approved traffic requirements and affected configuration paths. Ask it to render the manifests, explain effective reachability, and propose a patch. Apply test changes only through the team’s authorized disposable-cluster workflow; production policy changes remain subject to the existing deployment approval process.

Key takeaways

• Resolve selectors against actual namespace and Pod labels, including the rendered workload template.
• Review ingress and egress independently; an ingress restriction does not restrict outbound connections.
• Combine allowances from every policy selecting the workload in that direction.
• Keep namespace and Pod selectors in one peer entry when both conditions must hold.
• Separate DNS resolution, transport connectivity, and application authorization in the test evidence.
• Use fresh connections and paired controls; a timeout alone does not establish policy enforcement.

Sources checked

Three primary Kubernetes pages were retrieved successfully on November 5, 2026 UTC:

• Network Policies documents enforcement prerequisites, independent isolation directions, additive allowances, selector composition, default policies, propagation, and existing-connection limitations.
• Declare Network Policy demonstrates checking connectivity before and after applying a policy, then comparing clients with and without an allowed label.
• DNS for Services and Pods explains namespace-sensitive Service lookup, normal versus headless Service records, and Pod DNS policies.

These maintained technical references support an evergreen review task. Match documentation to the target Kubernetes version and network implementation before adopting a rule. The examples and acceptance criteria below are recommendations; this article reports no executed cluster tests or deployment results.

Contract details to verify

Write the traffic requirement before editing YAML

Describe each required connection as a source, destination, transport, and purpose. For example: frontend Pods in review-clients may connect to API Pods in review-backend on TCP port 8080. Other Pods, namespaces, and application ports are outside that requirement.

Render all affected environments. An agent can preserve the policy file while changing a Deployment label so that its Pods no longer match. Conversely, broadening a selector may pull unrelated workloads into isolation and interrupt their dependencies. Include namespace-label changes and label ownership in the review: a label is useful for selection only when its writers are appropriately controlled.

The Kubernetes RBAC review guide helps inspect who can change those objects. For the separate task of designing a sandbox’s destination inventory, use Network Egress Allowlists for Coding Agent Sandboxes .

Resolve AND and OR explicitly

This ingress example selects API Pods in review-backend. It permits TCP 8080 from Pods labeled app: frontend in review-clients. Both namespaces and the workloads must already exist in the authorized test environment.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-from-reviewed-frontend
  namespace: review-backend
spec:
  podSelector:
    matchLabels:
      app: api
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: review-clients
          podSelector:
            matchLabels:
              app: frontend
      ports:
        - protocol: TCP
          port: 8080

The control plane supplies the immutable namespace label kubernetes.io/metadata.name, whose value is the namespace name. The podSelector beside that namespace selector narrows the permitted peers within the selected namespace. Inspect the rendered policy with kubectl describe networkpolicy as an additional check of its interpretation.

Compare the following deliberately broader fragment. It is a counterexample for review, not a replacement for the preceding rule:

from:
  - namespaceSelector:
      matchLabels:
        kubernetes.io/metadata.name: review-clients
  - podSelector:
      matchLabels:
        app: frontend

The extra list marker creates two alternatives: any Pod in review-clients, or a frontend Pod in the policy’s own namespace, review-backend. It no longer requires both namespace and Pod identity. A test from the approved frontend will pass under either version, so include an unapproved Pod in review-clients and a frontend-labeled Pod in review-backend as negative cases.

The full policy above controls destination ingress only. If the sender is isolated for egress, its applicable policies must also permit the connection. Other ingress policies selecting the API Pods can grant additional access beyond this example.

Calculate the union of applicable allowances

For each selected workload, list all policies that apply to ingress and all that apply to egress. The Network Policies reference states that the allowed connections are the union of applicable rules, with no ordering-based override.

Read empty objects and lists carefully:

A no-allow policy isolates the selected direction, but another selecting policy can still allow traffic. Find broad policies before concluding that a new default-deny manifest closes access. Also check that the policy selects at least the intended Pods; a correct rule matching zero workloads provides no protection for the application.

Ordinary NetworkPolicy is an IP-and-port control. Its API does not select a Service by name or supply TLS validation and application authentication. Test the application’s actual Service route because address translation and the network implementation can affect IP-based rules. Treat stronger identity or application-layer controls as separate requirements.

Verify DNS separately from the application connection

A deny-all egress policy also blocks DNS unless an applicable allowance permits the required resolver traffic. Identify the resolver actually used by the Pod, including any node-local DNS arrangement, before proposing a DNS rule. Avoid copying a generic DNS-Pod selector into a cluster that uses a different path.

The DNS reference explains that an unqualified Service name is resolved in the caller’s namespace. In this example, a client in review-clients should use api.review-backend for a Service named api in review-backend; the short name api refers to the client’s namespace. A normal Service record resolves to its cluster IP, while a headless Service returns backing Pod addresses.

Record name resolution and the subsequent TCP connection as separate checks. Successful DNS does not grant application access. Failed DNS does not demonstrate that the destination’s ingress policy blocked the client.

Happy-path workflow: prove the intended connection

Use synthetic workloads and data in a disposable cluster with the target network plugin. Establish that the destination is ready and listening, and that the chosen test client can connect before introducing the candidate restriction. The official walkthrough uses this before-and-after approach and compares clients with different labels.

Have the authorized deployment workflow install the rendered candidate. Inspect the effective labels and all applicable policies. Allow bounded time for the plugin to process changes, then open a fresh connection from the approved frontend to TCP 8080 through the actual Service path. Require the expected harmless application response, not merely a successful name lookup.

Capture the candidate revision, cluster and plugin versions, source namespace and labels, destination, protocol, port, deadline, and observed result. Keep credentials and application payloads out of the review record.

Error-path workflow: isolate why a connection failed

Run the negative cases with healthy clients and a known-listening destination. Change one selector dimension at a time. Keep the approved client as a contemporaneous positive control so a destination outage cannot make every forbidden case appear successful.

Other policies and sender restrictions must be included when interpreting these expectations. For the port case, a refusal from a closed listener is insufficient; first establish that the test port accepts the harmless fixture connection without the candidate restriction.

If a forbidden connection succeeds, inspect selector membership, list structure, and other allowances before changing ports or adding policies. If the approved connection fails, investigate DNS, readiness, source egress, destination ingress, and policy propagation separately. Preserve the first result and diagnostic context. Stop approval when enforcement remains uncertain rather than widening access to make the test green.

Failure modes

Valid YAML is treated as enforcement evidence. API acceptance does not prove the network plugin implements the rule. Require runtime connection checks.

A default-deny policy is expected to override allow-all. Ordinary NetworkPolicies are additive. Remove or narrow the unintended allowance through the reviewed change process.

Only the approved peer is tested. Both AND and OR variants can permit it. Use the wrong-label and wrong-namespace cases to distinguish them.

An old connection is reused after a policy change. Kubernetes leaves the effect on existing connections implementation-defined. Reconnect for each acceptance case and evaluate session revocation separately if required.

One immediate timeout is accepted as a denial. Policy propagation is asynchronous, and outages produce similar symptoms. Use bounded repeated checks with a working positive control and the implementation’s available diagnostics.

FAQ

Does a default-deny policy close access granted elsewhere?

No. It contributes no allowances while isolating its selected direction. Another applicable NetworkPolicy can still permit the connection.

Does allowing ingress also allow outbound requests?

No. Ingress and egress isolation are independent. Replies to an allowed connection are implicitly permitted, but unrelated outbound connections require their own egress evaluation.

Can a manifest alone prove the plugin is enforcing policy?

No. Kubernetes can accept a NetworkPolicy even when the network implementation does not enforce it. Verify the implementation and exercise allowed and forbidden connections.

Will this policy authenticate the frontend application?

No. It restricts network peers and ports using selectors. Keep application authentication, authorization, and TLS checks in the application or appropriate platform layer.

Reader next step

Choose one agent-written NetworkPolicy change. Render it with the affected workload labels, enumerate every applicable allowance, and write one permitted connection plus wrong-label and wrong-namespace cases. Run those checks with fresh connections in the approved disposable environment. Attach the selector explanation, DNS result, positive control, negative results, and exact candidate revision before approving the patch.