Network Policies: Building a Zero Trust Fortress

By default, a Kubernetes cluster is a very trusting place. Any pod in the dev namespace can ping any pod in the production namespace. Your "experimental" AI agent can talk to your production database. While this makes development fast, it is a catastrophic security vulnerability in a real-world environment.

To secure your applications, you must move from "Allow All" to Zero Trust. In Kubernetes, we do this using Network Policies.

Think of a Network Policy as a firewall that sits around your pods. It defines exactly who is allowed to talk to them (Ingress) and who they are allowed to talk to (Egress). In this lesson, we will master the Network Policy Resource, learn to use Labels as security boundaries, and build a "Deny All" security posture that keeps your AI and data assets safe.

1. Why the Default is Dangerous

In a standard Kubernetes cluster, the network is "Open." If a hacker compromises your Next.js frontend pod (perhaps through a vulnerable NPM package), they can then "lateral" across the cluster to find your Postgres database or your AWS credentials stored in a secret.

With Network Policies, you can say: "The Database only accepts connections from the Backend API. Any other connection from any other pod—even inside the cluster—must be blocked."

2. Prerequisites: The CNI Support

Unlike Pods or Services, Network Policies are not handled by the core Kubernetes components. They are enforced by the CNI Plugin.

Flannel: Does NOT support Network Policies.
Calico / Cilium / Azure CNI / Antrea: FULL support for Network Policies.
AWS VPC CNI: Requires the "Amazon VPC Lattice" or a secondary policy engine like Calico.

Always verify that your CNI supports policies before you rely on them for security.

3. Defining a Network Policy

Network Policies use Selectors (Module 4.4) to decide which pods to protect.

Example: Isolating the Database

This policy says: "Only pods with the label app: backend can reach the database on port 5432."

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: database-policy
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: database # The TARGET we are protecting
  policyTypes:
  - Ingress # We are controlling incoming traffic
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: backend # The ONLY allowed source
    ports:
    - protocol: TCP
      port: 5432

4. Ingress vs. Egress

Ingress Rules: Control traffic coming into your pod. (Who can call me?)
Egress Rules: Control traffic leaving your pod. (Who can I call?)

Use Case for Egress:

If you are running an AI experiment that you don't fully trust, you can apply an Egress policy that says: "This pod is allowed to talk to the Internal DNS and the AI Backend, but it is BLOCKED from talking to the public internet." This prevents an AI agent from accidentally (or maliciously) "exfiltrating" data to an external server.

5. The "Default Deny" Strategy

The industry best practice is to start with a "Default Deny" policy for every namespace. This blocks all traffic by default. You then "Punch holes" in the firewall only for the specific connections you need.

The "Deny All" YAML:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
spec:
  podSelector: {} # Selects ALL pods in the namespace
  policyTypes:
  - Ingress
  - Egress
  # No 'ingress' or 'egress' fields means no traffic is allowed!

6. Visualizing the Managed Flow

graph TD
    User["Public Internet"] --> Ingress["Ingress Controller"]
    Ingress -- "Allowed" --> Frontend["Frontend Pod"]
    Frontend -- "Allowed" --> Backend["Backend Pod"]
    Backend -- "Allowed" --> DB["Database Pod"]
    
    Other["Unauthorized Pod"] -- "BLOCKED" --> DB
    Frontend -- "BLOCKED" --> DB
    
    style Other fill:#f99,stroke:#333
    style DB fill:#9f9,stroke:#333

7. Practical Example: Securing a Multi-Tier AI App

Let's say you have three tiers: UI, API, and Vector-DB.

UI Policy: Allows traffic from the Ingress Controller.
API Policy: Allows traffic ONLY from the UI.
Vector-DB Policy: Allows traffic ONLY from the API.

This creates a "Chain of Trust." Even if a hacker takes over the UI, they cannot reach the Vector-DB because they have to go through the API first, which acts as a secondary layer of validation.

8. AI Implementation: Protecting Training Data

When training AI models inside Kubernetes, security is paramount. Your training pods often need access to high-performance storage containing sensitive datasets.

By using Namespace-level Network Policies, you can ensure that your "Training Clusters" are completely isolated from your "Inference Clusters."

The training pods can talk to the data storage.
The inference pods can talk to the internet to serve users.
There is ZERO network connectivity between the two, preventing a production breach from ever touching your raw training data.

9. Summary and Key Takeaways

Zero Trust: Assume everything is hostile.
Default Open: K8s is open by default; you must explicitly close it.
Selectors: Use labels to define your firewall rules.
Ingress/Egress: Control what comes in and what goes out.
CNI Engine: Ensure your network plugin actually supports policies.

In the final lesson of this module, we will explore the internal "Phonebook" of the cluster: DNS resolution inside clusters.

10. SEO Metadata & Keywords

Focus Keywords: Kubernetes network policy tutorial, K8s default deny-all policy, securing microservices with network policies, ingress vs egress K8s, Kubernetes zero trust networking, Calico network policy examples.

Meta Description: Learn how to implement professional-grade security in your Kubernetes cluster. Master Network Policies to build firewall rules, isolate sensitive databases, and create a Zero Trust environment for your AI and web microservices.

Network policies and security