Kubernetes Network Policies
Guide to Kubernetes Network Policies for microsegmentation including default-deny patterns, label selectors, CNI requirements, and zero-trust baselines.
Continue your mission
Guide to Kubernetes Network Policies for microsegmentation including default-deny patterns, label selectors, CNI requirements, and zero-trust baselines.
# Kubernetes Network Policies
Kubernetes Network Policies are namespace-scoped resources that control traffic flow between pods and between pods and external endpoints. They implement microsegmentation at the cluster level, defining which pods can communicate with which other pods and on which ports.
Network Policies exist because Kubernetes clusters, by default, operate as a flat network. Every pod can reach every other pod on any port. This default behavior makes sense for development environments where connectivity simplifies debugging and testing. It becomes a significant security liability in production environments where a compromised application container can immediately access databases, internal APIs, and other sensitive services without restriction.
Network Policies address this security gap by implementing software-defined firewalls at the pod level. Unlike traditional network firewalls that operate on IP addresses and subnets, Network Policies work with Kubernetes-native constructs: labels, selectors, and namespaces. This integration allows security controls to move with applications as pods are created, destroyed, and rescheduled across cluster nodes.
Within the broader Kubernetes security model, Network Policies complement other pod-level controls like Pod Security Standards, Resource Quotas, and RBAC. While those controls govern what pods can do on the host system and what resources they can access through the API server, Network Policies govern what pods can reach over the network. Together, these controls implement defense in depth for containerized workloads.
Network Policies operate at Layer 3 and Layer 4 of the network stack, controlling traffic based on IP addresses, ports, and protocols. Some Container Network Interface (CNI) implementations extend this to Layer 7, enabling HTTP method filtering and DNS-based rules.
Network Policies use three primary mechanisms to define traffic rules: pod selectors, namespace selectors, and IP blocks. Pod selectors identify source and destination pods based on their labels. Namespace selectors control cross-namespace traffic. IP blocks specify external endpoints using CIDR notation.
A basic Network Policy structure includes a pod selector that determines which pods the policy applies to, and ingress or egress rules that specify allowed traffic. Here is a fundamental example:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: backend-policy
namespace: production
spec:
podSelector:
matchLabels:
app: backend
policyTypes:
- Ingress
- Egress
ingress:
- from:
- podSelector:
matchLabels:
app: frontend
ports:
- protocol: TCP
port: 8080This policy selects all pods labeled app: backend in the production namespace and allows ingress traffic only from pods labeled app: frontend on TCP port 8080. All other ingress traffic to backend pods is denied.
The enforcement model follows an important principle: once any Network Policy selects a pod, that pod becomes subject to policy enforcement for the specified traffic directions. If a policy specifies ingress rules, all ingress traffic not explicitly allowed is denied. The same applies to egress rules. Pods not selected by any policy continue to allow all traffic.
This enforcement model enables a layered security approach. Organizations typically start with a default-deny policy that selects all pods:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny
spec:
podSelector: {}
policyTypes:
- Ingress
- EgressWith this baseline in place, specific allow policies grant the minimum necessary connectivity. For example, allowing DNS resolution:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-dns
spec:
podSelector: {}
policyTypes:
- Egress
egress:
- to: []
ports:
- protocol: UDP
port: 53Cross-namespace communication requires namespace selectors. This example allows backend pods to access a shared database service in the data namespace:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: backend-to-database
spec:
podSelector:
matchLabels:
app: backend
policyTypes:
- Egress
egress:
- to:
- namespaceSelector:
matchLabels:
name: data
- podSelector:
matchLabels:
app: postgres
ports:
- protocol: TCP
port: 5432External traffic uses IP blocks. This policy allows backend pods to reach an external payment API:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: backend-to-payment-api
spec:
podSelector:
matchLabels:
app: backend
policyTypes:
- Egress
egress:
- to:
- ipBlock:
cidr: 203.0.113.0/24
ports:
- protocol: TCP
port: 443Network Policy enforcement requires a compatible CNI plugin. The Kubernetes network model is implemented by CNI plugins, and not all CNI plugins support Network Policies. Calico, Cilium, and Weave Net provide full Network Policy support. Flannel does not support Network Policies in its default configuration. Cloud providers typically offer managed CNI solutions with Network Policy support: Amazon VPC CNI with network policy controller, Azure CNI with Azure Network Policy Manager, and Google Kubernetes Engine with Calico.
Advanced CNI implementations extend Network Policies beyond the standard specification. Cilium provides DNS-aware policies that allow rules based on fully qualified domain names rather than IP blocks, Layer 7 HTTP filtering based on HTTP methods and URL paths, and identity-based security that persists pod identity across IP address changes. Calico adds global network policies that apply across namespaces and host endpoint protection that extends policies to nodes themselves.
Policy testing and validation presents operational challenges. kubectl provides basic syntax validation, but it cannot verify that policies achieve the intended connectivity restrictions. Network policy visualization tools like Insightful's network-policy-viewer and Cilium's Hubble help operators understand policy effects. Testing often requires deploying test pods and attempting connections to verify that allowed paths work and denied paths fail.
The business impact of Network Policy implementation centers on containing security incidents and meeting compliance requirements. Without Network Policies, a single compromised container can access any service in the cluster. This unlimited lateral movement capability transforms minor application vulnerabilities into major data breaches.
Consider a typical three-tier web application: frontend, backend API, and database. Without Network Policies, compromising the frontend pod through a stored XSS or code injection vulnerability gives an attacker direct access to the database. The attacker can scan for other services, access Kubernetes secrets mounted in other pods, and potentially reach the cluster control plane. Network Policies limit this blast radius by ensuring that compromised frontend pods can only reach the backend API on specific ports, not the database or other cluster services.
The financial services industry illustrates the compliance dimension. PCI DSS requires network segmentation between systems that handle cardholder data and other systems. In Kubernetes environments, this segmentation must be implemented through Network Policies. A payment processing application must demonstrate that card data handling pods cannot be reached from general application pods. Network Policies provide the technical control and audit evidence required for compliance validation.
Operational consequences of missing Network Policies extend beyond security incidents. During incident response, teams must assume that any pod in the cluster could have been affected because lateral movement was unrestricted. This assumption significantly expands the scope of investigation and remediation. With proper Network Policies, incident responders can limit their analysis to pods that the compromised service could actually reach.
Organizations often underestimate the complexity of implementing Network Policies in production environments. Applications frequently have undocumented dependencies discovered only when Network Policies block previously working connections. This discovery process can cause application outages if not carefully managed. Many organizations deploy monitoring and alerting for denied connections before implementing restrictive policies.
Another common misconception treats Network Policies as a complete solution for Kubernetes security. Network Policies control pod-to-pod communication but do not address container image vulnerabilities, insecure API server configurations, or compromised nodes. They are one component of a comprehensive security strategy, not a standalone solution.
The performance impact of Network Policies is generally minimal but depends on the CNI implementation and policy complexity. Simple policies based on pod labels have negligible overhead. Complex policies with many IP block rules or frequent policy changes can impact network performance. Organizations running latency-sensitive applications should test Network Policy performance in staging environments before production deployment.
CDA integrates Network Policies into the VSD (Vulnerability and Surface Defense) domain because they directly reduce the attack surface available to compromised workloads. Network Policies align with CDA's CSR (Continuous Surface Reduction) methodology: every network path you expose is a path we eliminate.
CDA's approach to Network Policies differs from conventional security thinking in several ways. Most organizations treat Network Policies as an additional security layer to implement after addressing "more important" vulnerabilities like CVE patching. CDA treats Network Policies as foundational infrastructure that should be implemented early in the cluster lifecycle, before significant application deployment.
The conventional approach implements Network Policies reactively, often after a security incident demonstrates the need for lateral movement controls. CDA implements Network Policies proactively as part of cluster hardening. This proactive approach prevents the accumulation of undocumented network dependencies that make later Network Policy implementation more complex and risky.
CDA missions implement a three-phase Network Policy deployment strategy. Phase one establishes monitoring and visibility for existing network traffic patterns without enforcement. Phase two implements default-deny policies in permissive mode, logging denied connections without actually blocking them. Phase three enables enforcement with continuous monitoring for application impact.
This phased approach differs from vendor recommendations that often suggest implementing simple allow-all policies first and gradually tightening restrictions. CDA's experience shows that allow-all policies provide no security benefit and create false confidence. Organizations deploy them to check the "Network Policy implemented" box without achieving any actual risk reduction.
CDA emphasizes Network Policy automation and infrastructure-as-code management. Manual Network Policy creation does not scale in environments with hundreds of microservices and frequent deployments. CDA integrates Network Policy generation with CI/CD pipelines, automatically creating policies based on application manifests and service dependency declarations.
The automation extends to policy validation and testing. CDA develops Network Policy test suites that verify both positive and negative cases: ensuring that required connections work and forbidden connections fail. These tests run automatically in staging environments before policy deployment to production.
CDA also addresses the organizational challenges of Network Policy implementation. Development teams often resist Network Policies because they complicate local development and testing. CDA works with development teams to create development-specific policy variants that maintain security boundaries while enabling necessary debugging and testing workflows.
• Network Policies implement microsegmentation for Kubernetes clusters, controlling which pods can communicate with other pods and external services based on labels, namespaces, and IP blocks.
• Default Kubernetes networking allows any pod to reach any other pod on any port; Network Policies change this to a deny-by-default model where only explicitly allowed traffic is permitted.
• Network Policy enforcement requires a compatible CNI plugin such as Calico, Cilium, or Weave Net; not all CNI implementations support Network Policies.
• Implementation requires careful planning to avoid application outages from blocked dependencies; organizations should monitor traffic patterns before enforcing restrictive policies.
• Network Policies are essential for compliance requirements like PCI DSS that mandate network segmentation between different security zones.
• Container Security Fundamentals • Kubernetes Security Architecture • Microsegmentation Strategies • Cloud Native Security Controls • Zero Trust Network Architecture
• National Institute of Standards and Technology. "Application Container Security Guide." NIST Special Publication 800-190. https://csrc.nist.gov/publications/detail/sp/800-190/final
• Cloud Security Alliance. "Kubernetes Threat Modeling." Cloud Security Alliance. https://cloudsecurityalliance.org/research/working-groups/containers/
• Center for Internet Security. "CIS Kubernetes Benchmark v1.8.0." Center for Internet Security. https://www.cisecurity.org/benchmark/kubernetes
• MITRE Corporation. "MITRE ATT&CK Framework for Containers." https://attack.mitre.org/matrices/enterprise/containers/
CDA Theater missions that address topics covered in this article.
Cryptographic technique that encrypts data while preserving its original format and length, enabling protection without breaking legacy system compatibility.
Guide to HTTP/2 security covering binary framing, HPACK compression attacks, rapid reset vulnerability, stream multiplexing risks, and mitigation strategies.
Explanation of Certificate Transparency framework, covering log servers, Signed Certificate Timestamps, monitoring capabilities, and detection of fraudulent certificates.
Written by CDA Editorial
Found an issue? Help improve this article.