Kubernetes network policies

When Kubernetes network policies become necessary in a self-managed cluster

Kubernetes network policies restrict traffic between pods and from pods to external destinations, but only when the cluster's network plugin enforces them. The NetworkPolicy object is defined by the Kubernetes API, so the cluster will accept and store a policy whether or not anything acts on it. In a self-managed cluster, that gap is the first thing to check. Teams often install a cluster with a plugin that does not enforce NetworkPolicy, create policies that look correct, and assume segmentation exists. Before a security or compliance owner asks for segmentation, confirm which plugin is installed, whether it enforces both ingress and egress rules, and how that enforcement was verified in your environment.

Teams usually need policies once the default allow-all behavior stops matching how the cluster is used. Three situations come up most often. The first is multi-tenant namespaces, where teams or customers share a cluster and one tenant's workloads should not reach another tenant's services or databases. The second is regulated data workloads, such as services that handle payment, health or personal records, where the network path should be limited to the components that genuinely need it. The third is lateral movement. If one container is compromised, unrestricted pod-to-pod reach lets an attacker scan and connect to neighboring services. Network policies do not replace authentication or Pod Security Standards, but they limit how far a compromise can travel.

Deciding whether you need policies is less work than deciding how far to take them. Start by listing which namespaces hold regulated data, which services must reach external endpoints such as a payment processor or a managed database, and which components only need in-cluster access. Those answers shape the default deny posture and the egress allow list. Also decide who owns policy authoring. Platform teams often own a baseline set of rules, while application teams own the rules for their own services. Ask your security owner to name the traffic flows that must be documented for an assessment, because an auditor will ask for evidence of the rules themselves.

Introducing policies to a running cluster carries its own risk. A default deny rule applied before traffic flows are mapped can cut off DNS lookups, metrics scraping, health checks or a service mesh control path, and the resulting outage may look like an application fault. Plan a period to observe traffic first, apply policies to one namespace at a time, and keep a documented rollback procedure. Check your plugin's documentation for support of the rule features you need, including egress to DNS and to external IP ranges, because behavior differs between implementations. Settle the plugin choice and the policy design together before the first production namespace is changed.

Which enforcement plugin and policy pattern fits your cluster

This table compares the decisions that shape a NetworkPolicy design: the network plugin, how default deny is scoped, how selectors match traffic and whether egress is controlled. Read each row for what it gives you, what it costs your team to run and the conditions where it fits. Confirm plugin enforcement and feature support against the plugin documentation and your Kubernetes version before you commit to a design, because a policy object that the plugin does not enforce gives no protection.

Decision	What it gives you	What it costs to operate	When it fits
Network plugin that enforces NetworkPolicy	Policy objects are translated into real traffic rules at the node or pod network layer	Plugin upgrades must be scheduled with Kubernetes upgrades; advanced features may vary by plugin version	Any cluster where segmentation is a control you must show. Confirm enforcement and features for your Kubernetes version first
Default deny per namespace	A single baseline policy isolates every pod in a namespace, so new workloads start closed	Every legitimate flow must be written as an explicit allow rule, which adds review work to each release	Multi-tenant namespaces or environments where teams share a cluster and unknown traffic must be blocked by default
Default deny per workload	Each pod selector gets its own isolation rules, giving the tightest scope	Largest policy count; rules drift when labels change and need more testing	Small, high-value workloads such as payment or identity services inside a namespace that otherwise runs less sensitive code
Namespace selectors	Allows traffic by namespace label, so whole environments or tenants can be grouped	Namespace labels become a control surface; anyone who can label a namespace can change allowed traffic	Coarse boundaries between teams, environments or security zones, with label changes restricted by RBAC
Pod selectors	Matches individual workloads by label, giving precise service-to-service rules	Labels must be consistent across manifests and Helm charts or rules silently miss pods	Application tiers such as web to API to database, where each service has stable and reviewed labels
Ingress-only control	Restricts who can reach a pod, with no change to outbound traffic from that pod	Lower rule count and simpler testing, but lateral movement and data exfiltration paths stay open	Early segmentation programs, or workloads where outbound paths are already controlled by other means such as a proxy
Ingress plus egress control	Limits both inbound and outbound flows, including DNS, external APIs and cloud metadata access	Every external dependency needs a documented rule, and DNS and cluster services must be allowed explicitly	Regulated workloads that must limit where data can leave the cluster, and clusters where compromised pods could reach internal networks

How Kubernetes network policies select pods and combine allow rules

