Kubernetes Network Policies 101: a Brief Guide

In the evolving world of software delivery and IT operations, Kubernetes has emerged as the frontrunner for container orchestration. This is due to its automated deployments, scaling, management of containerized applications, and other powerful features. However, with great power comes great complexity, especially when it comes to Kubernetes networking. 

In Kubernetes, network communication occurs at multiple levels—pods, services, nodes, availability zones, data centers, and the external world. Moreover, given the ephemeral nature of containers, traditional networking solutions will no longer do; this is because conventional IP-based firewalls do not work in a Kubernetes cluster where pods’ IPs can change frequently. 

Enter Kubernetes NetworkPolicies, a native Kubernetes construct designed to secure network communication within a cluster. They allow you to regulate traffic between different parts of your application based on labels and selectors. This is unlike classical IP-based firewalls and segmentation, which have difficulty dealing with the dynamic nature of Kubernetes clusters.

This blog post will discuss what Kubernetes NetworkPolicies are, how they work, and why they’re critical for enhancing the security posture of your cluster.

Understanding Kubernetes NetworkPolicies

Kubernetes NetworkPolicies are a powerful security feature that lets you control the network traffic in and out of your pods. They act as virtual firewalls that determine what traffic is allowed to reach your applications, providing a granular level of control over your application’s network communication.

Kubernetes NetworkPolicies are based on allow-listing traffic. By default, the policies do not apply to any pod. However, once applied to a pod, all traffic is denied unless explicitly permitted by the NetworkPolicy. NetworkPolicies are defined using PolicyTypes, PodSelectors, Ingress, and Egress rules:

• PolicyTypes determine whether the policy will apply to ingress (incoming), egress (outgoing) traffic, or both.
• PodSelectors determine the set of pods to which the policy applies.
• Ingress rules specify which inbound (incoming) network traffic is allowed to reach the selected pods.
• Egress rules specify which outbound (outgoing) network traffic is allowed from the selected pods.

By carefully defining and managing these rules, you can reduce your Kubernetes cluster’s attack surface and better protect your applications from potential threats. Moreover, NetworkPolicies bring consistency and predictability to your cluster’s network communication, easing debugging and troubleshooting efforts.

In addition to Kubernetes’ own native policies, there are also Kubernetes-native external network policies, for example, from Calico and Cilium. These tools extend the functionality of Kubernetes policies, offering additional features and capabilities to enhance the network security of your Kubernetes clusters.

NetworkPolicies use cases

The power of Kubernetes NetworkPolicies lies in their versatility and granularity. They can be tailored to meet specific use cases, helping to secure your cluster based on your unique requirements. Here are three common use cases that demonstrate their potential.

Isolating pods

Suppose you have a sensitive application running within a pod that should not be accessed by any other pod in the cluster. In this case, you can create a NetworkPolicy that denies all inbound traffic to this specific pod, effectively isolating it from the rest of the cluster.

Allowing specific pod-to-pod communication

Consider a scenario where two pods need to communicate with each other, but you do not want them to interact with the rest of the pods in the cluster. In this case, you can create a NetworkPolicy that allows traffic only between these two specific pods, effectively restricting their communication. This helps maintain the integrity and functionality of particular applications.

Allowing traffic from a specific namespace

Namespaces in Kubernetes provide a scope for names and can be used to create virtual clusters within the same cluster. You can define a NetworkPolicy that restricts communication to pods within a namespace, thereby limiting the scope of network traffic and enhancing security. This use case is valuable when managing multi-tenant environments or segregating different parts of your application.

Creating and applying NetworkPolicies in Kubernetes

Creating and applying Kubernetes NetworkPolicies involves defining your policies in a YAML file and applying them to your cluster using the kubectl command-line tool. Here is a step-by-step guide to help you through this process:

1. First, create a YAML file defining your NetworkPolicy according to the Kubernetes API.
2. Once you have defined your policy, apply it via the kubectl apply command.  
3. To confirm that your NetworkPolicy has been applied correctly, you can use the kubectl get networkpolicy command. This lists all the NetworkPolicies applied in your current namespace.
4. To further inspect the details of a specific policy, use the kubectl describe networkpolicy command followed by the name of your NetworkPolicy.

If you suspect that your policy is not working as expected, there are several Kubernetes tools available to help you debug, such as kube-score, or kubeaudit. These tools identify and rectify configuration errors and ensure your NetworkPolicies are correctly deployed.

Implementing NetworkPolicies in a live cluster

For this example, let’s assume we have a cluster with three deployments that need to communicate differently: the frontend, backend, and database, each with multiple pods. The frontend has to communicate with the backend, the backend needs to access the database. However, the frontend should not be able to access the database directly. 

