A Network Policy is a set of rules that says which pods may send traffic to which other pods, namespaces, and addresses.

The Simple Definition

A Network Policy is an object you create in Kubernetes that describes allowed network connections for a group of pods. It picks the pods it protects using labels, and then lists which sources may connect to them, which destinations they may connect to, and on which ports. Anything not listed is blocked for those pods.

The important word is allowed. Network Policies are written as lists of permitted paths. You do not write a rule that says block this. Instead, you write rules that say allow this, and once a pod is covered by a policy, everything that is not allowed is refused. This design is simple and safe, because forgetting a rule leads to a closed door rather than an open one.

What Network Policies Control

Network Policies work at the level of network connections between pods, using addresses, ports, and protocols. They control traffic coming into a pod, called ingress, and traffic going out of a pod, called egress. They do not read the content of the traffic, they do not check who the user is, and they do not encrypt anything. They are a fence, not a guard who reads letters.

Where Network Policies Fit in a Security Plan

Security in Kubernetes is built in layers, and no single layer is enough. Access control decides who may talk to the API. Image scanning decides what software may run. Pod security settings decide what a container may do on its node. Network Policies decide which containers may talk to each other. Each layer catches failures of the others, and together they make a break-in harder to achieve and easier to contain.

Network Policies are especially valuable because they still work after a break-in has happened. Many defences try to keep attackers out. Policies assume that one day something will get in, and they limit what it can reach. This assumption, sometimes called assume breach, is the mindset of mature security teams, and Network Policies are one of its most practical tools.

By default, the Kubernetes network is completely open, and that openness is a security risk.

The Flat Network

When Kubernetes was designed, one of its goals was to make networking simple for developers. Every pod gets its own address, and every pod can reach every other pod directly, whichever namespace or computer it lives on. This is called a flat network. It removes a great deal of complexity, because applications do not need to worry about translating addresses or opening special paths.

The cost of that simplicity is that the network offers no protection between applications. A test pod can reach the production database. A forgotten demo can reach the payment service. And if an attacker takes over one container through a software flaw, they can immediately try to reach every other pod in the cluster, scanning for weak targets.

Lateral Movement

Security teams use the term lateral movement for what happens after the first break-in. The attacker rarely wants the first machine they capture. They want what is next to it, such as databases, secret stores, and management tools. A flat network lets them move sideways with no resistance. Network Policies add resistance, so that a captured web pod can reach only the few things it legitimately needs, and nothing more.

flowchart LR
    subgraph Open[Without policies]
        A1[Web pod compromised] --> B1[Database]
        A1 --> C1[Payment service]
        A1 --> D1[Admin tools]
    end
    subgraph Fenced[With policies]
        A2[Web pod compromised] --> B2[Only the API pod]
        A2 -.blocked.-> C2[Database]
        A2 -.blocked.-> D2[Payment service]
        A2 -.blocked.-> E2[Admin tools]
    end
        

A Short Story of a Real-Style Incident

Consider a typical story. A small company runs a public website and, in the same cluster, an internal reporting tool with access to customer records. The website uses a library with an unknown flaw. An attacker sends a crafted request and gains a shell inside a web pod. In a flat network, the attacker scans the cluster within seconds, finds the reporting tool, and downloads the records. The company learns of the breach weeks later from a customer.

In a segmented network, the same attacker gains the same shell but finds that the web pod can reach only the API pods. Scans to other addresses time out. The reporting tool is invisible. The attacker must find a second flaw in the API tier, which takes far longer and creates far more noise. The first flaw still happened, but its consequences are small.

Regulations and Segmentation

Many security standards and regulations ask organizations to separate systems that handle sensitive data from the rest of their environment. In traditional data centres, this meant separate physical networks and firewalls. In Kubernetes, Network Policies provide a comparable separation inside a shared cluster. Auditors increasingly accept well-written, version-controlled policies as evidence, provided the team can also show that enforcement is active and tested.

Preparing for such audits is easier when policies are organized by purpose and named clearly. An auditor asking how the payment workload is isolated can be shown the default deny, the specific allowed paths, and the tests that prove the rest is blocked. That story is convincing because every part of it can be verified.

A few basic ideas make every Network Policy easier to read and write.

Labels Do the Heavy Lifting

