Network Policies in Kubernetes: Key Concepts, Challenges & Best Practices

Sometimes, you want to allow Kubernetes workloads to talk to each other - as well as the outside world - without limits. But in other cases, you want to restrict which network communications are allowed. Doing so can help to mitigate network-related security risks. It may also improve performance by conserving network bandwidth.

This is why Kubernetes offers network policies, a capability that effectively lets you establish firewall rules to govern network communication both inside your cluster and between the cluster and external network endpoints.

Read on for the details as we explain everything Kubernetes admins need to know about working with network policies.

What are network policies in Kubernetes?

In Kubernetes, network policies are rules that specify how Pods can communicate with each other, and/or with external endpoints. Network policies can block traffic entirely between specific workloads and network endpoints. They can also allow or deny traffic based on characteristics like port number or protocol type.

In essence, network policies function as a type of software-defined firewall, although they’re not the same as traditional firewalls because they are implemented within Kubernetes rather than at a higher level of the networking stack.

Importantly, Kubernetes doesn’t establish any network policies by default. This means that, unless you set up network policies, all Pods are allowed to communicate with all other Pods, as well as with any external endpoints. But by creating network policies, you can establish networking rules that isolate workloads at the network level or enforce a “least privilege” networking security model.

There is no hard limit on how many network policies you can create. In most cases, you’ll need multiple network policies, each tailored to different workload requirements. However, it’s important to avoid deploying so many that they become hard to manage.

Why network policies are critical for Kubernetes security & stability

Network policies serve two key purposes in Kubernetes:

• Security: The ability to filter or block traffic helps to mitigate security risks. For example, you could use network policies to isolate a sensitive workload from the public Internet by blocking communications with external endpoints. Or, you could filter out network requests that use a vulnerable protocol.‍
• Stability and performance: Controlling traffic flows can also help to optimize the use of available bandwidth, which in turn boosts application health and performance. This tends to be especially important when managing “north-south” traffic (meaning traffic that flows between Kubernetes workloads and external endpoints), since external bandwidth tends to be more limited than internal “east-west” connectivity - but even within a cluster, there may be cases where you want to prioritize certain types of traffic or workloads.

Common types of network policies

Network policies in Kubernetes are flexible and allow for highly granular configurations; you are not limited to a handful of preconfigured options. That said, there are certain types of network policies that admins commonly turn to because they are easy to enable with minimal configuration. They include:

• Deny all: This type of policy blocks all traffic to a Pod (or group of Pods) by default. Only traffic that is specifically allow-listed can pass through.
• Label-based filtering: Using Pod labels, you can configure which Pods can communicate with which other Pods.
• Egress control: Egress network policies restrict how Pods communicate with external endpoints. For example, they could be configured to allow communications only with a specific range of external endpoint IP address ranges, or with a specific CIDR block.
• Ingress control: Similarly, you can create ingress policies that block or filter incoming traffic.
• Namespace-based policies: Namespace network policies allow traffic only within a given namespace or between specific namespaces. They are useful as a way of enforcing network segmentation between workloads that occupy particular namespaces.

How network policies work in Kubernetes

Network policies work by using YAML to define networking rules. From there, a Container Network Interface (CNI) plugin enforces the rules. Under the hood, most CNI network plugins rely on the Linux kernel’s iptables capabilities or on eBPF to filter or block packets as they flow to and from nodes.

The network filtering capabilities of CNI plugins can vary a bit, so it’s important to know what your CNI actually supports if you are implementing a complex configuration. That said, all of the major CNIs support the core types of common network policies.

Steps to create and apply network policies

As we mentioned, Kubernetes doesn’t set up any network policies by default. You have to create and apply them using the following steps:

1. Enable a CNI network plugin

First, make sure your cluster has a CNI plugin set up. If it doesn’t, you can install one. You’d typically do this by applying a manifest for the CNI using a command such as:

kubectl apply -f /path/to/manifest.yml

2. Define desired network policies

Write YAML code to describe the policies you want to enforce. As we noted, you can configure a broad range of rules. But as a simple example, here’s a basic network policy that blocks egress (i.e., outgoing traffic) for all Pods.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all-egress
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Egress

Note that in this example, the {} podSelector value matches all Pods. If we wanted to apply the policy only to certain Pods, we could identify them here.

3. Apply the policies

For your new network policy to take effect, you have to apply it. You can do this using a command such as:

kubectl apply -f /path/to/network-policy.yml

4. Verify and test network policies

You can confirm that the new network policy is in effect using the command:

kubectl get networkpolicy --all-namespaces

Core components of Kubernetes network policies

Most network policies include four key elements:

• PodSelector: This determines which Pods the policy applies to. As we showed above, you can use the {} value to select all Pods, or you can choose specific ones.
• PolicyType: Establishes whether the policy applies to ingress traffic, egress traffic, or both.
• Ingress rules: Specifies rules that apply to ingress traffic specifically.
• Egress rules: Specify rules that apply to egress traffic specifically.

