Kubernetes NetworkPolicy: A Practical Zero-Trust Guide

Kubernetes makes it easy for Pods to communicate, but an unrestricted cluster network also gives a compromised workload room to move. A vulnerable frontend might reach a database it never needed, a test namespace might call production services, or malware might send data to the internet. Kubernetes NetworkPolicy lets teams describe which network connections are allowed at the Pod level and deny traffic that is outside the application's intended communication paths.

NetworkPolicy is a native Kubernetes API for controlling ingress to selected Pods and egress from selected Pods. It is best understood as application-aware network segmentation, not a complete firewall or service-mesh replacement. This guide explains the policy model, default-deny rollout, selectors, DNS and internet access, testing, troubleshooting, operational controls, and common mistakes.

What NetworkPolicy solves

Kubernetes networking normally assumes that Pods can communicate across the cluster. Namespaces organize resources and RBAC controls access to the Kubernetes API, but neither automatically blocks Pod-to-Pod traffic. NetworkPolicy adds a data-plane rule: a selected Pod may accept or initiate only the connections allowed by applicable policies. That reduces unnecessary reachability and limits the blast radius of a compromised workload.

A policy is namespaced. Its podSelector chooses destination or source Pods within that namespace. Ingress rules describe allowed incoming connections; egress rules describe allowed outgoing connections. Peers can be selected by podSelector, namespaceSelector, both selectors together, or ipBlock. Ports can narrow the rule by protocol and port.

First verify that enforcement is supported

Creating a NetworkPolicy object does not guarantee enforcement. The cluster's network plugin must implement NetworkPolicy. If it does not, Kubernetes can accept the YAML while traffic remains unrestricted. Before rollout, identify the installed CNI or network provider, read its supported feature set, and run a simple allow-deny test. Managed Kubernetes products may require a specific networking mode or policy engine.

Provider behavior matters for extensions and edge cases. Some implementations support only the standard API; others add policies for DNS names, Layer 7 HTTP rules, logging, or cluster-wide scope. Build portable baseline isolation with standard NetworkPolicy, then document any provider-specific controls separately so migration and incident response remain understandable.

How policy selection and isolation work

A Pod is non-isolated for ingress until at least one ingress policy selects it. Once selected, only ingress traffic allowed by the union of all applicable ingress policies is accepted. Egress works the same way: a Pod becomes egress-isolated when an egress policy selects it. Policies are additive; they do not contain explicit deny rules that override allows. Traffic must be allowed by the source Pod's egress side and the destination Pod's ingress side when both sides are isolated.

An empty podSelector selects every Pod in the policy's namespace. A selector such as matchLabels: app: api selects only matching Pods. Labels therefore become security inputs. Establish controlled, consistent labels for application, component, environment, and access role. Restrict who can change workloads and labels, because changing a label can change which policies protect or permit a Pod.

Start with default deny

A strong baseline denies traffic unless an allow policy exists. For ingress, create a policy with podSelector: {}, policyTypes: [Ingress], and no ingress rules. For egress, use podSelector: {}, policyTypes: [Egress], and no egress rules. A combined policy can deny both. Apply these per namespace only after mapping required flows, because a sudden default deny can break DNS, metrics, identity, storage, webhooks, and application dependencies.

Default deny is a foundation, not the finished design. Add narrowly scoped allow policies for each legitimate path: ingress controller to frontend, frontend to API, API to database, monitoring to metrics endpoints, jobs to required services, and workloads to DNS. Prefer many small policies with clear names and ownership over one large policy containing unrelated exceptions.

Example: frontend, API, and database

Imagine three Deployments labeled app: frontend, app: api, and app: database. The desired graph is user traffic through an ingress controller to frontend, frontend to API on port 8080, and API to database on port 5432. The database should not accept direct connections from frontend or arbitrary Pods. Default deny removes implicit paths, while individual policies restore only these required edges.

A database ingress policy selects app: database and allows from Pods labeled app: api on TCP 5432. If the API is in another namespace, use namespaceSelector together with podSelector. Be careful with YAML structure: when namespaceSelector and podSelector appear in the same from item, both conditions select Pods in matching namespaces. Separate list items mean either peer can match, which is broader.