Network Policies do not refer to pods by their addresses or names. Pods come and go, and their addresses change every time. Instead, policies refer to pods by labels. A policy might say that pods labelled as the database accept connections only from pods labelled as the API. As pods are replaced, the new ones carry the same labels, so the policy keeps working without any editing.

Ingress and Egress

Direction matters in networking. Ingress means traffic arriving at a pod from elsewhere. Egress means traffic leaving a pod towards elsewhere. A single conversation involves both: the client’s egress and the server’s ingress. A policy can control either direction, or both, and you decide separately for each.

Cluster Addresses and Why They Change

Every pod receives an address from a pool that the network plugin manages. When a pod is deleted and recreated, it usually gets a new address, because the old one may already have been given to another pod. This is why writing addresses into rules is fragile for anything inside the cluster. A rule that allows one address today may allow a completely different pod tomorrow, which is both a breakage and a security hazard.

Labels avoid the problem, because they describe what a pod is rather than where it happens to be at the moment. Whenever you feel tempted to write an in-cluster address into a policy, stop and ask which label describes the workload. There almost always is one, and using it makes the policy last.

A Network Policy is only a description. Something else in the cluster must carry it out, and that something is the network plugin.

The Network Plugin

Kubernetes itself does not move network traffic. It delegates that job to a network plugin, commonly called a CNI plugin, where CNI stands for Container Network Interface. The plugin gives pods their addresses, connects them together, and, if it supports the feature, enforces Network Policies. The API server happily stores a Network Policy object, but storing is not enforcing.

How Enforcement Works in General

Each node runs a piece of the plugin that watches for Network Policy objects. When a policy is created or changed, the plugin translates it into low-level filtering rules on the node, using technologies built into the operating system kernel. Packets to and from local pods are checked against those rules, and forbidden packets are dropped silently. Because the checks happen on the node where the pod runs, policies work regardless of where the other end of the connection is.

flowchart TD
    U[You create a NetworkPolicy] --> API[API server stores it]
    API --> AG[Network plugin agent on each node watches for changes]
    AG --> RULES[Agent translates policy into kernel filtering rules]
    RULES --> PKT[Packets to and from pods are checked]
    PKT --> OK[Allowed packets pass]
    PKT --> DROP[Other packets are dropped]
        

Choosing a Network Plugin With Security in Mind

When selecting a network plugin, security features deserve a place next to speed and simplicity. Ask whether it enforces standard Network Policies fully, including egress and namespace selectors. Ask whether it offers flow logs, since visibility is the difference between guessing and knowing. Ask whether it supports extended policies with explicit deny and cluster-wide baselines, and whether it can encrypt traffic between nodes.

Managed cloud clusters often offer several plugin choices, and some require you to switch on policy enforcement as a separate option. Read your provider’s documentation carefully, because a default setup sometimes runs without enforcement. Making the choice deliberately, early, saves a painful migration later.

Every Network Policy has the same four parts, and once you know them you can read any policy.

The Four Parts

Reading a Policy as a Sentence

The easiest way to read a policy is as a plain sentence. For the pods labelled as the database in the shop namespace, allow incoming connections only from pods labelled as the API, only on the database port. That sentence names the protected pods, the direction, the allowed peers, and the port. If you can write the sentence, you can write the policy.

Keeping Policy Files Readable

Policies are written as structured text, and their layout affects readability. Keep one purpose per file, or group closely related policies with clear separators. Use comments to explain unusual choices. Keep the same order of sections in every policy, such as selector first, then types, then ingress, then egress, so that reviewers know where to look.

Consistency reduces mistakes. A reviewer who has seen forty policies in the same shape spots the forty-first that differs, and that difference is often where the bug hides.

A pod is either open or isolated in each direction, and a policy that selects it is what flips the switch.

Non-Isolated Pods

A pod that no policy selects is non-isolated. It accepts traffic from anywhere and can send traffic anywhere, exactly as if Network Policies did not exist. This is the starting state of every pod in a new cluster, and it remains the state of any pod that your policies do not mention.

Isolated Pods

As soon as at least one policy selects a pod for a direction, that pod becomes isolated in that direction. For ingress isolation, the pod accepts only the incoming connections that some policy allows. For egress isolation, the pod may send only the outgoing connections that some policy allows. The directions are independent: a policy that covers only ingress leaves egress fully open.

