Skip to main content
In this hands-on guide, you’ll learn how to secure pod-to-pod communication in Kubernetes using NetworkPolicies. We’ll start with a clean cluster—no workloads, services, or policies—and progressively:
  1. Deploy two NGINX apps (app1 & app2)
  2. Verify default connectivity
  3. Enforce a default-deny posture
  4. Open selective ingress/egress rules
  5. Test DNS resolution and direct IP connectivity

Ensure you have a running Kubernetes cluster (v1.8+) with a CNI plugin that supports NetworkPolicies (e.g., Calico, Cilium).

1. Deploying Two Sample Applications

We’ll create two deployments and expose each via a ClusterIP service.

1.1 app1 Deployment & Service (app1.deploy.yaml)

1.2 app2 Deployment & Service (app2.deploy.yaml)

Apply both manifests and confirm pods are running:
Expected output:

2. Verifying Basic Connectivity

By default, all pods can talk to each other. From inside app1, curl the app2 service:
You should see the NGINX welcome page:
Repeat from app2 to app1 to confirm bi-directional access.

3. Applying a Default-Deny NetworkPolicy

Now enforce a zero-trust posture by blocking all ingress and egress in the default namespace.
Output:
This policy blocks all traffic, including DNS queries. Pods will no longer resolve service names or reach cluster DNS.
Test connectivity failure:

4. Allowing Traffic Between app1 and app2

We’ll create two policies to selectively permit pod-to-pod and DNS traffic.

4.1 allow-app1 (allow-app1.networkpolicy.yaml)

4.2 allow-app2 (allow-app2.networkpolicy.yaml)

Apply both policies:

5. Testing Connectivity with NetworkPolicies

  1. Direct IP
  2. Service Name (DNS)


By following this tutorial, you’ve implemented a default-deny network posture and selectively opened up pod-to-pod and DNS traffic between app1 and app2. This approach helps you secure microservices communication with fine-grained policies.

Watch Video

Practice Lab