What are Good Use Cases for Kubernetes Network Policy and a Sample Demo

By default, Kubernetes allows all pods to communicate with each other, which simplifies the management of micro services. However, there are situations where you might want to restrict this communication within pods. Kubernetes Network Policy enhances security within Kubernetes without the need for a firewall.

Looking at the Correct Design on the left through Network Policy we were able to create a rules that allows front end and micro service communicate, and micro service and database communicate securely without needing to go out to internet. For simplicity I did not draw the service component of the database on the left.

On the contrary on the right is a bad design practice that I've seen often. A front end communicates to a micro service but needs to traverse all the way out to internet and pass through third-party firewall making all the hops. Same thing with micro service needing to go out to the public internet just to communicate to local database.

Use Case 1: Enhanced Performance in Application Running in Kubernetes

In the past; I've seen design where a micro service A and micro service B communicates by traversing over the internet, a typical traditional security requirement in a non-cloud native perspective. This comes with a price of network and latency performance because communication of two micro services needs to traverse over the internet, and is further slowed down by unnecessary deployment of third-party firewall in between the micro service.

A good solution is make the two micro service communicates via internal Kubernetes network leveraging on services rather than traversing in the internet. Further more a Kubernetes Network Policy can be put in placed to restrict and accept traffic within a pod level.

Use Case 2: Negligence in Development

I've seen in the past where Development environment API are being pointed to production for troubleshooting. As a result horrors happens in production database. To prevent such happening, a network policy in the Kubernetes layer put in placed is a good use case for Kubernetes Network Policy.

Use Case 3: Database Connectivity

In a multi-tier application, you wanted to limit connectivity to your database from specific micro-services that needs database connectivity, and would like to block other incoming connection such as from front-end, other pods, or from other namespaces for added security. This follows the principle of least privileges, this is another good use case for Kubernetes Network Policy.

Use Case 4: During Pre-Production Deployment

Technically pre-production and production environment is the same and identical. This can be achieved by having both environment deployed in the same cluster with different namespace with the same back-end.

Pre-production are used by internal testers conducting final test prior of release, while Production environment are for live users. Using Kubernetes Network Policy, a rule can be created that exposes pre-production environment during testing then blocking it then after. With this approach, a project team can control the usage of pre-production testing.

Simple Kubernetes Network Policy Demonstration

Step 1: Create the Kubernetes Deployment, Service, and Ingress

To create the three per-requisite Kubernetes resources for this demo follow by previous post instruction in this link How to Setup Kubernetes Ingress Controller.

Step 2: Create a Kubernetes Network Policy

Demonstration of Kubernetes Network Policy

Scenario 1: Restrict the Ingress from specific CIDR block

First let us create a network policy that denies my IP range. Assuming my IP is 192.168.100.45. The policy below will surely deny my http connection.

Deny Policy for my IP

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: network-demo
spec:
  podSelector:
    matchLabels:
      app: httpd
  policyTypes:
  - Ingress
  ingress:
  - from:
    - ipBlock:
        cidr: 172.17.0.0/16
    ports:
    - protocol: TCP
      port: 80

If we do curl

curl http://web.cloudlet.io:80/home

Then this http call will result to timeout.

Scenario 2: Allow the Ingress from specific CIDR block

This time we will now create a Kubernetes Network Policy that allows traffic coming from external IP range. Do note that since your deployment is exposed using service, the IP range to use must be your Kubernetes cluster CIDR, that is because the Network Policy will not see your source IP.

Check your CIRDR range

ps -ef | grep kube-controller-manager | grep cluster-cidr

We will now allow traffic coming IP specific CIDE range. To do this we need to replace the cidr fron the ingress block to 10.10.0.0/16 using the result of the previous command.

Replace the CIDR Block to allow traffic

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: network-demo
spec:
  podSelector:
    matchLabels:
      app: httpd
  policyTypes:
  - Ingress
  ingress:
  - from:
    - ipBlock:
        cidr: 10.10.0.0/16
    ports:
    - protocol: TCP
      port: 80

kubectl apply -f <your yaml file>

If we do curl

curl http://web.cloudlet.io:80/home

Then this http call will now succeed

Summary

We have demonstrated basic Kubernetes Network Policy, there are more configuration available such as pod to pod communication policy. The one we showed here is just basic policy to restrict traffic to pod within a traffic coming from the cluster service.