Policies Do Not Cross Namespaces for Selection

A policy protects only pods in its own namespace. To protect pods in three namespaces, you need policies in each of the three. This keeps things predictable: reading the policies in a namespace tells you everything about how its pods are protected.

Thinking About Which Pods to Isolate First

Not all pods carry the same risk, so rolling out isolation in a sensible order pays off. Start with pods that hold valuable data, such as databases and secret stores, since protecting them limits the worst outcomes. Then protect pods that face the internet, since they are the most likely first point of attack. Then protect the middle tiers that connect them. Finally, cover the remaining workloads and shared services.

This order gives the largest reduction in risk for the earliest effort. It also gives your team practice on important but well-understood workloads before you tackle the messy, poorly documented ones.

Ingress rules list the sources that are allowed to open connections to the protected pods.

Sources and Ports

An ingress rule has two optional lists. The first, called from, names the allowed sources. The second, called ports, names the allowed destination ports on the protected pod. A connection is allowed by the rule only if it matches both lists. If the from list is left out, any source is allowed for those ports. If the ports list is left out, any port is allowed from those sources.

A policy may contain several ingress rules. A connection is allowed if it matches any one of them. This makes it easy to combine separate needs, such as allowing the API pods on the database port and allowing the monitoring pods on the metrics port, in a single policy.

Health Checks and Platform Traffic

Not all traffic to a pod comes from other applications. The node agent on the pod’s own computer sends health checks to see whether a pod is alive and ready. Monitoring systems and service meshes also send their own traffic. Depending on the network plugin, traffic from the local node may be allowed automatically, or it may need an explicit rule. Forgetting this can make healthy pods appear broken and cause endless restarts.

When you first apply an ingress policy to a workload with health checks, watch the pods closely. If they begin restarting and their health checks fail, check how your plugin treats traffic from the node, and add the required allowance for the node address range or for the health check port if needed.

Egress rules list the destinations that protected pods are allowed to reach.

Why Egress Matters

Many teams protect the entrances and forget the exits. Yet exits are where stolen data leaves and where a captured pod calls home to its controller. Controlling egress can stop a compromised pod from downloading harmful tools, contacting a command server, or copying customer records to an outside address. Because attackers depend on outbound connections, egress policies are among the most powerful defences.

Destinations and Ports

An egress rule has a to list and a ports list, mirroring the ingress structure. The to list names the allowed destinations, and the ports list names the allowed destination ports. A connection is allowed if it matches any egress rule of any policy selecting the pod.

Egress and Third-Party Services

Modern applications depend on many outside services: payment providers, email senders, analytics tools, and cloud storage. Each is a possible egress destination, and each needs a decision. For important ones with stable addresses, list them explicitly. For those with changing addresses, consider routing through an egress gateway that can apply name-based rules and records every call.

Keeping a written inventory of external dependencies helps enormously. When a new dependency is added, the inventory prompts a review of the egress rules. When a dependency is retired, the inventory prompts removal of the rule, preventing old openings from lingering for years.

A rule identifies the other end of a connection in one of three ways.

Pod Selectors

A pod selector is the everyday tool. It says that pods carrying certain labels are the allowed peers. When used alone in a rule, it refers only to pods in the same namespace as the policy. This is why policies naturally stay local by default.

Namespace Selectors

A namespace selector chooses namespaces by their labels, not by their names. This surprises beginners. Namespaces must carry labels for the selector to find them. Modern clusters automatically label each namespace with its own name, which makes selecting by name possible, but you may also add your own labels such as environment equals production.

IP Blocks

An IP block names a range of addresses and may carve out exceptions. It suits traffic to and from things outside the cluster, such as a partner service or an office network. It is not the right tool for pods inside the cluster, because pod addresses change constantly. Also be aware that some network setups change the apparent source address of traffic, which can make IP blocks behave unexpectedly for external sources.

Labels on Namespaces in Practice

Because namespace selectors depend on namespace labels, your organization needs a plan for labelling namespaces. Some clusters add a label with the namespace’s own name automatically, which is convenient. Beyond that, useful labels include the owning team, the environment, and the sensitivity level. With such labels, a single policy can admit all namespaces of one team, or refuse all namespaces marked as untrusted.