A NetworkPolicy decides which pods it governs before it decides what traffic to allow. Its podSelector field is a label query evaluated in the policy's own namespace, so a policy with an empty podSelector governs every pod in that namespace. Each policy also lists policyTypes, Ingress, Egress or both, which chooses the directions it affects. Selection applies per direction: a pod selected for ingress by one policy is isolated for inbound traffic, but it stays open for outbound traffic unless some policy also selects it for Egress. Before you write any rules, run kubectl get pods with the show-labels option to see which pods each selector matches, and confirm that the selection is what you intend in a non-production namespace.

Rules name the other side of a connection through peers. A podSelector peer matches pods in the policy's namespace. A namespaceSelector peer matches pods in namespaces with matching labels, and when both fields appear in the same peer entry, they combine with AND, so only matching pods in matching namespaces qualify. Listing them as separate entries combines them with OR, which is a common source of access broader than intended. An ipBlock peer matches a CIDR range with optional exceptions, and it occupies its own peer entry, so it cannot share an entry with selectors. Omitting the from or to field in a rule matches all sources or all destinations, so a rule with no peers allows everything through its ports. Review each peer entry with this behavior in mind before you approve a policy.

Allow rules combine additively. When several policies select the same pod for a direction, the pod accepts the union of what all of them allow, and traffic is dropped only when no rule in any selecting policy matches it. Pods that no policy selects for a direction remain open in that direction, so a policy can leave a workload unprotected if its labels miss the target. A policy that lists a direction in policyTypes with no rules for it selects those pods and allows nothing in that direction, which is the usual building block for a default deny. Because policies only add allowances, a broad allow in one policy cannot be carved back by an exception in another policy. Narrow the broad policy itself, and keep a record of which policies select each workload.

Plan the rollout before you apply anything. Map each workload to the labels that identify it, and record which namespaces must reach which services and on which ports. In a test cluster, apply a default deny for one namespace first, then add allows for the flows you have confirmed, and check that DNS lookups and health checks still succeed. Confirm with your CNI plugin's documentation how it handles connections that were already established, how it treats pods on the host network, whether it logs dropped traffic, and whether it supports every selector and field you plan to use. Enforcement depends on the plugin you choose, so this confirmation belongs in the plugin decision, not after it.

How to roll out default deny without breaking cluster traffic

This sequence moves a cluster from open pod-to-pod traffic to default deny one namespace at a time, with a check after each change so that DNS, ingress, monitoring and control plane traffic keep working throughout the rollout.

Inventory traffic flows and namespaces
The platform team lists every namespace, the workloads in each, and the traffic they send and receive, including ingress paths, service-to-service calls, database connections, DNS lookups, metrics scrapes and any calls from the API server to workloads such as admission webhooks. Flow logs from your network plugin or a traffic observability tool, if your plugin provides them, show what actually runs rather than what the architecture diagram says. The output is a written flow inventory with an owner for each namespace and a list of traffic that crosses namespace boundaries. You know this step is done when each application owner has reviewed their namespace entries and signed off on them.
Confirm the plugin enforces policies in a lab
Before relying on NetworkPolicy, the platform team builds a lab cluster with the same network plugin and version as production. They apply a deny-all policy to a test namespace and confirm that a test pod can no longer reach a pod in another namespace, then remove the policy and confirm traffic returns. Some plugins accept NetworkPolicy objects without enforcing them in every mode, so this test is the only reliable proof for your plugin. Ask your plugin vendor or documentation which features it supports, such as egress rules, IP blocks, host endpoints or logging, and record any gaps. The step is done when enforcement is confirmed in both directions and the results are saved with the cluster build record.
Apply default deny to one non-production namespace
In a non-production namespace with a low-risk workload, the platform team applies a default deny policy for ingress and, separately, for egress if the plugin and the team's scope support it. Applying the ingress and egress policies as separate objects makes rollback simpler. The change is made through version-controlled manifests so the reviewer can see exactly what was applied. Immediately afterward, the team runs the connectivity checks from the flow inventory against that namespace and watches for dropped connections in flow logs. The step is done when the expected traffic that should be blocked is blocked and no unexpected dropped connection appears during an agreed observation window.
Allow DNS lookups from the namespace
Once default deny blocks everything, pods can no longer resolve service names, which is the most common cause of broken workloads after rollout. The team adds an egress allow rule that permits UDP and TCP port 53 to the cluster DNS pods in the kube-system namespace, selected by label. They then test name resolution from a pod in the namespace, both for in-cluster service names and for external names if pods need them. The step is done when a lookup from a representative pod succeeds for each name type the application uses, and a lookup to an address outside the allowed list still fails.
Allow ingress controller, monitoring and API server traffic
The team adds targeted allow rules for the ingress controller namespace, the monitoring namespace that scrapes metrics endpoints, and the API server callbacks used by admission webhooks or aggregated APIs. Each rule uses namespace and pod selectors that match the labels seen in the flow inventory, and the port list is limited to what the flow logs showed. For the API server, confirm the source addresses your distribution uses, since they differ across distributions and cloud providers, and ask your plugin documentation how it treats host-network traffic. The step is done when the application responds through its public route, Prometheus shows the target as up, and any webhook call from the API server succeeds in a test.
Validate application behavior and record evidence
Before moving on, the application owner runs their normal functional tests, including login, background jobs and any cross-namespace calls listed in the inventory. The platform team reviews flow logs for dropped connections for a full business cycle or the period agreed with the owner, and records each allow rule with the flow it supports. Rules that match no observed flow are removed to keep the policy set minimal. The output is a short record per namespace: the policies applied, the tests run, the dropped flows reviewed and the sign-off. The step is done when the owner confirms the application works and the record is stored with the change ticket.
Expand namespace by namespace
The team repeats the same sequence for the next namespace, starting with lower-risk workloads and leaving shared services, identity components and data stores until the pattern is proven. Each namespace goes through the inventory check, the default deny change, DNS and platform allow rules, and the validation step before the next one begins. Teams should expect rules that exist only for one application, so reusable allow rules belong in a shared platform template while application specific rules stay with the owning team. The rollout is complete when every namespace in scope has a documented policy set, the flow logs show no unexplained drops, and the team has a tested rollback path for each namespace.

