Mastering Kubernetes Network Policies - A Hands-On Guide

Network policies are a crucial aspect of Kubernetes security, allowing fine-grained control over pod-to-pod communication. In this hands-on guide, we’ll walk through setting up a Kind cluster with Calico, deploying applications, and implementing network policies.

Step 1: Creating a Kind Cluster with Custom Networking#

First, let’s create a Kind cluster with the default CNI disabled:

1
kind: Cluster
2
apiVersion: kind.x-k8s.io/v1alpha4
3
nodes:
4
  - role: control-plane
5
    extraPortMappings:
6
      - containerPort: 30001
7
        hostPort: 30001
8
  - role: worker
9
  - role: worker
10
networking:
11
  disableDefaultCNI: true
12
  podSubnet: 192.168.0.0/16

Save this as kind-config.yaml and create the cluster:

1
kind create cluster --config kind-config.yaml

Step 2: Installing Calico#

Follow the official Calico documentation to install it on your Kind cluster:

1
kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.25.0/manifests/tigera-operator.yaml
2
kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.25.0/manifests/custom-resources.yaml

Step 3: Deploying Applications#

Let’s create deployments for frontend, backend, and db:

1
apiVersion: apps/v1
2
kind: Deployment
3
metadata:
4
  name: frontend
5
spec:
6
  replicas: 1
7
  selector:
8
    matchLabels:
9
      app: frontend
10
  template:
11
    metadata:
12
      labels:
13
        app: frontend
14
    spec:
15
      containers:
16
        - name: nginx
17
          image: nginx
18
          ports:
19
            - containerPort: 80
20
---
21
apiVersion: apps/v1
22
kind: Deployment
23
metadata:
24
  name: backend
25
spec:
26
  replicas: 1
27
  selector:
28
    matchLabels:
29
      app: backend
30
  template:
31
    metadata:
32
      labels:
33
        app: backend
34
    spec:
35
      containers:
36
        - name: nginx
37
          image: nginx
38
          ports:
39
            - containerPort: 80
40
---
41
apiVersion: apps/v1
42
kind: Deployment
43
metadata:
44
  name: db
45
spec:
46
  replicas: 1
47
  selector:
48
    matchLabels:
49
      app: db
50
  template:
51
    metadata:
52
      labels:
53
        app: db
54
    spec:
55
      containers:
56
        - name: mysql
57
          image: mysql:5.7
58
          ports:
59
            - containerPort: 3306
60
          env:
61
            - name: MYSQL_ROOT_PASSWORD
62
              value: password

Save this as deployments.yaml and apply:

1
kubectl apply -f deployments.yaml

Step 4: Exposing Services#

Now, let’s expose these deployments as NodePort services:

1
apiVersion: v1
2
kind: Service
3
metadata:
4
  name: frontend
5
spec:
6
  type: NodePort
7
  selector:
8
    app: frontend
9
  ports:
10
    - port: 80
11
      targetPort: 80
12
      nodePort: 30001
13
---
14
apiVersion: v1
15
kind: Service
16
metadata:
17
  name: backend
18
spec:
19
  type: NodePort
20
  selector:
21
    app: backend
22
  ports:
23
    - port: 80
24
      targetPort: 80
25
      nodePort: 30002
26
---
27
apiVersion: v1
28
kind: Service
29
metadata:
30
  name: db
31
spec:
32
  type: NodePort
33
  selector:
34
    app: db
35
  ports:
36
    - port: 3306
37
      targetPort: 3306
38
      nodePort: 30003

Save this as services.yaml and apply:

1
kubectl apply -f services.yaml

Step 5: Testing Connectivity#

To test connectivity, you can use temporary pods:

1
kubectl run tmp-shell --rm -i --tty --image nicolaka/netshoot -- /bin/bash

From within this pod, you can use curl to test connections to other services.

Step 6: Implementing Network Policy#

Now, let’s create a network policy that only allows the backend to access the db:

1
apiVersion: networking.k8s.io/v1
2
kind: NetworkPolicy
3
metadata:
4
  name: db-access-policy
5
spec:
6
  podSelector:
7
    matchLabels:
8
      app: db
9
  policyTypes:
10
    - Ingress
11
  ingress:
12
    - from:
13
        - podSelector:
14
            matchLabels:
15
              app: backend
16
      ports:
17
        - protocol: TCP
18
          port: 3306

Save this as network-policy.yaml and apply:

1
kubectl apply -f network-policy.yaml

Key Takeaways#

CNI Flexibility: Kind allows us to disable the default CNI and use alternatives like Calico.
Fine-grained Control: Network policies enable precise control over pod-to-pod communication.
Label-based Selectors: Network policies use labels to select pods, making them flexible and powerful.
Default Deny: Without explicit allow rules, network policies default to denying all traffic.
Testing is Crucial: Always test your network policies thoroughly to ensure desired behavior.

Conclusion#

Kubernetes Network Policies provide a powerful tool for securing your cluster’s internal communications. By following this guide, you’ve set up a Kind cluster with Calico, deployed applications, and implemented a basic network policy. This foundation will allow you to create more complex policies tailored to your specific security needs.

Remember, network security is an ongoing process. Regularly review and update your policies as your application architecture evolves.

This blog post template provides a comprehensive, hands-on guide to implementing Kubernetes Network Policies, based on the task you described. It includes step-by-step instructions, explanations of key concepts, and important takeaways. The content is structured to be both informative and practical, suitable for readers who want to understand and implement Network Policies in their Kubernetes environments.

Newsletter