Protect the ability to change namespace labels. Since policies trust these labels, anyone who can add a label to their own namespace could gain access that the label grants. Treat label changes on namespaces as security-relevant, and restrict them with access control.

A tiny difference in how selectors are written changes a policy from safe to wide open.

Two Shapes That Look Almost Alike

Within one rule, you can list several peers. If a namespace selector and a pod selector appear together as two parts of the same peer, they combine with and: only pods that match the pod selector inside the namespaces that match the namespace selector qualify. If they appear as two separate peers in the list, they combine with or: any pod matching the pod selector in the policy’s own namespace, plus every pod in the matching namespaces, qualifies.

The difference in the written form is only a small indentation, one extra dash, yet the effect is very large. The and form is narrow and precise. The or form is broad and often not what the author intended, since it admits every pod in the chosen namespaces.

flowchart TD
    subgraph AND[AND form: one peer with both selectors]
        A1[Pod must have label] --- A2[and live in a matching namespace]
        A2 --> A3[Narrow: only monitoring pods in the monitoring namespace]
    end
    subgraph OR[OR form: two separate peers]
        B1[Any pod with the label in the policy namespace] --- B2[or any pod in a matching namespace]
        B2 --> B3[Wide: every pod in the monitoring namespace is allowed]
    end
        

A Habit for Reading Peer Lists

A reliable habit for reading any peer list is to count the dashes, mentally, at the start of each peer entry. Each dash begins a new peer. Selectors that share one dash belong together and must both match. Selectors under different dashes stand alone, and either one is enough. Reading this way, slowly and aloud, catches the misplaced dash that changes the meaning.

When you find a rule that is hard to read, rewrite it as two clearer rules rather than keeping a clever one. Clarity is more valuable than compactness in security configuration, and a rule that a colleague can understand is a rule that a colleague can review.

Ports narrow a rule from allowing anything to allowing exactly one kind of conversation.

Port Numbers and Names

A port entry gives a protocol, most often TCP, and a port number. It may also give a named port, which refers to a port name defined on the pod, so that the policy keeps working if the number changes. Ranges of ports are also supported in newer versions, which helps for applications that use a block of consecutive ports.

Protocols Supported

Network Policies handle TCP, UDP, and in supporting plugins, SCTP. If no protocol is written, TCP is assumed, which surprises people who expect name lookups over UDP to work under a default rule. Traffic types that are not connection-based in the usual way, such as some kinds of ping messages, are handled differently by different plugins, and the standard does not define their behaviour.

Choosing Ports Carefully for Shared Pods

Some pods serve more than one purpose, listening on one port for customers and on another for metrics or administration. Network Policies let you treat these differently, exposing the customer port to the ingress controller and the metrics port to the monitoring system, while leaving the administration port closed to everyone. This separation is one of the cheapest ways to reduce the attack surface of an application.

If an application exposes an administration port that nobody uses, closing it with policy is a sensible precaution. Closing it in the application itself is even better, but policy gives you a safety net when the application cannot be changed quickly.

Network Policies never conflict, because they can only allow, and allowances simply add together.

The Union of Everything

If several policies select the same pod, the pod may do everything that any of them allows. Policies are combined as a union. There is no order of evaluation, no priority, and no way for one policy to cancel another. This eliminates a whole category of confusing problems that plague firewalls with ordered rules and explicit denies.

flowchart LR
    P1[Policy A allows API to database] --> U[Union of all allowances]
    P2[Policy B allows monitoring to database metrics port] --> U
    P3[Policy C allows backup job to database] --> U
    U --> R{Connection matches any allowance?}
    R -- Yes --> OK[Allowed]
    R -- No --> NO[Dropped]
        

What This Means in Practice

Because policies add up, you can write small, separate policies for separate needs and rely on their sum. One policy for the API, one for monitoring, one for backups. It also means that you can never make a pod safer by adding another policy on top of a generous one. To tighten access, you must remove or narrow the generous policy.

Connections Are Two-Way, Rules Are Not

When a connection is allowed, the replies flowing back along the same connection are also allowed automatically. You do not need to write a rule for the return traffic. However, both ends can enforce policy: the sender’s egress rules and the receiver’s ingress rules must both allow the connection if both pods are isolated. A connection needs permission at both ends to succeed.