Security and operational risks of Kubernetes network policies

A network policy set that looks correct in review can still block cluster dependencies, enforce nothing, or drift away from its intent over time. The cards below cover the failure modes that appear after rollout and the controls and owners that keep segmentation working.

Missing egress rules block DNS and registries

A default deny egress policy also cuts off DNS lookups and image pulls unless those destinations are allowed explicitly. Pods then fail with name resolution or image pull errors that look unrelated to segmentation. Before rollout, test DNS to the cluster resolver and pulls from the internal registry from a pod in each namespace, and keep those allowances in the shared baseline policy. Platform engineering owns the baseline; application teams own their namespace-specific egress.

Policies ignored by the network plugin

NetworkPolicy objects are only enforced when the cluster's network plugin implements them. A cluster can accept and store policies that do nothing, which gives a false sense of isolation. Confirm enforcement with the plugin vendor for your version, then run a connection test that is expected to fail after a deny policy is applied. Platform engineering owns the plugin choice and the enforcement test, which should run again after every cluster upgrade.

Label changes that alter pod selection

Policies select pods and namespaces by label, so a renamed or removed label can silently add pods to a policy or drop them from it. A change to a deployment template can widen access without any policy file changing. Store selector-based rules with the workload manifests they depend on, and audit which pods each policy selects after label changes. Application teams propose label changes; the platform team reviews any change that touches a selector.

Host network pods bypass pod rules

Pods that run with host networking share the node's network namespace, and pod-level NetworkPolicy rules do not apply to their traffic in the way teams expect. A workload that quietly sets host networking can reach services that the policy set is meant to isolate. Review pods that request host networking as part of workload admission, and restrict that setting through the Pod Security Standards for namespaces that do not need it. The platform team owns the namespace enforcement level.

Policy drift across many teams

When several teams write policies directly in the cluster, rules overlap, conflict and fall out of date as applications change. No single reviewer sees the full allow list, so gaps appear in namespaces nobody reviews. Store all policies in Git, deploy them through a GitOps controller, and use admission rules that require a policy in every namespace before workloads run. Each namespace owner is accountable for their rules, and the platform team owns the admission requirement.

Secrets used by policy controllers

Some network policy tooling and the service accounts that deploy policies hold credentials that can change allow rules across the cluster. Compromise of those credentials lets an attacker remove isolation without touching a workload. Limit who can create or modify NetworkPolicy objects with RBAC, store controller credentials according to the secrets handling practices for your cluster, and alert on policy deletions. The security team reviews these roles; the platform team maintains them.

How to control egress and test policies before enforcing them

