Course contentsShow
← Docker, Kubernetes & CI/CD
Lesson 297 of 8024. Kubernetes Architecture and Core ObjectsFree lesson

Securing Inter-Namespace Communication with Network Policies

Learners will design and implement network policies to control traffic flow and restrict communication between pods residing in different namespaces.

In this lesson, you will learn how to use Kubernetes Network Policies to enforce security boundaries between pods, even when they reside in different namespaces.

The Default "Open" Network

By default, Kubernetes clusters are "flat" networks. This means any pod in your cluster can communicate with any other pod, regardless of which namespace they are in. While this is convenient for development, it poses a significant security risk in production. If a pod in your frontend namespace is compromised, an attacker could potentially scan and probe sensitive services residing in your database or internal-tools namespaces.

Controlling Traffic with Network Policies

A NetworkPolicy acts as a virtual firewall for your pods. It uses label selectors to define allowed traffic paths. When you want to restrict cross-namespace traffic, you don't just rely on the namespace boundaries; you define a policy that specifically permits or denies traffic based on namespace labels.

For example, to allow a frontend pod to talk to a backend pod, you can create a policy that selects the backend pods and explicitly permits traffic coming from pods with a specific label located in the frontend namespace:

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-frontend-to-backend
  namespace: backend
spec:
  podSelector:
    matchLabels:
      app: database
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          project: my-app
      podSelector:
        matchLabels:
          role: frontend

Why This Matters

Without these policies, your logical isolation (Namespaces) is merely organizational, not functional. By applying Network Policies, you transform your flat network into a "Zero Trust" environment. Even if an attacker gains access to one part of your cluster, they are blocked from moving laterally to other namespaces unless you have explicitly granted that access through a policy. This minimizes your blast radius and ensures that only authorized services can communicate.

Key Takeaway: Namespaces provide logical organization, but Network Policies provide the actual traffic enforcement necessary to secure communication between pods across your cluster.