Kubernetes traffic control using network policies
A security audit is a fundamental step in every system, like your Kubernetes cluster. In a security audit, access to the cluster front-end could lead to an internal hack which is a big issue; however, it can be easily fixed.
How Network policies work
By default, all communication is allowed among applications in the Kubernetes cluster. There are no restrictions on which pods or services can talk to each other. The network policy component is the way to restrict that. It sets specific rules on who can talk to each other. Network policy is a network resource; it’s a native Kubernetes YAML file and configures the CNI application. I use weavnet as my Kubernetes plug-in, and it manages the network rules that enforce the network policies between pods and services in the cluster. Not all Kubernetes network plug-ins support network policies (a topic by itself for a post). For example, flannel does not keep that. So, the primary criteria for selecting the right CNI will be the network policy rule engine.
How to define Ingress network policy rules
We need to define which application communication we plan to restrict, and we do that by defining pod selector attributes. It takes a pod label as a value like MySQL that the network policy will apply to it to all MySQL pod replicas. If we leave the podSelector empty, the network policy will apply to all pods in the namespace. After you define who the rules are for, you need to explain what the rules are. We have two sets of rules, one for ingress traffic, meaning what traffic will be allowed to enter the pod, and the second is for outgoing egress, meaning what traffic is allowed to leave the pod. Let’s say we want to enable only backend pods to the MySQL pod, which means ingress from the back end to MySQL. It will be defined, as you can see below:
The next question you may ask is which port to use, as MySQL uses 3306 it must be configured as well. So now we have 2 network rules.
Let's make things more complicated, let's say we add PHP add that needs also access to the MySQL app but with the current network rule, there will be no access.
As you can see, a new rule is added to define the label PHP and set port 3306. As YAML can be tricky, paying attention to where each practice starts and ends is essential.
How to define Egress network policy rules
Let’s assume that the backend app now needs to talk with two apps, MySQL and Redis; we want to restrict the outgoing traffic to these two databases only and no other application in the cluster. As before, we need to define the posSelector that defines the backend using matchLabel. The epolicyTupes should be egress which is the list of rules that each starts with two attributes. To Ingress, where we define from where we allow the traffic to come in. With egress, we specify where it should go.
About namespaces, we assume they are in the same namespace, which is the default namespace where the network policy is created. But let’s say MySQL and Redis are in a different namespace called database, and to add more complexity, the backend application is another namespace called myapp. So how do the rules be changed? Remember that network policies will permanently reside in the namespace you want to enforce the laws, meaning they will live in the myapp namespace. As for the database’s namespace, we will have to use namespaceSelector and configure it in each rule.
You can combine egress and ingress rules in the same policy file, just make sure egress and ingress appear in the policyType.