Thinking in Terms of Paths, Not Pods

A helpful way to design policies is to think in paths rather than in individual pods. A path is a single allowed conversation: this tier may call that tier on this port. Writing down the paths of an application yields a short list, usually ten or twenty items, that captures the whole design. Each path becomes one or two policies, one for the sender and one for the receiver.

Thinking in paths also makes reviews meaningful. A reviewer can look at the list and ask whether each path is truly necessary, whether any direct path could be removed by going through an intermediate tier, and whether any path crosses a sensitive boundary. These are questions of design, not just of syntax.

The safest starting point is a namespace where everything is closed, and only needed paths are opened.

What Default Deny Means

A default deny policy selects every pod in a namespace, using an empty pod selector, and lists no allowed sources or destinations. Because selected pods are isolated and nothing is allowed, every connection to and from those pods is refused. From that closed state, you add small policies that open only the paths the applications need.

Rolling It Out Safely

Keeping Default Deny Healthy Over Time

Default deny is not a one-time act. As applications change, new connections are needed, and old ones disappear. Teams that fail to keep policies up to date face two problems: outages when a new dependency is blocked, and stale openings that nobody removes. A regular review, ideally connected to the release process, keeps the policies aligned with reality.

A helpful rule is that any change to an application’s connections must include a matching change to its policies, in the same change request. Reviewers then see both sides together, and the policies never lag behind the code.

Almost every application needs to translate names into addresses, and a strict egress policy must leave that door open.

Why DNS Matters

Applications rarely use numeric addresses. They use names such as the payments service, and the cluster’s name lookup service, called DNS, turns them into addresses. This service runs as pods in the system namespace. When you restrict egress, a pod can no longer reach those DNS pods, and every name lookup fails. Applications then report that they cannot find their databases, even though the databases are running perfectly.

The Standard Fix

The fix is a small egress policy that allows pods to connect to the DNS pods, using both UDP and TCP on port 53. Many teams apply it to every namespace as part of the default setup, together with default deny. Selecting the DNS pods by namespace label and pod label keeps the rule narrow.

sequenceDiagram
    participant W as Web pod
    participant D as DNS pods
    participant A as API pod
    W->>D: Where is the API service? (port 53)
    D-->>W: Here is its address
    W->>A: Connect to the API (allowed by policy)
    A-->>W: Reply
        

Local DNS Caches and Special Cases

Some clusters run a local name cache on every node to speed up lookups. Pods then talk to the cache rather than the central DNS pods, and the cache uses its own addresses. If your policy allows only the central DNS pods, lookups may still fail. Learn how name resolution works in your cluster before writing the rule, and test lookups from a restricted pod.

Also remember that some applications use their own resolvers or connect to external name servers. These need to be considered in the egress design, either allowed explicitly or, better, replaced by the cluster’s own lookup service.

A common goal is to make each namespace a private neighbourhood, open inside and closed to visitors.

The Same-Namespace Pattern

To let pods in a namespace talk to each other but not to other namespaces, write an ingress policy that selects all pods and allows connections only from all pods in the same namespace. Combined with default deny for anything else, this turns each namespace into a sealed area. Applications inside work as before, and outsiders are refused.

Opening Controlled Doors

Namespaces usually need a few controlled openings. The monitoring system in its own namespace must scrape metrics. The ingress controller in another namespace must forward user traffic. A shared logging service must receive logs. Each of these gets its own narrow policy naming the specific namespace, pod labels, and ports.

Shared Services Across Namespaces

Real clusters contain shared services, such as logging, tracing, certificate management, and message brokers, used by many namespaces. Each such service needs both an ingress policy on its own side, allowing the calling namespaces, and egress policies on the caller side. Using a label on the calling namespaces, such as a label that marks them as consumers, lets a single policy on the shared service admit them all without listing each one.

This pattern scales well. When a new team joins, giving its namespace the consumer label is enough to grant access, and removing the label revokes it at once. The policies themselves do not need to change.

Walking through a typical shop application shows how the pieces fit together.

The Setting

An online shop has three tiers. A web tier serves pages to customers. An API tier holds the business logic. A database tier stores orders. Customers should reach only the web tier. The web tier should reach only the API tier. The API tier should reach only the database. Nothing else should be connected.

