What Is a Kubernetes Network Policy?
A Kubernetes network policy controls incoming and outgoing connections between Pods and other network destinations. The article explains how ingress and egress rules work, why default network access can create security risks, and how to configure and verify traffic restrictions. It also covers common policy mistakes and how Saner COSP's COAE and COPM modules support Kubernetes exposure visibility and configuration assessment.
A Kubernetes network policy is a set of rules that controls which network connections Pods can receive and initiate. It restricts traffic using Pod labels, namespace labels, IP address ranges, ports, and protocols. Administrators use NetworkPolicies to limit unnecessary communication between workloads and reduce the possible impact of a compromised application.
Kubernetes normally permits Pod traffic when no applicable NetworkPolicy restricts it. Creating a policy changes that behavior only for the selected Pods and traffic direction. Enforcement also depends on a compatible cluster networking plugin. A policy accepted by the Kubernetes API does not automatically mean traffic is restricted.
How Does a Kubernetes Network Policy Work?
A NetworkPolicy is a namespaced Kubernetes resource. Its podSelector identifies the Pods governed by the policy within that namespace. Ingress rules control connections arriving at those Pods. Egress rules control connections initiated by them.
The rules describe allowed traffic. Native NetworkPolicies do not contain explicit deny rules. Instead, selecting a Pod for ingress or egress makes that direction restricted, and only connections permitted by applicable policies are allowed. A Pod can be restricted for ingress, egress, or both.
Two details matter when assessing the result. First, policies are additive. If two policies select the same Pod, traffic permitted by either policy is allowed in the relevant direction. Second, for a connection between two restricted Pods, the sender's egress rules and the receiver's ingress rules must both permit it.
| Policy field | Purpose | Practical example |
|---|---|---|
| podSelector | Selects Pods governed by the policy | Database Pods labeled app=db |
| namespaceSelector | Selects namespaces permitted as traffic peers | Pods from an approved application namespace |
| ipBlock | Identifies an IP address range | An approved external network CIDR |
| ingress | Describes allowed incoming connections | API Pods reaching the database |
| egress | Describes allowed outgoing connections | Application traffic to an approved service |
| policyTypes | Specifies whether ingress, egress, or both are restricted | Ingress and Egress |
NetworkPolicies ordinarily operate at network and transport layers. Native policies filter by IP information, TCP or UDP ports, and supported protocols, rather than HTTP paths, API methods, or user identities.
Why Are Network Policies Important for Kubernetes Security?
A Kubernetes namespace organizes resources, but namespace boundaries alone do not block Pod-to-Pod network traffic. Without suitable restrictions, an application may communicate with unrelated workloads in another namespace.
Consider a web application, an API service, and a database. The web component needs to call the API, and the API needs access to the database. The database usually does not need to accept connections from every workload in the cluster.
An attacker who compromises a reachable application could attempt to connect to internal services that allow unrestricted traffic. Carefully scoped policies can limit those network paths. They do not prevent the initial application compromise or replace identity controls, application authentication, and workload security settings.
What Is the Difference Between Ingress and Egress Rules?
Ingress rules apply to traffic arriving at the selected Pods. Egress rules apply to traffic leaving them. They are independent, so an ingress-only policy does not automatically restrict outbound connections.
| Traffic direction | Example requirement | Intended restriction |
|---|---|---|
| Ingress | Database accepts TCP port 5432 from API Pods | Other Pod sources cannot initiate database connections unless another policy permits them |
| Egress | API connects to the database on TCP port 5432 | API connections to unrelated destinations are not permitted unless explicitly allowed |
| Both | API communicates with the database but not unrelated services | Apply compatible outbound and inbound rules to the appropriate Pods |
The actual result depends on every applicable policy. Removing one allow rule may not block a connection if another policy still permits it.
Is a NetworkPolicy the Same as an Ingress Resource or RBAC?
No. A Kubernetes Ingress resource describes how HTTP or HTTPS requests are routed to Services, usually through an ingress controller. A NetworkPolicy controls permitted network connections to and from selected Pods. An externally reachable Service may still need network restrictions on its backend Pods.
RBAC governs requests to the Kubernetes API. It does not control ordinary application traffic between Pods. Teams should review network communication, API permissions, and application authentication as separate controls.
Native NetworkPolicies also have limits. They do not provide explicit deny rules or HTTP request filtering, and Pod connections to their own node are treated specially. Some host-networked Pods and traffic translated by network address translation can behave differently across networking implementations. Validate the actual traffic path rather than assuming uniform behavior.
What Does Default Deny Mean in Kubernetes?
Default deny means selecting Pods for a traffic direction without providing rules that permit connections in that direction. For example, a namespace-wide policy can select all Pods with an empty podSelector and specify both Ingress and Egress without corresponding allow rules.
Because NetworkPolicies are namespaced, a policy created in one namespace does not automatically protect Pods in another. Teams must apply their baseline to the intended namespaces and account for existing rules.
Default-deny rollout requires careful testing. Blocking egress also affects DNS queries, connections to external services, and other required dependencies. Applications may need separate allowances for cluster DNS, observability components, and approved external endpoints.
Apply restrictions first in a representative environment, then verify required connections before expanding to production workloads.
How Can Teams Create a Network Policy for an Application?
Consider a hypothetical application in a namespace named payments. Its API Pods have the label app=api, while database Pods have app=db. Only the API needs to reach the database on TCP port 5432.
A suitable ingress policy would use the following settings.
| Setting | Example value |
|---|---|
| Policy namespace | payments |
| Selected destination Pods | app=db |
| Traffic direction | Ingress |
| Permitted source Pods | app=api within payments |
| Permitted protocol | TCP |
| Permitted destination port | 5432 |
Configure podSelector to select database Pods. Under ingress, use a from rule containing a podSelector for the API Pods and a ports entry for TCP 5432. A Pod selector in this form refers to the same namespace as the policy. For cross-namespace access, add a suitable namespace selector and validate how the selectors are combined.
The policy restricts incoming connections to the selected database Pods, subject to any other applicable policies. It does not, by itself, restrict traffic leaving those Pods or the API Pods.
Before deployment, confirm that the database label is correct and that other required clients have been accounted for. Test access from approved API Pods and from a Pod that should be denied. Confirm that the application still performs its normal transactions.
Administrators can inspect current objects with the following commands.
kubectl get networkpolicy -A
kubectl get pods -n payments --show-labels
kubectl describe networkpolicy allow-api-to-db -n payments
The final command assumes the example policy has been created under that name. Listing and describing policies shows the intended configuration, not proof that the network plugin enforces it. Test actual connections and check the networking implementation's diagnostic data where available.
Which Kubernetes Network Policy Mistakes Cause Security Gaps?
Assuming a Saved Policy Is Enforced
The Kubernetes API accepts NetworkPolicy resources even if the cluster network plugin does not enforce them. Check plugin support and validate allowed and denied traffic. A configuration object alone is not evidence of network isolation.
Using Selectors That Match Too Many Pods
Broad or incorrect Pod and namespace labels can permit connections from workloads that do not need access. Review labels after deployments because changes to labels can affect the Pods matched by existing policies.
Restricting Ingress but Ignoring Egress
Ingress-only restrictions protect selected destinations from unwanted incoming connections but do not control the connections those Pods initiate. Where appropriate, add egress restrictions for known application dependencies and external services.
Blocking Required DNS or Service Traffic
Namespace-wide egress restrictions can interrupt name resolution or calls to dependent services. Map normal communication first, test in stages, and permit the minimum traffic the application requires.
Treating Policies as Application Firewalls
Native NetworkPolicies generally filter network connections at layers 3 and 4. They do not validate HTTP authorization or restrict requests by URL path. Application authentication, API access controls, and other suitable safeguards remain necessary.
How Should Teams Assess Network Policies Across Clusters?
Review policy coverage alongside the workloads and services they affect. A useful inventory includes the cluster, namespace, selected Pods, ingress and egress restrictions, exposed services, policy owner, and last verification date.
Assess whether important namespaces have an appropriate baseline, whether Pods still permit unnecessary communication, and whether the cluster plugin enforces the intended controls. Compare policy rules with actual application dependencies before recommending changes.
For example, a database with no ingress restrictions may deserve earlier attention if it is reachable from a compromised or publicly accessible workload. A development service with tightly controlled communication may carry a different level of risk. Assess the affected workload and network path rather than counting policy objects alone.
How Do COAE and COPM Support Network Policy Assessment?
SecPod's Saner COSP connects Kubernetes resource visibility with configuration posture assessment through two complementary modules.
Container Orchestration Asset Exposure, COAE gives security teams visibility into Kubernetes resources, namespaces, workloads, and open port exposure. That information helps identify resources and access points worth investigating.
Container Orchestration Posture Management, COPM assesses Kubernetes configurations against supported security benchmarks and organizational rules. SecPod's documentation includes misconfigured network policies among the issues COPM can report, with affected resources and namespace-level findings.
Together, these capabilities help teams identify potentially exposed resources, examine related configuration issues, assign remediation work, and review the resulting posture. Actual packet filtering still depends on Kubernetes network configuration and a compatible enforcement plugin. Administrators should verify changes through functional and connectivity tests.
What Should Teams Do After Applying a Network Policy?
Confirm that approved traffic works and prohibited connections fail. Repeat the checks after application deployments, changes to Pod labels, networking updates, and policy modifications. Keep the relevant configuration and verification record with the affected application.
A Kubernetes network policy is useful only when it selects the intended workloads and is enforced as expected. Combine least-privilege network rules with resource visibility, configuration assessment, and recurring validation to reduce unnecessary communication paths inside the cluster.
