This blog was written by an independent guest blogger.
Organizations are increasingly adopting Kubernetes to manage their containerized workloads and services, but Kubernetes security incidents are on the rise, as well. In the fall 2020 edition of the “State of Container and Kubernetes Security” report, for instance, 91% of respondents told StackRox that they had recently adopted Kubernetes. Three quarters of survey participants went on to reveal that they had deployed the container orchestration platform in their production environments. Even so, nine out of 10 respondents told the company that their organizations had suffered a security incident in their container and Kubernetes environments over the last 12 months. Subsequently, nearly half (44%) of respondents said that they had delayed moving an application into production due to their security concerns.
These findings highlight the need for organizations to strengthen their Kubernetes security. They can do this by focusing on the security of their pods. StackRox explains why in a blog post:
Securing pods, and the containers that run as part of them, is a critical aspect of protecting your Kubernetes environments. Among other reasons, pods and containers are the individual units of compute that are ultimately subject to adversarial techniques that may be used as part of any attack on your Kubernetes clusters. Since pods are also the smallest resource you can deploy and manage in Kubernetes, applying security at this level ensures greater fine-grained controls that are scoped to individual application components.
Organizations can specifically use Pod Security Policies (PSPs) to strengthen their pod security. Before that even happens, they need to figure out what they want to define within those PSPs. That’s where security context comes into play.
What are security contexts?
According to Kubernetes’ documentation, security contexts define the privileges and access control settings for a selected pod or container. These settings include Linux Capabilities through which users can specify whether to give a process some privileges but not those of a root user. They also include AllowPrivilegeEscalation, or controls through which users can make a process more privileged than its parent process.
To set up security contexts, users need to have a Kubernetes cluster and the kubectl command-line tool configured to communicate with that cluster. They can then include the “securityContext” field in the specification for their pod or container. This action applies whatever security settings they want to their selected resource.
Moving on with Pod Security Policies
Once they know the security context, organizations can create a Pod Security Policy. Kubernetes notes elsewhere on its website that a PSP functions as a cluster-level resource that defines the security conditions under which a pod is allowed to run. Such a policy encapsulates and enforces one or more security contexts chosen by the user.
Along the way, users can choose to create three different types of PSPs. These are as follows:
- Privileged: Privileged PSPs are unrestricted in the sense that they don’t contain restrictions. As such, they are best conceived of as the absence of constraints rather than their own standalone policies. These types of PSPs work best for privileged users who are managing system- and infrastructure-level workloads.
- Baseline/Default: These types of PSPs are a bit more restricted than privileged policies in that they don’t allow for privilege escalation. Overall, they serve application operators and developers of non-critical applications.
- Restricted: Out of the three kinds of PSPs, restricted policies are the most limited. They enforce pod hardening best practices and sacrifice some compatibility in the process. These types of policies are best suited to operators and developers who are charged with managing security-critical apps as well as to lower-trust users.
To set up a PSP on one of their existing clusters, users first and foremost need to add the policies and authorize the pod’s service account to use a specific policy. They can do this by allowing the “use” verb on the PSP. Next, they can enable the admission controller, a feature which determines whether a pod should be able to run based upon the existing security contexts and active Pod Security Policies.
Kubernetes security more broadly
Using security context and PSPs can help organizations to minimize the occurrence of a security incident in their Kubernetes environments. But Kubernetes security doesn’t end there. With regard to pods specifically, organizations can’t just stop at controlling the conditions under which a pod is allowed to run. They also need to set restrictions that govern the ways in which pods can communicate with one another so as to limit the possibility of attackers moving laterally across the environment. Organizations also need to look beyond pods and use proper security configurations to harden not only their build, deploy and runtime phases of development but also the architecture of the container orchestration platform itself.
Organizations can learn more about how to secure their Kubernetes environments by viewing the solution’s documentation here.