An API ingress policy selects app: api and allows from app: frontend on TCP 8080. An API egress policy allows the database and DNS. The frontend egress policy allows the API and DNS. The result is a communication graph that reviewers can compare with architecture diagrams, rather than a cluster in which every Pod can reach every service.

Namespace selectors and trusted labels

A namespaceSelector matches labels on Namespace objects. Many clusters expose the immutable kubernetes.io/metadata.name label, which can select one namespace by name. Custom labels such as environment: production are useful but must be governed. If developers can relabel namespaces freely, they may accidentally or deliberately gain access intended for trusted namespaces.

For shared platforms, define who owns namespace security labels, how changes are reviewed, and how policies are generated. Admission controls can require standard labels and reject unsafe configurations. Do not assume similarly named namespaces are equivalent; selectors match labels, not human intentions.

DNS is the most common egress surprise

After egress default deny, applications may fail because they cannot query cluster DNS. Allow UDP and TCP port 53 to the DNS Pods or service path appropriate for the cluster. Do not blindly allow port 53 to every destination, because that broadens reachability and can enable unexpected DNS endpoints. Verify the DNS deployment namespace and labels rather than copying an example unchanged.

DNS permission does not automatically allow the resolved destination. Standard NetworkPolicy is primarily based on Pod, namespace, and IP selectors, not domain names. If a workload must reach a changing external hostname, investigate the CNI's supported FQDN policy or use a controlled egress gateway or proxy. Document that provider-specific dependency.

External traffic and ipBlock

ipBlock allows or excludes CIDR ranges and is useful for stable external networks. It is usually a poor way to identify Pods because Pod addresses can change and translation behavior varies. Kubernetes documentation notes that traffic rewriting may occur before or after policy evaluation depending on implementation and path, affecting which source or destination IP a policy observes.

Avoid allowing 0.0.0.0/0 merely to make an application work. If broad internet egress is truly required, route it through monitored controls, limit destination ports, and combine network policy with proxy rules, workload identity, TLS verification, and application authorization. Network reachability alone does not establish trust.

NetworkPolicy is not an application firewall

Standard policies generally work at IP address, protocol, and port. They do not understand users, HTTP routes, JSON payloads, database rows, or business authorization. A rule allowing TCP 443 permits network access to that endpoint; the application must still authenticate the caller, authorize the action, validate input, and encrypt sensitive data.

NetworkPolicy also does not replace RBAC, Pod Security Standards, secrets management, image scanning, runtime controls, node hardening, or service-mesh identity. Use it as one layer in a zero-trust design: minimize reachability, authenticate every meaningful request, authorize at the service, encrypt traffic where required, and observe both allowed and denied flows.

Safe rollout strategy

Begin with inventory. Capture service dependencies from architecture documents, manifests, traces, flow logs, and interviews. Observe actual traffic across peak and scheduled workloads, but do not assume every observed connection is legitimate. Separate required flows from accidental or obsolete ones. Identify DNS, telemetry, identity, time synchronization, package repositories, cloud metadata, and control-plane dependencies.

Next create policies in a development environment and exercise realistic tests. Roll out one namespace or application tier at a time. Where the provider supports policy auditing or dry-run-like visibility, use it; otherwise combine flow observation with deliberate connectivity tests. Keep a tested rollback manifest and never remove baseline security permanently as a troubleshooting shortcut.

Manage policies in Git beside workloads or in a dedicated platform repository. Use review, automated validation, policy checks, and staged deployment. Record an owner, purpose, expected flows, and expiry for temporary exceptions. A network policy change is a security change and should receive the same discipline as firewall or IAM changes.

Testing that proves isolation

Positive tests confirm required paths: frontend reaches API, API reaches database, and applications resolve DNS. Negative tests are equally important: frontend cannot connect directly to database, a Pod in an unrelated namespace cannot call API, and database cannot reach the internet when it has no egress requirement. Test TCP and UDP separately where relevant.