flowchart LR
    C[Customers] -->|443| I[Ingress controller]
    I -->|8080| W[Web pods]
    W -->|9090| A[API pods]
    A -->|5432| D[Database pods]
    M[Monitoring] -.metrics only.-> W
    M -.metrics only.-> A
        

The Policies You Would Write

Adjusting the Example for Your Own Application

The three-tier example is only a starting point. Real applications add caches, queues, search engines, and background workers, each with its own paths. The method stays the same: list the components, draw the arrows that must exist, and turn each arrow into policies on both ends. Add default deny and DNS to every namespace, and the design is complete.

When in doubt, run the application in a test namespace with default deny on, and watch what fails. Each failure points to a missing path. Add the path deliberately, after asking whether it is really needed, and continue until the application works and no unexpected path remains.

Extending the Example to Background Workers

Most real applications include background workers that process queues, send emails, or generate reports. These workers usually need paths to the database and to the queue, but no path from the public internet. In policy terms, they receive no ingress at all and have carefully limited egress. Giving workers their own labels and their own small policies keeps them from inheriting the openings meant for web pods.

Workers are also a common target for supply-chain problems, since they often run large amounts of third-party code. Tight egress rules on workers are therefore especially valuable, because they stop harmful code from contacting outside servers even if the package is compromised.

Customers, load balancers, and ingress controllers reach your pods through paths that need careful thought.

How Outside Traffic Arrives

Users on the internet rarely connect straight to your pods. They reach a load balancer, which forwards to an ingress controller or a service, which in turn forwards to pods. By the time a connection reaches your web pod, its apparent source may be the ingress controller, a node address, or the original client address, depending on how the cluster and the cloud are set up. The source that the policy sees determines what your rule must allow.

Three Common Arrangements

Health of the Edge Path

The path from the internet to a pod passes through several components, and any of them can fail or be misconfigured. When customers report that a site is unreachable after a policy change, it is tempting to blame the policy at once. A calmer approach checks each hop in turn: the load balancer, the ingress controller, the service, and finally the pod. Policy is only one of those hops, but it is the newest change, so it deserves suspicion first.

Keeping a simple diagram of the edge path and its policies on hand makes such investigations much quicker. Each hop in the diagram has an owner, a rule, and a test, so the team can rule out hops one by one.

Egress to the internet and to external services is where data theft and callbacks happen, so it deserves its own design.

Allow Lists of Addresses

Standard Network Policies can name external destinations only by address ranges, using IP blocks. This works well for a small number of stable destinations, such as a payment provider whose addresses are published, or a corporate network. It works poorly for services whose addresses change often, such as content delivery networks and many software-as-a-service products, because you would need to keep the ranges up to date.

Blocking the Dangerous Places

Even where you cannot list every allowed destination, you can block dangerous ones. A common example is the metadata service that cloud providers expose to virtual machines at a special internal address. If a pod can reach it, an attacker may steal credentials belonging to the underlying machine. An egress rule that allows general outbound traffic but excludes that address closes this well-known hole.

Egress Gateways in Everyday Terms

An egress gateway is a small set of pods through which all outside traffic must flow. Policies then allow application pods to talk only to the gateway, and the gateway alone may talk to the internet. This concentrates control into one place: the gateway can enforce name-based rules, log every outside call, and present a single stable address to external partners who want to allow your traffic on their side.

The trade-off is added complexity and a new component that must be highly available. For small clusters, address-based rules may be enough. For regulated or high-risk environments, the gateway is often worth the effort.

A policy you have not tested is only a hope, so verification is part of the job.

Test Both Directions of Result

Testing has two halves. First confirm that the connections you intend to allow really work. Second, and more important for security, confirm that the connections you intend to block really fail. Many teams test only the first half, see that the application works, and assume all is well, while unwanted paths remain wide open.

Simple Test Methods

The simplest method is to start a temporary pod with a small networking tool, place it in the namespace and with the labels of the pod you want to test as, and attempt connections to the target. A successful connection means allowed and a timeout means blocked. Because blocked packets are dropped silently, a blocked connection typically hangs until it times out rather than being refused at once. That hanging behaviour is itself a hint that a policy is at work.

Policy Testing Tools and Simulation

