Phase 2: Containers & Orchestration

Kubernetes Network Policies

Intermediate ~3 min read
Think of it this way A friendly analogy. Read this if the technical version feels dense. Show Hide

Imagine you're in a super big, super busy library, full of different kinds of rooms. There's a quiet study zone, a lively group project area, a computer lab, and even a fun story time corner. Now, what if everyone in the entire library could just walk into any room and start talking to anyone else, about anything, at any volume? It would be a complete mess, right? Nobody would get anything done, and it might even feel a bit unsafe if someone noisy kept interrupting your quiet reading. In the world of computer programs, especially when many small programs work together like different parts of a big app, we have a similar problem. We don't want every program being able to "talk" to every other program all the time. It's just too much chatter and can lead to problems.

That's exactly why we have something called Kubernetes Network Policies. Think of them as the special rule book for our library. These rules are decided by the head librarian (which is you, the computer builder!). A rule might say: "People in the quiet study zone can only communicate with other people inside the quiet study zone, and only in whispers." Another rule could be: "People in the computer lab are allowed to send messages to the printer, but they are absolutely not allowed to talk to the kids in the story time corner." These rules clearly define who (which group of programs) can send messages to whom (another group of programs), and how (like on which specific topic or "door").

By setting up these rules, you make sure that each part of your computer system only "talks" to the parts it absolutely needs to. For instance, you could make a rule that says your program which handles people buying things online (let's call it the "shop checkout" program) can only talk to the "payment processing" program, and never to your "game high scores" program. This is super important for security. If, for some reason, the "game high scores" program gets a problem – maybe someone tries to mess with it – these rules stop that problem from instantly spreading to your super important "shop checkout" and "payment processing" programs. It's like if someone starts yelling loudly in the story time corner, the library rules make sure they don't bother the quiet study zone.

So, when you build computer systems with lots of different parts working together, using Network Policies means you can make sure each part only communicates exactly what it needs to, and nothing more. It keeps everything neat, organized, and much, much safer, just like a well-run library.

Kubernetes Network Policies are a critical security primitive that allow you to define how groups of pods are allowed to communicate with each other and with external network endpoints. Operating at Layer 3/4 (IP address and port level), they enable you to enforce the principle of "least privilege" within your cluster's network. Instead of having a flat network where any pod can talk to any other pod by default, Network Policies provide a declarative way to segment your application's network traffic, significantly reducing the attack surface and preventing unauthorized communication paths.

Practically, you define Network Policies as YAML manifest files. Each policy targets a specific set of pods using a podSelector in its spec. Once targeted, you then specify ingress (incoming) and/or egress (outgoing) rules. These rules can restrict traffic based on various criteria: source/destination pods (using podSelector or namespaceSelector), IP CIDR blocks (ipBlock), and specific ports and protocols. It's crucial to understand that Network Policies are opt-in; a pod is not restricted by a policy unless it is selected by that policy. If a pod is selected by a policy with policyTypes: Ingress, then all ingress traffic to that pod is denied by default unless explicitly allowed by a rule. The same applies to Egress.

Implementing Network Policies is fundamental for building secure, resilient Kubernetes deployments. They are invaluable for preventing lateral movement within your cluster in the event of a compromised pod, as an attacker would be confined to only what the compromised pod is explicitly allowed to communicate with. Furthermore, they are often a requirement for regulatory compliance (e.g., PCI DSS). For Network Policies to function, your Kubernetes cluster must be using a Container Network Interface (CNI) plugin that supports them, such as Calico, Cilium, or Weave Net. Without a supporting CNI, these policies will have no effect, highlighting the importance of proper infrastructure setup.

Key Takeaways

  • Kubernetes Network Policies enforce Layer 3/4 (IP/port) traffic rules between pods.
  • They are declarative YAML objects defining ingress (incoming) and egress (outgoing) rules.
  • Network Policies help implement the principle of least privilege for pod communication, reducing attack surface.
  • They are opt-in; a pod is unrestricted by default until selected by a Network Policy.
  • A CNI plugin (e.g., Calico, Cilium) that supports Network Policies is required for them to be enforced.

Code Example

yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: default
spec:
  # Apply this policy to pods labeled 'app: backend'
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
    - Ingress # This policy only defines ingress rules
  ingress:
    # Allow incoming traffic only from pods labeled 'app: frontend'
    - from:
        - podSelector:
            matchLabels:
              app: frontend
      # ...and only on TCP port 8080
      ports:
        - protocol: TCP
          port: 8080

How this code works

This Kubernetes NetworkPolicy defines crucial security rules for traffic flowing into a cluster's services. Its primary job is to ensure that only authorized services can communicate with specific backend components. Specifically, this policy dictates that pods labeled app: backend are the target of these rules, identified by the podSelector. The policyTypes: Ingress line explicitly states that this policy only governs incoming traffic to these backend pods, not traffic originating from them.

Within the ingress section, the policy specifies exactly what kind of incoming connections are permitted. The from rule uses a podSelector to allow traffic only from pods labeled app: frontend. This establishes a secure communication channel, ensuring only frontend services can reach the backend. Furthermore, the ports rule restricts this allowed traffic to protocol: TCP on port: 8080, preventing unauthorized access on other ports. A key point for beginners: once an Ingress NetworkPolicy is applied to a pod, all traffic not explicitly allowed by an ingress rule will be automatically blocked. This "default deny" behavior makes Network Policies a powerful security tool.

Related Articles

Hand-picked reads to go deeper on container security.

Back to DevOps Engineer Roadmap