Run tests from Pods that accurately represent labels, namespaces, service accounts, and network paths. Testing from a node or administrator laptop may bypass the path being controlled. Repeat tests after scaling, rolling updates, namespace changes, CNI upgrades, and policy refactoring. Include these checks in CI for manifests and in post-deployment verification for real clusters.

Troubleshooting a blocked connection

First confirm the endpoints and ports: service selector, EndpointSlices, container port, targetPort, and protocol. Next list every NetworkPolicy selecting the source for egress and destination for ingress. Remember that allows are the union of applicable policies. Check Pod and Namespace labels exactly, including capitalization and rollout labels. Then confirm the CNI is enforcing the standard features used.

Test DNS separately from destination connectivity. Compare direct Pod IP, Service ClusterIP, and external destination behavior to identify translation issues. Inspect provider flow logs or policy verdicts when available. Avoid deleting all policies during debugging; instead reproduce in a controlled namespace and change one rule at a time.

Frequent mistakes

Common failures include assuming namespaces isolate traffic automatically, applying default deny before discovering dependencies, forgetting DNS, using a podSelector that matches nothing, confusing same-item selector AND behavior with separate-item OR behavior, allowing broad CIDRs, depending on mutable security labels, and testing from an unrepresentative location. Another mistake is writing policies but never confirming that the CNI enforces them.

Teams also create permanent allow-all exceptions after an outage. Treat every emergency exception as time-limited work with an owner and removal date. Restore least privilege after diagnosis, add a regression test for the missed dependency, and improve rollout documentation so the next release does not repeat the incident.

Operational checklist

Confirm NetworkPolicy support and version compatibility. Label workloads and namespaces consistently. Apply ingress and egress default deny. Allow DNS narrowly. Express each required application flow with specific selectors, protocols, and ports. Review external egress and translation behavior. Protect label changes. Store policy as code. Test positive and negative paths. Enable flow visibility. Audit exceptions and reassess policies when architecture changes.

Frequently asked questions

Does a Kubernetes namespace block network traffic?

No. A namespace scopes names and resources, but it does not automatically isolate Pod traffic. NetworkPolicy and an enforcing network plugin are needed for policy-based network segmentation.

Do policies apply in a specific order?

No priority order is used for standard NetworkPolicy allows. Applicable policies are additive, and their allowed connections are combined. Model narrow allows on top of default-deny isolation.

Can NetworkPolicy filter HTTP paths?

Standard NetworkPolicy does not provide HTTP route or method filtering. Use application authorization, an API gateway, ingress controls, a service mesh, or supported CNI extensions when Layer 7 rules are required.

Why did egress default deny break my application?

DNS is a frequent cause, followed by identity, telemetry, external APIs, package services, and cloud endpoints. Inventory dependencies and restore only the required destinations and ports.

Can I use NetworkPolicy on Docker Desktop Kubernetes?

Support depends on the networking implementation and configuration, not merely on the Kubernetes API accepting the object. Verify the current environment's CNI capabilities and test enforcement before using it for a security claim.

Turn the network diagram into enforceable policy

The clearest NetworkPolicy design starts with an architecture graph: which component needs to initiate traffic to which destination, on what protocol and port. Default deny removes every unplanned edge; small allow policies restore the intended ones. That approach makes reviews, tests, and incident analysis easier than trying to secure a flat network after deployment.

NeoAI Tech helps learners and teams turn Kubernetes, DevOps, cloud, and cybersecurity concepts into practical implementations. Use this guide as a checklist for a lab cluster first, then adapt it carefully to the CNI, workloads, and operational controls of each production environment.

Related NeoAI Tech guide: Kubernetes for Beginners

Related NeoAI Tech guide: Deploy a Machine Learning Model on Kubernetes

Related NeoAI Tech guide: OpenTelemetry for Python Flask

Authoritative references

Kubernetes: Network Policies

Kubernetes: Declare Network Policy

Kubernetes API: NetworkPolicy v1

Kubernetes: Security Checklist

Kubernetes: Multi-tenancy