Kubernetes Network Policies and Their Role in Controlling Traffic Flow
Kubernetes Network Policies are a way to control how pods communicate with each other and with external sources. They allow you to define rules that specify which pods can send or receive traffic, and what kind of traffic is allowed.
What are Kubernetes Network Policies?
Kubernetes Network Policies are a Kubernetes resource that let you define rules for network traffic.
They are applied to pods based on labels and selectors, and they can specify the following:
- direction of the traffic: ingress (incoming) or egress (outgoing)
- source and destination of the traffic: pod selectors, namespace selectors, IP blocks, or ports
- protocol and port of the traffic: TCP, UDP, SCTP, or ICMP
- action to take on the traffic: allow or deny
In Kubernetes, network policies are used to control the flow of traffic between pods. A network policy defines a set of rules that determine whether traffic between two pods is allowed or denied. The policy specifies the source and destination pods, the type of traffic (e.g., HTTP, TCP), and any additional criteria required to permit or deny the traffic.
The Kubernetes networking model relies on a software-defined network (SDN) approach, which separates the control plane from the data plane. The control plane, responsible for managing the network topology and routing decisions, is implemented by the Kubernetes master node(s). The data plane, responsible for forwarding traffic between pods, is handled by the worker nodes.
When a pod sends traffic to another pod, the request first reaches the worker node hosting the source pod. The worker node then encapsulates the request in a tunnel packet and forwards it to the worker node hosting the destination pod. The destination worker node removes the tunnel header and delivers the original request to the destination pod. This process allows Kubernetes to manage inter-pod communication without requiring explicit network configuration on the part of the user.
Why Use Network Policies?
Network policies are useful for enhancing the security and isolation of your Kubernetes applications.
By default, Kubernetes does not restrict any network traffic between pods. This means that any pod can communicate with any other pod in the cluster, as well as with external sources. This can pose security risks, as malicious pods can exploit vulnerabilities in other pods or access sensitive data.
Kubernetes Network Policies allow you to enforce granular rules that limit the network access of pods, and thus improve the security and isolation of your cluster.
With network policies, you can restrict the ingress and egress traffic of your pods based on their labels, namespaces, ports, protocols, and IP addresses.
You can also allow or deny traffic from specific sources or destinations, such as external IPs, DNS names, or other pods. This way, you can enforce the principle of least privilege and limit the attack surface of your cluster.
How Do Kubernetes Network Policies Work?
Suppose we have a simple web application consisting of a frontend and backend, both running in separate pods within the same Kubernetes cluster. The frontend pod needs to communicate with the backend pod to retrieve data. To ensure that only authorized requests reach the backend, we want to apply an ingress policy that permits traffic only from the frontend pod.Here’s how the process would work:
- The frontend pod sends a request to the backend pod
- The request is intercepted by the ingress controller, which checks the ingress policy associated with the backend pod
- The ingress policy evaluates the source of the request (the frontend pod) against the specified source selector (a label selector that matches the frontend pod’s labels)
- Since the source selector matches, the ingress policy grants permission for the request to proceed to the backend pod
- The request is delivered to the backend pod, which processes the request and returns a response
- The response is sent back to the frontend pod through the reverse path, following the same process in step 3
- Once the response arrives at the frontend pod, it’s returned to the client
Types of Network Policies
Ingress Policies
Ingress policies control incoming traffic to a pod. An ingress policy specifies which sources are allowed to reach a particular pod. When a client outside the cluster sends a request to a pod, the request must pass through an ingress controller, which enforces the defined ingress policy.
Egress Policies
Egress policies control outgoing traffic from a pod. An egress policy specifies which destinations a pod can connect to. When a pod initiates a connection to a target outside the cluster, the egress policy determines whether the connection is allowed.
Internal Policies
Internal policies control traffic between pods within the same cluster. An internal policy specifies which pods can communicate with each other. Internal policies are typically used to segregate parts of an application or to protect sensitive resources.
Use Cases for Network Policies
- isolating pods or namespaces from each other, and creating security zones or boundaries within your cluster
- allowing or denying access to specific services or endpoints, such as databases, APIs, or external resources
- enforcing compliance or regulatory requirements, such as PCI-DSS, HIPAA, or GDPR
- enhancing performance or reliability, by reducing network congestion or latency, or preventing denial-of-service attacks
Common Usage
DENY all traffic to an application
It’s common to use Network Policies to whitelist traffic by first blacklisting it.
This can be useful when running a Pod and wanting to prevent communication with other Pods, or when temporarily isolating traffic to a Service from other Pods.
LIMIT traffic to an application
Traffic to a service can be restricted to only other microservices that need to use it, and connections to a database can be restricted to only the application using it.
DENY all non-whitelisted traffic to a namespace
Fundamental policy is to block all cross-pod networking except for those whitelisted by other Network Policies.
This manifest should be applied to any namespace with workloads, except for kube-system.
As a best practice, this policy provides a default deny all functionality, allowing for clear identification of dependencies between components and the deployment of Network Policies that can be translated into dependency graphs.
DENY all traffic from other namespaces
NetworkPolicy can be configured to deny traffic from other namespaces while allowing traffic from the same namespace as the deployed pod.
This can be useful in cases where you want to prevent deployments in a test namespace from accidentally sending traffic to services or databases in a prod namespace, or when hosting applications from different customers in separate Kubernetes namespaces and wanting to block traffic from outside a namespace.
ALLOW traffic to an application from all namespaces
If you have Common service or database used by deployments in different namespaces, you may not need a NetworkPolicy to block traffic to the application unless there is already a NetworkPolicy in place blocking non-whitelisted traffic to all pods in the namespace.
ALLOW all traffic from a namespace
Traffic to a production database can be restricted to only namespaces where production workloads are deployed, and monitoring tools deployed to a particular namespace can be enabled to scrape metrics from the current namespace.
ALLOW traffic from some pods in another namespace
Since Kubernetes v1.11, it is possible to combine podSelector and namespaceSelector with an AND (intersection) operation.
However, this feature is only available on Kubernetes v1.11 or later and may not be supported by all networking plugins. It is important to test this policy after deployment to ensure it is working correctly.
ALLOW traffic only to a port of an application
If a port is not specified in the ingress rules, the rule applies to all ports.
A port can be either a numerical or named port on a pod.
This can be useful in cases such as allowing a monitoring system to collect metrics by querying the diagnostics port of your application, without giving it access to the rest of the application.
ALLOW traffic from external clients
If you need to expose pods to the public Internet in a namespace that denies all non-whitelisted traffic, you can do so by configuring the appropriate NetworkPolicy.
Best Practices for Network Policies
Conclusion
Kubernetes Network Policies are a way to control the traffic flow between pods and other network endpoints in a Kubernetes cluster. They allow you to define rules that specify which pods can communicate with each other and with external services, and how they can do so.
