ARMO named in Gartner® Cool Vendors™ report
We are excited and honored to announce that we were selected as Gartner Cool Vendor...
Aug 17, 2023
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.
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:
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.
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.
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.
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.
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 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:
kubectl apply
command. kubectl get networkpolicy
command. This lists all the NetworkPolicies applied in your current namespace.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.
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.
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
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.
Kubernetes NetworkPolicies give you the leverage you need to secure your cluster, but using them effectively requires you to follow best practices.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Experience effective, end-to-end, from dev to production, Kubernetes protection:
Manage Kubernetes role-based-access control (RBAC) visually
Eliminate misconfigurations and vulnerabilities from your CICD pipeline – from YAML to cluster
Full Kubernetes security compliance in a single dashboard