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.

Let us take a look on the sample diagram below;

Key Components and Flow

1. Namespaces and Pods: The diagram features three distinct namespaces:

   • Web: Contains Web-App Pods.

   • DB: Contains Database Pods.

   • Monitoring: Contains a Prometheus Pod.

2. Network Policy (NetPol): A central object is the Network Policy: Allow Web to DB. This policy is applied to the DB namespace (via a PodSelector targeting app=db) and defines rules for traffic:

   • Ingress Rule: Allows incoming traffic from Pods with the label app=web.

   • Egress Rule: Allows outgoing traffic to Pods with the label app=db.

3. Traffic Flows: The diagram highlights two crucial traffic scenarios:

   • Allowed Flow (Web-App to Database): A request from a Web-App Pod to a Database Pod is shown. This flow is explicitly Allowed by NetPol because the policy's Ingress rule permits traffic from the Web Pods.

   • Denied Flow (Monitoring to Web-App): A request from the Prometheus Pod (in the Monitoring namespace) to a Web-App Pod is shown. This flow is Denied by Default Isolation. When a Network Policy is applied to a Pod (even if it's in the DB namespace), all other Pods in the cluster become isolated by default unless explicitly allowed by a policy. In this simplified example, the Monitoring Pod's traffic is not explicitly allowed, demonstrating the "deny-all-by-default" behavior of Network Policies.

In essence, the diagram visually explains the core concept: Network Policies act as firewalls for Pods, controlling which Pods can communicate with others based on labels and namespaces, and demonstrating the critical principle of default isolation once a policy is in place.

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.

restricted ingress traffic by Kubernetes Network Policy

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

Get your Kubernetes CIDR Range

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

allow ingress traffic by Kubernetes Network Policy

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.