TechOps Examples

Hey — It's Govardhana MK 👋

Welcome to another technical edition.

Every Tuesday – You’ll receive a free edition with a byte-size use case, remote job opportunities, top news, tools, and articles.

Every Thursday and Saturday – You’ll receive a special edition with a deep dive use case, remote job opportunities, and articles.

Customer expectations keep rising. Support budgets don't. On July 9, Fin and AWS are hosting a live executive session on how leading enterprises close that gap: scaling AI-powered support while simplifying how they buy it.

You'll see how to resolve an average 76% of conversations with Fin on AWS enterprise-grade infrastructure, procure through AWS Marketplace to put committed cloud spend to work, and turn the Fin and AWS collaboration into lower support costs. Register for the live session to see how.

Save your spot

Powered by: Jobsurface.com

Browse 599 Worldwide Jobs Here →

Looking to promote your company, product, service, or event to 49,000+ Cloud Native Professionals? Let's work together. Advertise With Us

By default, every pod in a Kubernetes cluster can send traffic to every other pod. There are no network level restrictions. A compromised pod in one namespace can freely connect to a database pod in another. A frontend pod can reach internal admin services it has no business accessing. Kubernetes does not impose any traffic rules between pods unless you explicitly create them.

Network Policies are the Kubernetes mechanism let you define rules about which pods can talk to which other pods, on which ports, and in which direction. Think of them as a virtual firewall placed in front of each pod, evaluating every packet before it is allowed through.

Each pod in a Kubernetes cluster connects to a shared pod network. Traffic between pods flows through this network, and without any policies in place, everything is permitted in both directions. A Network Policy changes this by placing a firewall in front of the pod, one on the sending side and one on the receiving side, that evaluates traffic against defined rules before allowing it through.

Note: They do not inspect application layer content, authenticate callers, or replace RBAC.

Kubernetes defines the NetworkPolicy API, but it does not enforce it. The API lets you create NetworkPolicy objects, validate them, and store them. The actual enforcement is done by the CNI plugin running on each node. This is a critical distinction. If you create a NetworkPolicy in a cluster that is running a CNI plugin without policy support, the policy will be accepted and stored but will have no effect on actual traffic.

The NetworkPolicy object is handed off to the CNI plugin, which programs the firewalls on the nodes where the affected pods are running. The plugin reads the policy rules and translates them into the underlying network rules, whether that is iptables, eBPF, or another mechanism that actually control packet flow. Calico, Canal, Cilium, and Weave all support NetworkPolicy enforcement. Flannel alone does not.

A NetworkPolicy selects pods using label selectors and defines ingress and egress rules for those pods. When a pod has at least one NetworkPolicy selecting it, Kubernetes switches it from the default allow-all posture to a default deny posture for the directions covered by the policy. Any traffic not explicitly permitted by a matching rule is dropped.

A common production pattern is to block all external internet traffic at the cluster level and then use namespace scoped policies to control which pods within the cluster can communicate with which.

In the example above, a cluster level NetworkPolicy blocks all inbound internet traffic. A second policy scoped to the backend namespace allows traffic from the frontend namespace to reach app 1, while explicitly denying access to app 2. The frontend pod can reach app 1 directly. Any attempt by the frontend pod to reach app 2 is dropped by the namespace scoped policy.

The podSelector in a NetworkPolicy uses label matching to select which pods the policy applies to. An empty podSelector matches all pods in the namespace, which is how you create a namespace-wide default deny. A namespaceSelector allows you to write rules that permit traffic from an entire namespace rather than from specific pods, which is how the frontend to backend policy above is written.

🔴 Get my DevOps & Kubernetes ebooks! (free for Premium Club and Personal Tier newsletter subscribers)