Kubernetes Network Policies Proof of Concept

The first pod dropped, and traffic moved freely—too freely. Within seconds, every service could talk to every other. That’s default Kubernetes networking. Powerful, but dangerous.

Kubernetes Network Policies give you control. They define which pods can talk and on which ports. Without them, an internal compromise can spread fast. With them, you reduce the blast radius and enforce least privilege communication.

A Network Policy is a Kubernetes resource. It uses namespace and label selectors to match pods, and it defines ingress and egress rules. By default, Kubernetes allows all traffic between pods. Once any Network Policy selects a pod, traffic is denied unless explicitly allowed. This makes the first policy you apply an important proof of concept.

To create a Kubernetes Network Policies proof of concept, follow a minimal path:

1. Choose a namespace for testing.
2. Deploy two pods—one as the “secure” service, one as a “client.” Label them clearly.
3. Confirm connectivity with kubectl exec and curl or nc.
4. Write a NetworkPolicy manifest that allows only traffic from the client pod label to the secure pod label over a chosen port.
5. Apply the policy and retest connectivity.
6. Observe the block by trying to connect from a pod without the allowed label.

YAML example:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
 name: allow-client-to-secure
 namespace: test-ns
spec:
 podSelector:
 matchLabels:
 app: secure
 policyTypes:
 - Ingress
 ingress:
 - from:
 - podSelector:
 matchLabels:
 role: client
 ports:
 - protocol: TCP
 port: 8080

This defines a clear, auditable rule. The secure pod now accepts only TCP connections on port 8080 from pods labeled role=client in the same namespace. Everything else is denied.

Scaling the proof of concept means adding more policies, more namespaces, and explicit egress rules. Test each step. Keep manifests in version control. Apply them through GitOps for predictable rollouts.

Network policies are not retroactive magic. If your cluster CNI plugin doesn’t support them, they do nothing. Check compatibility first. Then apply your initial policy in a controlled namespace before extending to production.

A tight proof of concept shows stakeholders the security value fast. It builds confidence, prevents over-permissive defaults, and sets the stage for a cluster-wide policy rollout.

See a live Kubernetes Network Policies proof of concept in minutes—try it now at hoop.dev.