Imagine a busy city where every single house has its doors wide open, and anyone can walk into any room without an invitation. In the world of information technology, this is exactly how a Kubernetes cluster behaves by default. While this makes it easy for applications to talk to each other, it is a significant security risk. Today, we will learn how to build “digital fences” to keep our applications safe.
When you first set up a Kubernetes cluster, it operates on what we call a “flat network model.” This means that every Pod gets its own unique IP address and can communicate with every other Pod in the cluster without any restrictions. There are no firewalls or Network Address Translation (NAT) devices standing in the way. While this is great for testing, in a real-world scenario, you want your database to talk only to your backend, and your backend to talk only to your frontend. To achieve this level of control, we use a technical tool called Network Policies.
A Network Policy is essentially a pod-level firewall. It allows us to define rules for two types of traffic: Ingress (incoming traffic) and Egress (outgoing traffic). However, there is a very important rule you must remember: Network Policies are implemented by the network plugin (like Calico or Cilium), not by Kubernetes itself. If your cluster doesn’t have a network plugin that supports these policies, your rules will simply be ignored.
To begin our technical walkthrough, we must first create an isolated environment. We use the command kubectl create namespace netpol-lab to ensure our experiments do not interfere with other parts of the cluster. Within this namespace, we might deploy three different Pods: a client, a frontend, and a backend.
The most secure way to start is with a “Zero Trust” approach. We create a YAML file for a Default Deny policy. This policy tells the cluster to block every single connection attempt. In the YAML structure, we use a podSelector: {} with empty braces, which signifies that the policy applies to every Pod in that namespace. Once you apply this using kubectl apply -f default-deny.yaml, your applications will become completely isolated. They won’t be able to talk to each other, access the internet, or even resolve names using DNS.
Now that everything is locked down, we must selectively open the “doors” we need. Suppose we want our client Pod to talk to the frontend Pod. We create a new policy where the podSelector matches the label app: frontend. Inside the ingress section, we specify that traffic is allowed only from pods with the label app: client. We also specify the technical port, which is usually port: 80 for web traffic using the TCP protocol.
A common mistake beginners make is forgetting about Egress traffic. Even if you allow the frontend to receive traffic from the client (Ingress), the client must also be allowed to send that traffic (Egress). If the client’s outgoing traffic is blocked by a global deny rule, the connection will fail. This is why we often need to create explicit Egress policies.
Furthermore, applications almost always need to use DNS to find other services. In Kubernetes, DNS typically runs on UDP and TCP port 53. If you don’t create a policy that allows Egress traffic to the kube-system namespace on port 53, your Pods will be “blind” and won’t be able to find any other services by their names.
Lastly, there are times when a Pod needs to access the external internet, perhaps to download an update or connect to an outside API. In your Network Policy YAML, you can use the ipBlock field with a cidr of 0.0.0.0/0. This technical term represents the entire internet. By adding this to an Egress rule for a specific Pod, you allow it to go outside the cluster while keeping the rest of your internal network hidden and protected.
By mastering these configurations, you transition from being a casual user to a cluster administrator who understands the flow of data. Always start by blocking everything and then only open what is strictly necessary. This “least privilege” principle is the gold standard of cybersecurity. As you continue your journey, keep practicing with different YAML configurations in your lab environment to see how Ingress and Egress interact.
Your ability to secure a cluster depends on how well you understand Labels and Selectors. These are the “keys” that Network Policies use to identify which Pods to protect and which connections to trust. Once you are comfortable with these basics, you might explore more advanced concepts like using namespaceSelector to allow traffic between different sections of your cluster. Keep exploring, stay curious, and always verify your rules with connectivity tests!