Kubernetes Network Policies simplified

Ever been to a concert or event where there are different security checkpoints? Each section of the event might have guards that control who can come in and out. This is a lot like how Kubernetes Network Policies work in your cluster.

🔐 Imagine this:

You're organizing a concert, and you have different areas—VIP, backstage, and general admission. You wouldn't want everyone to roam freely everywhere, right? Each section needs rules for who can enter and who can’t.

In a Kubernetes cluster:

• Pods are like different areas of the event.

• Network Policies are like the security guards, controlling who (traffic) can enter or leave a specific Pod (section).

🎯 Without a network policy: It's like having no security at all. Everyone can go anywhere! 🎯 With a network policy: You specify which Pods can communicate with each other—just like how security guards allow only certain people into the VIP section.

K8s Diagram

K8s manifests

apiVersion: v1
kind: Service
metadata:
  name: vip-service
  namespace: concert
spec:
  selector:
    role: vip
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
---

apiVersion: v1
kind: Service
metadata:
  name: security-service
  namespace: concert
spec:
  selector:
    role: security
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
---

apiVersion: v1
kind: Service
metadata:
  name: backend-service
  namespace: concert
spec:
  selector:
    role: backend
  ports:
  - protocol: TCP
    port: 8080
    targetPort: 8080

Breakdown:

• This service routes traffic to the VIP Pod. If any other Pod (like security-pod) needs to reach the VIP, it can communicate via vip-service on port 80.

• The security-service provides an interface for other Pods to communicate with the Security Pods. Any traffic directed to the Security Pods goes through this service.

• The backend-service routes traffic to the Backend Pods. Any other Pod (like the vip-pod) that needs to communicate with the Backend will do so via this service.

apiVersion: v1
kind: Pod
metadata:
  name: vip-pod
  namespace: concert
  labels:
    role: vip
spec:
  containers:
  - name: vip-container
    image: nginx

---

apiVersion: v1
kind: Pod
metadata:
  name: security-pod
  namespace: concert
  labels:
    role: security
spec:
  containers:
  - name: security-container
    image: nginx

---

apiVersion: v1
kind: Pod
metadata:
  name: backend-pod
  namespace: concert
  labels:
    role: backend
spec:
  containers:
  - name: backend-container
    image: nginx

Breakdown:

• vip-pod: Represents the VIP area.

• security-pod: Acts as the security guard, controlling who can access the VIP area.

• backend-pod: The backend service that the VIPs can communicate with.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-vip-traffic
  namespace: concert
spec:
  podSelector:
    matchLabels:
      role: vip
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: security
    ports:
    - protocol: TCP
      port: 80
  egress:
  - to:
    - podSelector:
        matchLabels:
          role: backend
    ports:
    - protocol: TCP
      port: 8080

Breakdown:

• podSelector: Targets Pods labeled with role: vip, similar to securing access to a VIP area.

• Ingress: Only allows traffic from Pods labeled with role: security on port 80 (like guards checking entry).

• Egress: Allows traffic only to Pods with role: backend on port 8080 (VIP guests talking to the backend system).

Good to know!!

• Similar to AWS security groups, a NetworkPolicy is stateful and will allow an established connection to communicate both ways.

• By default, the podSelector only applies to pods within the same namespace as the network policy.