You will need to implement NetworkPolicies that secure the communication between these deployments while maintaining the desired functionality.

Step 1: creating a default deny-all traffic policy

As a best practice, we will first apply a default deny-all policy to every pod, denying any inbound and outbound traffic by default. This establishes a secure baseline from which we can selectively allow necessary traffic:

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

Step 2: allowing traffic to specific deployments

Next, we will define NetworkPolicies that selectively allow necessary traffic. To do this, we’ll allow inbound traffic from the frontend to the backend:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend

Then, we’ll allow inbound traffic from the backend to the database:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-backend-to-database
spec:
  podSelector:
    matchLabels:
      app: database
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: backend

In addition, there are tools like inspektor-gadget that observe the behavior of your application and suggest NetworkPolicies based on this behavior. These can be valuable when managing complex environments. 

Best practices for using Kubernetes NetworkPolicies

Kubernetes NetworkPolicies give you the leverage you need to secure your cluster, but using them effectively requires you to follow best practices. 

Adopt a default deny-all policy

Start with a default deny-all policy to secure your cluster baseline. This blocks all traffic by default; then, you can selectively allow the traffic necessary for your applications to function. This practice is also known as the principle of least privilege, a highly advised concept when it comes to security.

Define policies per application

It is best to define policies per application rather than per cluster. This gives you finer-grained control over your network traffic and makes your policies easier to manage and audit. Also, if one application becomes compromised, it won’t impact the network traffic of other applications.

Keep your NetworkPolicies simple and understandable

NetworkPolicies can quickly become complex, making them difficult to understand and manage. Try to keep your policies as simple and straightforward as possible. Use comments in your YAML files to explain what each policy does and why it’s needed.

Regularly audit and update your NetworkPolicies

Your network requirements will evolve as you deploy new applications or update existing ones. As your requirements change, you will need to regularly review and update your NetworkPolicies.

Test your policies

After defining your NetworkPolicies, test them to ensure they work as expected. Use tools such as kube-hunter, kube-bench, and inspektor-gadget to validate your policies.

Combine NetworkPolicies with other security practices

While NetworkPolicies are crucial to Kubernetes security, they are not a silver bullet. You will need to use them alongside other security practices, like role-based access control (RBAC), security contexts, and secrets management for comprehensive security.

Use tools for complex NetworkPolicies

For complex use cases, consider solutions that extend Kubernetes’ native policies, such as the aforementioned Calico and Cilium. They provide additional features that can help manage complex network traffic scenarios.

Common pitfalls and how to avoid them

While Kubernetes NetworkPolicies offer robust mechanisms for controlling traffic in a cluster, they also come with potential pitfalls that could cause issues in your environment.

Misconfigurations

One of the most common pitfalls is a misconfiguration of your policy rules. This could result from misunderstanding the policy language or human error such as deploying pods with the wrong labels. To avoid this, ensure all policies are reviewed and tested before deployment.

Overly permissive policies

An overly permissive NetworkPolicy can expose your applications to unnecessary risks. Policies that allow more access than necessary can lead to increased attack vectors. Always implement the principle of least privilege, granting only as much access as required.

Conflicting policies

Another common issue occurs when one policy allows certain traffic but another denies it, creating confusion and unexpected behavior. Kubernetes implements policy precedence, where the most restrictive rule applies when conflicts arise. To avoid this issue, thoroughly plan your NetworkPolicies to ensure they don’t conflict with one another.

Dynamic IPs for cloud service endpoints

Cloud services like Amazon’s S3 buckets often have dynamic IP addresses, which change over time. Unfortunately, Kubernetes NetworkPolicies can only manage network traffic based on IP addresses, not DNS/FQDN. This can lead to inconsistencies and potential downtime when those IP addresses change. 

One solution is to use an external solution that can monitor and manage the dynamic IP addresses of these services. However, this adds another layer of complexity to your cluster configuration, so make sure you plan and test these implementations thoroughly.

Ignoring egress traffic

While controlling incoming (ingress) traffic is essential, don’t forget to manage outgoing (egress) traffic from your pods. Limiting egress traffic is a crucial security practice, as it can prevent an attacker from exfiltrating data or spreading malware if a pod gets compromised.

Conclusion

Kubernetes NetworkPolicies are critical in securing your cluster environments and protecting your applications from network-based attacks. They provide fine-grained control over traffic between pods and enable you to implement a robust and defense-in-depth strategy for your applications. 

However, remember that NetworkPolicies are just one aspect of Kubernetes security. You should implement them as part of a comprehensive security approach that includes other techniques such as role-based access control (RBAC), Pod Security admission, secrets management, and more.