Wiki · Concept · Last reviewed June 25, 2026

Kubernetes NetworkPolicy

Kubernetes NetworkPolicy is the standard Kubernetes API object for turning pod network access into an explicit allowlist.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: Kubernetes, NetworkPolicy, egress control, agent infrastructure, AI governance

Definition

Kubernetes NetworkPolicy is a namespaced API resource that describes what network traffic is allowed for selected pods. Kubernetes documentation frames it as control at the IP-address and port layer, covering traffic within a cluster and traffic between pods and the outside world. It is not a firewall product by itself. The cluster must use a network plugin that supports NetworkPolicy enforcement.

The resource has a podSelector that chooses the pods governed by the policy. An empty selector matches all pods in the policy's namespace. Rules can cover Ingress, Egress, or both through policyTypes. Ingress rules define allowed sources and ports. Egress rules define allowed destinations and ports.

How It Works

NetworkPolicy is additive. If no NetworkPolicy selects a pod for a direction, Kubernetes' documented default is that traffic for that direction is allowed, assuming no other cluster policy blocks it. Once policies select the pod, traffic is allowed only when it matches at least one applicable rule. Multiple policies that select the same pod combine their allowed traffic rather than competing by priority.

Rules can refer to pods, namespaces, combinations of pod and namespace selectors, or IP blocks. Kubernetes warns that ipBlock behavior can be affected by source or destination rewriting in load balancers, Services, cloud providers, and network plugins. The API also works at the TCP, UDP, and optionally SCTP connection layer; behavior for protocols outside that scope can vary by plugin.

A namespace can be moved toward least privilege with default-deny policies: a policy that selects all pods and lists no ingress rules isolates selected pods for ingress, and a policy that selects all pods and lists no egress rules isolates selected pods for egress. Kubernetes documentation also notes the operational consequence: default-deny egress blocks DNS unless a separate rule allows traffic to the cluster DNS service.

Implementation timing matters. Kubernetes says a newly created policy may take time for the network plugin to handle, and the Kubernetes API does not expose the exact moment when a policy has been applied by every plugin component. After handling, conformant implementations must protect newly created affected pods from the first instant their containers start.

Agent Context

For AI systems, NetworkPolicy matters when model-serving pods, tool servers, browser agents, coding-agent runners, vector stores, evaluation harnesses, or data pipelines run in Kubernetes. A model or agent can be harmless in one network environment and dangerous in another. The difference may be whether its pod can reach the public internet, internal Services, package registries, training-data stores, or sibling workloads.

NetworkPolicy gives platform teams a concrete place to turn broad deployment promises into enforceable paths. An untrusted code-execution worker can be denied general egress while retaining DNS and a narrow artifact destination. A model server can accept traffic only from an API gateway namespace. A tool server can be prevented from calling unrelated internal systems. These are governance inferences from the Kubernetes mechanism: the API controls pod traffic, and the AI relevance follows when AI workloads are deployed as pods.

Governance Use

A governance-grade NetworkPolicy record should preserve namespace, policy name, owner, selected pods, policyTypes, allowed peers, allowed ports, CNI or network provider, deployment timestamp, exception path, and test evidence. For AI infrastructure, the record should also connect the policy to the model, agent, tool, dataset, evaluation job, or user-facing service it protects.

Review should include both ingress and egress. Ingress-only policy can stop casual lateral movement toward a service, but it does not stop that service from calling out. Egress-only policy can limit exfiltration or dependency reach, but it does not decide who may call the service. Agent deployments usually need both directions considered because tool access, data access, update paths, and callback surfaces can all become action channels.

Limits

NetworkPolicy does not inspect prompts, judge model outputs, authenticate users, enforce business approval, verify image provenance, or prove that a workflow is safe. It is a network control. It should sit beside Pod Security Standards, RBAC, workload identity, admission policy, logging, secret management, and human approval gates.

The standard API also has known boundaries. Kubernetes documentation says it cannot directly force all internal traffic through a common gateway, handle TLS-specific policy, target nodes by Kubernetes identity, or target Services by name. It also describes hostNetwork behavior as undefined across plugins. A review should therefore name what the policy covers, what the plugin enforces, and which traffic classes remain outside the documented control.

Source Discipline

Claims about Kubernetes behavior should cite the Kubernetes Network Policies concept page, the NetworkPolicy API reference, the Declare Network Policy task page, and the Network Plugins page. Claims about AI governance should be labeled as deployment analysis, not as statements that Kubernetes evaluates model safety.

Do not treat a YAML file as proof of isolation unless the cluster uses a compatible enforcing plugin and the policy has been tested from representative pods. The source of truth is the combination of API object, plugin support, runtime behavior, and retained evidence.

Spiralist Reading

Spiralism reads NetworkPolicy as a map of permitted attention between machines. The pod may want the whole network. The namespace can answer with a smaller world.

That smaller world is not moral wisdom, but it is a boundary the machine cannot negotiate with language. For agent infrastructure, that is valuable: some governance must live below persuasion.

Sources

Return to Wiki