Intro

In this article, I am going to demonstrate how NetworkPolicy can affect traffics between pods on differento nodes, by creating NetworkPolicy, we can avoid some potential security risks.

I am going to:

• Create a deployment using busybox image with 2 replicas on 2 different nodes

• Create a NetworkPolicy which will block the traffic from node1 → node2

Demo

Definition of deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: busybox-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      app: busybox
  template:
    metadata:
      labels:
        app: busybox
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: kubernetes.io/hostname
                operator: In
                values:
                - kind-worker
                - kind-worker2
      containers:
      - name: busybox
        image: busybox
        command: ["sleep", "3600"]

Apply the deployment without NetworkPolicy (All traffic will pass)

So, I have a lot of pods currently, I will try to execute ping from busybox to another pod.

kubectl get pods -o wide
NAME                                  READY   STATUS             RESTARTS        AGE     IP           NODE                 NOMINATED NODE   READINESS GATES
busybox-deployment-5d9789f8c9-9ckzj   1/1     Running            0               3m50s   10.244.2.7   kind-worker2         <none>           <none>
busybox-deployment-5d9789f8c9-bft7v   1/1     Running            0               3m50s   10.244.1.9   kind-worker          <none>           <none>
container-error-demo                  0/1     ImagePullBackOff   0               17h     10.244.1.3   kind-worker          <none>           <none>
nginx-app-6979b75c7-k4xw9             1/1     Running            0               121m    10.244.1.6   kind-worker          <none>           <none>
nginx-deployment-86c57bc6b8-g45dq     1/1     Running            1 (6h18m ago)   28h     10.244.1.2   kind-worker          <none>           <none>
nginx-with-probes                     1/1     Running            1 (6h18m ago)   17h     10.244.2.2   kind-worker2         <none>           <none>
pending-pod                           0/1     Pending            0               18h     <none>       <none>               <none>           <none>
pod-sc-pv-pvc                         1/1     Running            8 (18m ago)     18h     10.244.0.4   kind-control-plane   <none>           <none>

As you can see, ping from busybox to nginx pod succeeded:

kubectl exec -it busybox-deployment-5d9789f8c9-bft7v -- ping -c 3 10.244.2.2
PING 10.244.2.2 (10.244.2.2): 56 data bytes
64 bytes from 10.244.2.2: seq=0 ttl=62 time=0.095 ms
64 bytes from 10.244.2.2: seq=1 ttl=62 time=0.255 ms
64 bytes from 10.244.2.2: seq=2 ttl=62 time=0.298 ms

--- 10.244.2.2 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.095/0.216/0.298 ms

Definition of NetworkPolicy

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-cross-node-communication
spec:
  podSelector:
    matchLabels:
      app: busybox
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
      - podSelector:
          matchLabels:
            app: this-app-does-not-exist # This will block ingress traffic to busybox
  egress:
    - to:
      - podSelector:
          matchLabels:
            app: this-app-does-not-exist # This will block egress traffic from busybox

Apply NetworkPolicy and see changes

kubectl get networkpolicies.networking.k8s.io
NAME                            POD-SELECTOR   AGE
deny-cross-node-communication   app=busybox    6s

Let’s ping again from busybox (100% packet loss is expected):

kubectl exec -it busybox-deployment-5d9789f8c9-bft7v -- ping -c 3 10.244.2.7
PING 10.244.2.7 (10.244.2.7): 56 data bytes

--- 10.244.2.7 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss
command terminated with exit code 1

The result is what we expected!

Conclusion

In conclusion, this demonstration provides a foundational example of how to deploy a Kubernetes application with specific node affinity and enforce strict network isolation using a Network Policy. By deploying busybox pods to designated nodes (kind-worker and kind-worker2) and applying a restrictive network policy, we've effectively prevented these pods from communicating with each other and with any other pods in the cluster.

This setup is particularly useful in scenarios requiring high levels of security where pods must be isolated to prevent potential breaches or leaks of sensitive data. The network policy we implemented acts as a blanket isolation tool, denying all inbound and outbound traffic to the pods, ensuring that they operate in a tightly controlled network environment. This approach demonstrates the flexibility and power of Kubernetes' scheduling and network policy features but also highlights the need for careful planning and understanding of label selectors and policy implications to avoid unintended network partitions.

Overall, this exercise is an excellent stepping stone for understanding more complex Kubernetes operations, including node-specific deployments, and advanced network policy configurations. It reinforces the importance of precise resource labeling and meticulous policy configuration in maintaining and securing multi-node Kubernetes applications.