Network Policy | Kubernetes
Kubernetes network policies for pods and namespaces isolation
The Kubernetes networking model specifies:
● Every pod gets its own IP address.
● Pods can communicate with all other pods in the cluster using pod IP addresses (without NAT).
● Isolation (restricting what each pod can communicate with) is defined using network policies.
Let’s create two namespaces and deploy some pods into those namespaces; after then we will test how pods communicate with each other in the Kubernetes cluster.
● Create a new namespace named prod, and deploy three pods into that namespace.
● Create another namespace named dev, and deploy two pods into that namespace.
Communication between pods within the same namespace:
Now, let’s see if two pods (webserver-1 and webserver-2) within the same namespace (prod) can communicate with each other :
Similarly, webserver-2 can communicate with webserver-3.
Communication between pods from different namespaces:
Now we will test communication between two namespaces; Let’s see if a pod (testserver-1) residing in the “dev” namespace can communicate with a pod (webserver-1) residing in the “prod” namespace:
From the above demonstration, we have clearly seen that a pod can communicate with other pods independently; even pods from different namespaces also can communicate with each other. In a multi-tenant production environment; it is a very common practice to access control between the pods. In Kubernetes, access control between the pods is done by network policies.
Network Policy
Network Policy resource allows us to restrict ingress and egress traffic to/from pods. For instance, using network policies we can restrict the ingress traffic of database pods to the backend pods only, and also we can restrict the ingress traffic of a backend pod to a frontend pod only. As an outcome, if somehow any attacker gets access to the frontend application, can't directly access the database or any other pods.
For software and hardware, traffic control can be done by using firewalls. But in the case of Kubernetes, traffic control functionality is implemented by network plugins and controlled by network policies.
Prerequisites
The network plugin implements network policies. To use network policies, you must use a networking solution that supports Network policies.
More about network plugins and the installation process.
Walkthrough
Let’s do a walkthrough of a network policy defined below.
Cautions
namespaceSelectorAND podSelectorIf we want to allow connection to/from a particular pod within a particular namespace then we have to configure the rules in the following way—
namespaceSelectorOR podSelector
If we want to allow any pods to/froma particular namespace or a particular pod groups to/from any namespaces, then we have to configure the rules in the following way —
1. Ingress Traffic
1.1 Allow ingress traffic from pods in the same namespace
If we create a network policy using the above manifest file, then our webserver-1 only allows ingress traffic from webserver-2, but since we did not configure anything for egress traffic, webserver-1 can send egress traffic to webserver-2 and webserver-3. See the following image for a better understanding:
1.1.0 Ingress Test:
1.2 Allow ingress traffic from pods in a different namespace
If we create a network policy using the above manifest file, then our webserver-1 only allows ingress traffic from testserver-1, which is in a different namespace named dev. See the following image for a better understanding:
Now, let me ask you one thing; since we are configuring a policy for a particular pod (webserver-1) or pod group. What do you think? The testserver-1 from the dev namespace can only access webserver-1 or can access all the existing pods in the prod namespace?
The answer is, YES!
Right now, testserver-1 from the dev namespace will be able to access not only the webserver-1 pod or pod group but also, all the existing pods in the prod namespace.
If you don’t want to expose all the pods to different namespaces, it's a best practice to apply the default deny-all ingress network policy to the namespaces.
1.3 Create deny-all default ingress network policy:
The following network policy implements a default deny-all ingress policy, which prevents all-ingress traffic to the pods in the defined namespace.
All ingress traffic to the pods in the defined namespace(prod) will be denied unless the traffic is explicitly allowed by another network policy.
If we apply the default deny-all ingress policy along with ingress from a different namespace. Then, only the selected pods can be accessed from different namespaces.
2. Egress Traffic
2.1 Allow egress traffic to pods in the same namespace.
If we create a network policy using the above manifest file, then our webserver-1 can only send egress traffic to the webserver-3. But since we did not configure anything for ingress traffic, webserver-1 will allow ingress traffic from everywhere. See the following image for a better understanding:
2.1.0 Egress Test:
2.2 Allow egress traffic to pods in the different namespaces.
If we create a network policy using the above manifest file, then our webserver-1 pod within the prod namespace can only send egress traffic to the defined pods (testserver-1) in the dev namespace. Other undefined pods residing in the dev namespace cannot be accessed from the webserver-1 pods. See the following image for a better understanding:
In the above demonstration, we have seen that webserver-1 can only send traffic to the testserver-1 pod. But we should also keep in mind that not only the webserver-1 pod can send traffic to the testserver-1 pod, but also other pods residing in the prod namespace can send traffic to the dev namespace.
If you don't want to allow other pods within the prod namespace to send egress traffic to the dev namespace or prevent accidental access to the pods. It’s best practice to apply the default deny-all egress network policy along with other policies.
If we apply the default deny-all egress policy along with egress traffic to pods in the different namespace. Then, only the selected pods can send egress traffic to the different namespaces.
3. Default deny all ingress and all egress traffic
We can create a “default” policy for a namespace that prevents all ingress AND egress traffic by creating the following NetworkPolicy in that namespace.
This ensures that all the pods in the defined namespace (In this case-prod) will not be allowed ingress or egress traffic, unless the traffic is explicitly allowed by another network policy.
Bonus: Let’s explore more about network policies —
Suppose, we have several namespaces in the k8s cluster and we also have a requirement to isolate our prod namespace from other namespaces. The only namespace that can access the prod namespace is the dev namespace. Let’s see how we can achieve that —
To achieve our above-explained goal; First of all, we have to apply default deny all ingress and all-egress traffic network policy to the prod namespace. And then, we have to apply another network policy to the prod namespace. So that all the pods under the prod namespace can allow ingress traffic only from the dev namespace. Create the network policy using the following manifest file —
After applying the network policy shown above, only the dev namespace can send traffic to the prod namespace.
Network policy is a little bit tricky topic. I tried to explain as simply as possible, hope this article helped you to understand Kubernetes network policies more clearly. If you found this article helpful, please don’t forget to hit the Clap and Follow buttons to help me write more articles like this.
Thank You 🖤
👇 All Articles on Kubernetes
References
If you find this helpful, please click the clap 👏 button below a few times to show your support for the author 👇
