You did it! You set up a Kubernetes system to orchestrate your containers. This will help you support your customers with faster application development and management.
Let’s be clear, though. Your work doesn’t end there. If you really want to serve your customers, you need to make sure you’ve taken security into consideration. The last thing you want is for an attacker to exploit a security vulnerability and then move laterally throughout your network and follow up with stealing your or your customers’ sensitive information.
Fortunately, you can use a Kubernetes network policy to prevent that type of lateral movement. This blog post will begin by providing a definition of a Kubernetes network policy and by supplying some background information on what one does. After discussing the security shortcomings of a default Kubernetes network policy, this post will identify how you can use your custom settings to keep all your information safe.
What Is a Kubernetes Network Policy?
According to Kubernetes’ website, a network policy governs how pods (or groupings of containers, their storage resources and other components) can talk with one another.
Each network policy relies on pod labels and rules to govern this communication. In addition to its mandatory fields such as apiVersion, kind and metadata, a network policy uses its spec field to define the namespace that will be subject to a network policy. It also comes with the podSelector field for identifying to which pod groupings a network policy should apply.
Here are some other elements that form the basis of a traditional Kubernetes network policy:
- policyTypes – Specifies whether the network policy covers ingress traffic to a group of pods, egress traffic from a group of pods or both ingress and egress traffic.
- ingress – Whitelists rules for ingress traffic based upon its from and port fields.
- egress – Whitelists rules for egress traffic based upon its to and port fields.
- The ingress from and egress to fields also have their own selectors. These include podSelector and namespaceSelector.
So, What’s the Problem?
The issue with Kubernetes network policies is that these designs’ default configurations do not provide an adequate level of security for your Kubernetes environment. These shortcomings manifest in one key area: pod-to-pod communication.
Pod-to-Pod Communication
Network policies by default assume that all pods located within your environment want to communicate with one another, so they don’t limit any of this communication. Indeed, Kubernetes’ documentation reveals that pods’ default settings are non-isolated, meaning that all traffic is accepted from any source. The only way you can isolate a pod is to therefore create a network policy that rejects certain connections in a namespace. By selecting a particular pod in that namespace, you can limit the types of connections to which that pod is open. (If you don’t select other pods within that same namespace, however, they will be exempt from the network policy and will therefore continue to accept all traffic.)
What are the risks involved, you might ask? Think about it. If a malicious actor manages to compromise just one of your pods, they can gain the ability to communicate with all of your pods. They can abuse these privileges to then move laterally throughout the network, infect assets with malware and/or steal sensitive data.
How You Can Amp up the Security of Your Kubernetes
Fortunately, you can improve the security of your Kubernetes network policy using various best practices. First, you should settle upon what types of traffic should be flowing to and from each pod. You can then use different rules to create a network map that enforces this design and limits the exposure of your most sensitive pods.
Second, you should consider using a pod security policy. This resource controls the sensitive aspects of pod specification for the purpose of controlling privileges and other properties. Just remember that you need to implement pod security policy as a control by enabling the admission controller. You’ll also want to authorize policies, as a failure to do so will prevent any pods from spawning in the cluster.
Last but not least, exercise diligent secrets management. A major part of this is restricting the use of “watch” and “list” requests, powerful commands that enable you to inspect all secrets’ values within a namespace. You should limit these commands to only the most privileged components in your environments.
- 4 Things to Know About API Security - October 22, 2021
- Visibility: The Key to Analyzing and Detecting Threats in Your Kubernetes - April 28, 2021
- How RHCOS Can Help You Secure Your Cluster’s Node Images - March 28, 2021