Beyond this, network policies closely resemble any other type of standard Kubernetes resource in terms of how you write them using YAML.

Challenges and limitations of Kubernetes network policies

Although Kubernetes network policies are, on the whole, flexible and easy to work with, they are subject to some challenges and limitations:

• CNI dependency: As we noted, network policies rely on CNI plugins to enforce network policies, and CNIs vary in terms of exactly which capabilities they offer. This can lead to frustration because a network policy that works for one cluster may not work in another, due to differences in the CNIs used within each cluster. Complicating matters is the fact that Kubernetes won’t explicitly warn you that a network policy can’t be enforced due to CNI limitations; it will just fail silently.
• Pod-centric configuration: Network policies work at the Pod level. This can make it challenging to apply different policies to individual containers or other specific types of resources that are not Pods.
• Lack of encryption capabilities: Network policies can’t enforce encryption for network traffic. To do that, you need to include encryption support within Pods or use a tool such as a service mesh to encrypt traffic inside the cluster.‍
• Limited observability: On their own, network policies don’t offer much in the way of observability or visibility capabilities. Kubernetes won’t alert you to problems, and it logs minimal data related to network policy enforcement. You need additional tools to get deeper visibility.

Best practices for configuring and monitoring network policies

To get the most from network policies with the least hassle, consider the following best practices:

• Keep policies simple: In general, it’s better to have a larger number of policies that are each short and simple, as opposed to trying to cram a lot of complicated functionality into a single policy.
• Know your CNI capabilities: It’s critical to know which capabilities your CNI plugin supports, then design network policies accordingly.
• Monitor policies using external tools: The limited visibility that Kubernetes offers into network policy behavior makes it crucial to deploy external tools that can monitor network policy status, as well as detect networking errors.
• Don’t rely on network policies alone: While network policies are one important resource for managing network security and performance, they’re not a substitute for other types of tools like service meshes, ingress controllers, and cloud firewalls. These provide additional capabilities (like data encryption support) that you can’t enforce using network policies.‍
• Consider namespaced policies: You can configure a network policy to apply to a specific namespace by selecting the namespace within the policy’s metadata. Doing so is a convenient way to apply centralized policies to workloads of the same type, provided you separate those workloads by namespace. For example, you could have one namespace for testing workloads where external connections are blocked, and another namespace for production apps that need access to external network endpoints.

Observability and troubleshooting for network policies in Kubernetes

When it comes to observing and troubleshooting network policies, Kubernetes doesn’t offer much built-in tooling. The only thing you can really do is verify each existing network policy using the following command:

kubectl get networkpolicy --all-namespaces

This will tell you which network policies are in force, but if you want visibility into how traffic is actually flowing, you’ll need external tools. EBPF-based observability tools (like groundcover) excel at this task because they trace packets as they flow across nodes, which means you get deep, granular insight into which traffic is moving to and from which workloads. You can also detect bottlenecks that are slowing down the movement of data, and identify workloads that are not able to reach other endpoints.

Another approach is to log network data at the application level as a way of gaining visibility. However, this is generally not ideal. Not only does it require more effort (because you need to implement network logging logic within your applications), but it also provides limited observability because it only shows you the state of traffic flows from the application’s perspective. Issues that may exist at other layers of your stack (like problems with an operating system’s network socket) won’t typically be visible.

Tools and techniques for managing network policies

When it comes to creating and deploying network policies in Kubernetes, your go-to tool is kubectl, as explained above. For observability purposes, however, you’ll need a tool that can provide deep visibility into packet flows, as we also explained above. Kubernetes can’t do this natively on its own.

Note, too, that network policy tooling and techniques can vary depending on which CNI you use. Some CNIs (such as Calico) include native logging and visualization tools to help Kubernetes admins analyze network traffic. But others provide little in the way of built-in network monitoring and management capabilities, making it important to leverage other tools for these purposes.

End-to-end visibility and security insights for network policies with groundcover

No matter which CNI you use or which network policies you deploy, groundcover offers the deep visibility you need to track the security and performance of Kubernetes network policies.

Unlike most observability tools, groundcover uses eBPF to collect monitoring data directly from the operating systems running on each node. In addition to being hyper-efficient, this approach also provides extremely granular networking visibility by tracing where each individual packet is coming and going. Other solutions only map general traffic flows, making it harder to pinpoint security risks or trace network performance issues to their root cause.

You don’t strictly need to deploy network policies in Kubernetes, but if you care about network security and performance (and you probably do), configuring network policies is a smart way to help optimize Kubernetes in both of these areas. And with the right observability tools on your side, it’s easy to confirm that your network policies are doing what you intended, and identify the root cause of problems when they’re not.