On August 20, 2020, a provider of access management tools released an advisory detailing several misconfiguration issues that affected the kubelet. This feature of Kubernetes functions as the primary “node agent” running on each node. In order to support this functionality, the kubelet maintains full control over a pod running in a node.
As reported by the Container Journal, digital attackers could exploit the misconfigurations described in the advisory to gain access to the kubelet. Subsequently, they could conduct reconnaissance of a cluster, access a container’s app and move laterally in the cluster. This could give malicious actors all they need to gather more information about the pods and run commands within them for the purpose of compromising the Kubernetes environment and stealing sensitive data.
The Importance of Pod Security
The reality is that similar pod-related vulnerabilities and weaknesses will continue to come up. Acknowledging this reality, organizations need to focus on protecting their pods. StackRox couldn’t agree more with this observation:
A critical cornerstone of any Kubernetes security strategy is to secure the pods and containers that make up your clusters. The good news is that Kubernetes itself as well as its ecosystem make available multiple types of flexible capabilities and tools that enable you to protect pods in ways that range from applying general security best practices to meeting specific, fine-grained requirements based on workload type or other needs. Kubernetes security context and security policies, including Pod Security Policies, are the best way to get started and immediately increase the security of your Kubernetes applications.
This blog post will explain how organizations can use security contexts to keep their pods safe. It will then discuss how organizations can enforce those security contexts using three different types of pod security policies. Finally, the blog post will provide some insight into how organizations might look beyond pod security policies to address their pod security needs.
What Are Security Contexts?
Let’s begin by defining what a security context is. According to Kubernetes, a security context helps to define the security settings of a pod or container. For instance, administrators could use one security context called the “Discretionary Access Control” to meter access to a file based on user ID (UID) or group ID (GID).
There’s also the issue of privileges. Using security contexts, administrators can limit whether a pod or container can run as privileged or unprivileged. Not only that, but they can help to shape which privileges the object can achieve; the security context Linux Capabilities can help give some privileges to a process while avoiding the privileges of a root user, for example. And then there’s the security context “AllowPrivilegeEscalation,” which helps to control whether a process gain achieve more privileges than its parent process.
To enable a security context, administrators need to have a Kubernetes cluser and a kubectl command-line tool that’s configured to communicate with that cluster. They can then include the “securityContext” field in the pod specification or the container manifest to specify security settings for a desired pod or container.
Here Come Pod Security Policies
Pod Security Policies (PSPs) enter the fray when it comes time for administrators to enforce cluster requirements of security contexts. Per another section of Kubernetes’ documentation, these security policies act as cluster-level resources that define the conditions under which a pod must run in order to be accepted by the system. Those conditions include security contexts that are applicable to that pod.
Administrators can set up a PSP by first adding and authorizing policies to their existing clusters. They can do this by targeting the pod’s service account by allowing the “use” verb on the policy. At that point, admins can enable the admission controller. (PSP control is facilitated through this Kubernetes feature.
Along the way, administrators need to decide what type of Pod Security Policy they want to use. Kubernetes notes on its website that admins ultimately have three options: privileged, baseline/default and restricted.
- Privileged: These types of policies are unrestricted insofar as they allow for privilege escalation and a wide array of permissions. These policies are “purposely open,” explained by Kubernetes. In doing so, they target privileged users along with the system- or infrastructure-level workloads they help to manage.
- Baseline/Default: In contrast to privileged PSPs, baseline/default PSPs do have some restrictions. These limitations typically disallow privilege escalations. Even so, they aim to help those operating non-critical applications to adopt containerized workloads.
- Restricted: Not surprisingly, restricted PSPs are the most heavily limited Pod Security Policies. These types of policies seek to enforce pod hardening best practices. Generally, administrators use these types of policies for those responsible for operating security-critical applications as well as for lower-trust users.
A Caveat with Pod Security Policies
Notwithstanding the utility of PSPs, organizations have other options when it comes to hardening the security of their Kubernetes pods. These options include things like OPA Gatekeeper. To learn more about how else admins can harden their organizations’ pods against security threats, please review Kubernetes’ pod security standards here.
About the Author: David Bisson is an information security writer and security junkie. He's a contributing editor to IBM's Security Intelligence and Tripwire's The State of Security Blog, and he's a contributing writer for Bora. He also regularly produces written content for Zix and a number of other companies in the digital security space.