Several tools help you check policies before they reach production. Some read policy files and answer questions such as which pods can reach this pod, drawing a map of allowed paths. Others simulate connections and report which policy allowed or blocked them. Using such tools in a pipeline catches mistakes when they are cheap to fix.

Even a simple review checklist helps: does every namespace have a default deny, does every workload with egress restrictions have DNS allowed, do any policies allow all sources, and do any peer lists combine selectors in the wide form. Answering these four questions catches a large share of real-world errors.

When something stops working after a policy change, a calm, ordered search finds the cause quickly.

flowchart TD
    S[Connection fails or hangs] --> N{Is it a name lookup problem?}
    N -- Yes --> DNS[Allow egress to DNS pods on port 53]
    N -- No --> I{Does a policy select the destination pod for ingress?}
    I -- Yes --> IA{Does an ingress rule allow this source and port?}
    IA -- No --> FIXI[Add or correct the ingress rule]
    IA -- Yes --> E
    I -- No --> E{Does a policy select the source pod for egress?}
    E -- Yes --> EA{Does an egress rule allow this destination and port?}
    EA -- No --> FIXE[Add or correct the egress rule]
    EA -- Yes --> L[Check labels, namespace labels, and service ports]
    E -- No --> L
        

The Usual Suspects

Recording What You Learn

Every troubleshooting session teaches something about your cluster. Recording the cause and the fix in a shared page turns individual experience into team knowledge. Over time, the page becomes a guide to your own environment: which applications need which special paths, which plugin quirks matter, and which mistakes recur. New team members learn faster, and repeated outages become rarer.

Include the symptom in the record, in the words people actually use, such as cannot resolve host or connection times out. Future searchers will type those same words, and finding the page quickly is half of the solution.

To keep policies correct over time, you need to see what traffic actually flows and what gets dropped.

Why Standard Kubernetes Shows Little

The basic Network Policy feature has no logging. Dropped packets vanish without a trace, and Kubernetes offers no built-in report of denied connections. Beginners find this frustrating, because a blocked connection produces a timeout with no explanation. Visibility must come from the network plugin or from separate tools.

Sources of Visibility

Using Visibility to Design Policies

Traffic maps are especially valuable when you are protecting an existing application whose connections nobody fully remembers. Observe real traffic for a period, draw the map, and turn each observed legitimate flow into a policy. Then review the flows that surprise you: they are often forgotten dependencies or, occasionally, signs of something suspicious.

Reading Traffic Maps With a Security Eye

A traffic map is more than a design aid. Read it as an intruder would. Which workloads have paths to sensitive ones? Which paths seem unnecessary? Which workloads talk to the outside world, and to where? A map often reveals a tool that can reach far more than its purpose requires, giving you an obvious next policy to write.

Comparing maps over time is also useful. A new path that appears without a matching change request deserves investigation. It may be an honest new feature, a forgotten test, or occasionally an intrusion. Either way, you want to know the same day.

The standard Network Policy is deliberately simple, so many network plugins offer richer versions for demanding needs.

What the Standard Cannot Do

The standard object has several limits. It has no way to deny explicitly. It cannot set priorities between rules. It cannot apply a single rule across all namespaces at once, because every policy lives in one namespace. It cannot allow or deny by domain name, and it offers no logging. It works only at the connection level and cannot examine the contents of requests.

What Extensions Add

Deciding Whether You Need Extensions

Before adopting extended policies, list the needs that standard policies cannot meet. If your list is short and consists of items like logging, then a plugin with flow logs may be enough while you stay with standard policies for rules. If your list includes explicit deny, cluster-wide baselines, and name-based egress, extended policies are likely worth it.

Whichever way you decide, keep the design understandable. Extra features tempt teams to build elaborate layers of rules with priorities and exceptions. Complexity is the enemy of security, because nobody can verify what they cannot understand. Prefer the simplest design that meets the requirements.

Network Policies deliver large security gains, but they ask for care and discipline in return.

Weighing the Balance

The trade-offs are real but manageable. The risk of outages is handled by careful rollout, testing, and small policies. The lack of visibility is handled by plugin features and traffic maps. The limit to addresses and ports is handled by pairing policies with identity-based tools. The benefit, a cluster where a single mistake cannot become a disaster, is worth the effort for nearly every production environment.

When Network Policies Are Most Valuable