Egress control is the half of network segmentation that teams most often leave until last, and it needs a clear definition before any rule is written. The goal is to restrict outbound traffic from each namespace to an approved list: specific CIDR blocks for external services, named namespaces and services inside the cluster, and the cluster DNS service so pods can resolve names without gaining broader access. Core NetworkPolicy can express IP blocks and label-based selectors, but it matches on pod labels, namespaces and IP ranges and does not match hostnames or URLs. Traffic to a SaaS API whose addresses change, or any rule that must allow a domain name, usually needs a plugin-specific feature or an egress proxy. Confirm with your chosen network plugin which fields it supports beyond the core API and how it enforces DNS-based rules in your version.

Before enforcing anything, write each egress rule as a statement of intent: the source workload, the destination, the port and protocol, the business reason, and the person who approved it. Then map every rule to a test. Use a disposable test pod for each rule, labeled to match the source selector and run in a non-production namespace. Each rule needs positive tests, where the approved destination must succeed, and negative tests, where anything outside the rule must fail. Negative tests should include other namespaces, unapproved external addresses and attempts to use cluster DNS to reach unapproved names. Run the tests from the same node pools and network paths that production uses, because a result obtained from an unrepresentative node proves little about production behavior.

Dry runs belong in a staging cluster that runs the same network plugin version as production and carries the same namespace labels. Namespace labels are easy to overlook, but selectors that resolve differently between clusters are a common cause of policies that pass review and then block live traffic. Ask your plugin vendor or documentation whether it can log or report denied flows without enforcing them. If it can, run in that observation mode first. If it cannot, roll the policy out to a canary namespace before the wider cluster. Check that the rollout order does not cut off traffic the workload needs to run, including DNS, image pulls, metrics scraping, log shipping and calls to identity services.

What to confirm about your cluster before writing policies

Before you write NetworkPolicy objects, confirm the limits of the platform underneath them. The network plugin, the Kubernetes minor version, the DNS and image paths, and any traffic that bypasses pod policy each change what a policy can enforce. Settle these four items first so that the policies you write match the cluster you run.

Network plugin version and features

NetworkPolicy objects have no effect unless the installed network plugin enforces them, and plugins differ in what they support. Ask the vendor or check the plugin's release notes for the exact version in your cluster, then confirm support for IPv6 policies, egress rules and policy logging or flow logs. If the cluster runs dual-stack, test IPv6 separately, because a rule set that works for IPv4 can leave IPv6 traffic open. Record these answers before you write any policy.

Kubernetes minor version support

Policy behavior and API fields can change between minor releases, so the version you test against must be the version you run. As of September 2026, the three supported minor releases were 1.37, 1.36 and 1.35, with upstream end-of-life dates of October 28, 2027, June 28, 2027 and February 28, 2027. Confirm that your cluster is on a supported minor version and when your next upgrade window falls. A cluster close to end of life leaves little time to revise policy design after an upgrade.

DNS and registry reachability

Default-deny egress often breaks name resolution and image pulls before it breaks anything else. Identify the cluster DNS service, any node-local DNS cache, and the private registry or mirror that nodes use to pull images. In a managed service, confirm with the provider which control plane and node endpoints must stay reachable. In an air-gapped cluster, list every image source your control plane and add-ons pull from, including any registry set with the kubeadm image repository option, and allow those destinations explicitly before applying egress rules.

Service mesh and host network workloads

Pod policies only govern traffic that the network plugin sees as pod-to-pod traffic. Sidecar proxies, mesh gateways and pods that set hostNetwork to true can send or receive traffic that selectors do not match in the way you expect. Inventory which namespaces inject a mesh, which pods use host networking, and which node-level agents listen on host ports. Decide which of those flows are controlled by mesh authorization or host firewall rules, and document the remaining gaps so the team knows what pod policy will not enforce.

Questions buyers ask about Kubernetes network policy work

What drives the cost of Kubernetes network policy work?

Cost follows from a written scope. DeployOpen does not publish a price list, so the quote is built from the scope you agree in writing. The main cost drivers are the number of clusters and namespaces, how many application teams own traffic, whether traffic flows are already documented, and whether the network plugin must change.

Most of the cost is one-time: traffic discovery, policy design, plugin work if needed, testing and handover. Policy maintenance recurs, because every new namespace, service or external dependency needs a policy decision. Ask whether that work stays with your team or moves to a retainer. When you request a quote, ask for line items covering discovery, policy authoring, testing, documentation and knowledge transfer, and confirm who pays for any plugin or licensing change.

How long does a Kubernetes network policy project take?