Network Policies pay off most in clusters that share workloads between teams, handle sensitive data, or face the public internet. In such environments, the cost of one lateral movement can be enormous, and the effort of writing policies is small by comparison. In a tiny personal cluster running a hobby project, the benefit is smaller, though the habits learned there transfer directly to serious environments.

A useful test is to imagine that any single pod in your cluster has just been taken over by a stranger. Ask what that stranger could reach in the next ten minutes. If the honest answer is everything, policies are overdue. If the answer is a short, acceptable list, your segmentation is working.

A short list of habits separates clusters that are truly segmented from clusters that only appear to be.

Habits Worth Building

Naming and Documenting Policies

Clear names make policies self-explanatory. A name such as allow-api-to-database says at once what the policy does, while a name such as policy-7 says nothing. Adding a short description in an annotation, stating who requested the path and why, saves hours during reviews. When someone asks why a path exists, the answer is right there.

Consistent names also help searching and automation. Scripts can find all default deny policies, all DNS policies, and all policies that touch the database, simply by looking at the names and labels. This turns a pile of objects into an organized collection.

Network Policies appear in every serious cluster, in patterns that are easy to recognize.

Situations Where Policies Prove Their Worth

A Gentle Adoption Roadmap

Keeping the Momentum After the Rollout

Once the first namespaces are protected, the hardest part is often keeping the effort alive. New services appear, teams change, and shortcuts creep in. Build the protections into the normal path of work: templates that give every new namespace a default deny and a DNS policy, checks in the pipeline that reject policies allowing all sources, and a short review step for any change to network rules.

Celebrate small wins as well. Each time a policy blocks something unexpected and the alert draws attention to it, share the story with the team. Stories of real incidents that were contained do more to sustain good habits than any rule document, because they show that the effort truly matters.

Short answers to the questions beginners ask most often about Network Policies.

No. By default, every pod can reach every other pod across all namespaces. Isolation begins only when a Network Policy selects a pod.

The most likely reason is that your network plugin does not enforce Network Policies. Kubernetes stores the object without complaint. Check the plugin’s documentation and run a deny test.

Not with the standard object. It only allows. You achieve a denial by isolating pods and not allowing the traffic. Some plugins provide extended policies with explicit deny.

Their allowances are combined. The pod may do anything that at least one policy allows. There is no ordering and no conflict.

Most often because name lookups were blocked. Allow egress to the DNS pods on port 53, using both UDP and TCP.

No. Replies to an allowed connection are permitted automatically. You only need to allow the connection in the direction it is opened.

No. A policy selects pods only in its own namespace. It can, however, allow peers from other namespaces by using a namespace selector.

If the namespace selector and pod selector are in the same peer, both must match. If they are separate peers, either may match, which is much broader.

No. Pod addresses change constantly. Use pod and namespace selectors for in-cluster traffic, and reserve IP blocks for stable external ranges.

No. They control which connections may be opened, not whether the data is encrypted. Use encryption in the application or a service mesh for that purpose.

The standard feature has no logging. Use flow logs or observation features from your network plugin, or a separate traffic monitoring tool.

It is an excellent foundation, but you must add narrow policies to open the paths your applications need, including name lookups. Pair it with testing, monitoring, and other security layers.

Where to Learn More Safely

The best way to learn Network Policies is to practise in a scratch cluster. Create a namespace with a few simple pods, try connections, apply default deny, and watch them fail. Open one path at a time and watch it succeed. Deliberately make the classic mistakes, such as blocking DNS and misplacing a dash, so that you recognize them when they appear in real work.

Alongside practice, read the documentation of your own network plugin, because its behaviour details matter. Small differences in how node traffic, external sources, and unusual protocols are treated can change results, and only your own tests can settle them.

Kubernetes starts with a flat, open network in which every pod can reach every other pod. Network Policies fix this by describing, with labels, exactly which connections are allowed. Pods selected by a policy become isolated in the chosen directions, and only the allowed paths remain. Because policies only add allowances, they never conflict, and a good design starts from default deny and opens narrow, well-tested paths.

Success depends on a network plugin that enforces the rules, on careful handling of name lookups and of both ends of every connection, and on testing that blocked paths really fail. With those habits, Network Policies keep a single compromised pod from becoming a compromised cluster.