Duration depends on scope, and no single timeline fits every cluster. A non-production cluster with a few namespaces and documented traffic moves much faster than a multi-cluster estate where each application team owns its own flows. The largest variables are how much traffic is unknown, whether the plugin needs changing, and how quickly your change windows and approvers respond.

Waiting for approvals often takes longer than the technical work. Ask for a schedule in the written scope that lists milestones, the client inputs each milestone needs and the change windows assumed. If a proposed timeline does not name those dependencies, ask for them before you accept it.

Can our internal platform team implement NetworkPolicy without outside help?

Yes, if the team has Kubernetes networking skills and a non-production cluster to test in. The skills needed include how your chosen plugin enforces policy, how selectors match pods and namespaces, how DNS and ingress traffic must be allowed, and how egress rules affect calls to external services.

Teams without a test environment should not start on production. Outside help is most useful when traffic is poorly understood, when many application teams must agree on rules, or when the team lacks time for testing and documentation. DeployOpen can plan, implement and document the work in your infrastructure, so you can decide which parts to keep in-house.

What do we need to provide before network policy work starts?

Four things from your side: cluster access, traffic owners, change windows and a named approver.

First, cluster access in a non-production environment, with accounts for the people who will test. Second, a named traffic owner for each application who can confirm which flows are required and why. Third, change windows agreed with operations for any rollout to production. Fourth, a named approver who can accept each policy set before it is enforced.

Without traffic owners, policies usually end up either too broad or blocking valid calls. Ask engineering to name owners before scoping starts, confirm who holds production change authority, and agree where test results and approvals will be stored as evidence.

Which factors make a Kubernetes network policy project larger?

Cluster count, namespace count, application team count, documentation and plugin changes shape the effort most. Each cluster has its own plugin state, namespaces and traffic, so more clusters mean more discovery and testing. Namespace count and the number of application teams determine how many policy sets need an owner and sign-off.

Existing traffic documentation decides how much discovery happens before design. Plugin change needs add a cluster-level change with its own testing and rollback plan. Egress control also adds effort, because allowing outbound calls to external services requires more detail than internal pod-to-pod rules. Ask for the written scope to show each factor separately, so you can see where earlier documentation would reduce the work.

Do we need to change our CNI plugin to enforce policies?

It depends on whether your current network plugin enforces NetworkPolicy. Policy objects are only enforced by a plugin that supports them, so the first check is whether your installed plugin enforces the API and which features it supports. Confirm this in the plugin's documentation and with a test policy in a non-production cluster.

A policy that the API accepts but the plugin does not enforce gives false confidence. If the plugin does not enforce policy, changing it is a cluster-level change that affects networking for every workload. It needs its own rollback plan and change window. Ask whether the scope includes plugin selection, migration and testing, and who owns that decision.

How do we test network policies before they block production traffic?

Test in a non-production cluster first, then roll policies out in stages. Start by recording the actual traffic flows for each application, using the plugin's flow logs or another suitable tool. Apply a default deny policy only after allow rules for those flows exist. Verify each flow with a repeatable test, including DNS, health checks and calls to external services.

Move to production namespace by namespace during agreed change windows. Write a rollback step before each change, and keep test results and approvals as evidence. Ask for the test plan and rollback steps to be included in the written scope.

How DeployOpen scopes, delivers and supports Kubernetes network policies

DeployOpen plans and builds Kubernetes network policies inside clusters you control, starting from a written scope. The work covers confirming a network plugin that enforces NetworkPolicy, default deny baselines, selector design, egress control and policy tests, followed by documentation and optional support under a retainer.

How we scope

The written scope lists the namespaces, workloads and traffic flows that policies will cover.
It names the network plugin, confirms its enforcement of NetworkPolicy and sets the clusters in scope.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.

How we build

Default deny baselines are applied per namespace, followed by allow rules for each documented traffic path.
Selectors use namespace and pod labels that match the labeling standard your teams already follow.
Egress rules cover DNS, package mirrors, identity providers and external APIs, each justified in the design.

How we hand over

A test suite checks allowed and denied flows against the cluster before sign-off.
Documentation records each policy, its owner, the traffic it permits and the reason it exists.
Runbooks cover adding a namespace, changing a rule and troubleshooting a blocked connection.

How we support

Retainers can cover policy reviews as new workloads, namespaces and services are added to the cluster.
Continuous testing can re-run flow checks after cluster upgrades and network plugin changes.
Confirm whether support covers plugin upgrades that change how NetworkPolicy is enforced.