This blog was written by an independent guest blogger.

Organizations are increasingly turning to Kubernetes, but they’re having trouble balancing security in the process. In its State of Container and Kubernetes Security Fall 2020 survey, for instance, StackRox found that 91% of respondents were using Kubernetes to orchestrate their containers and that three quarters of organizations were using the open-source container-orchestration system in production. Even so, nine in 10 respondents told StackRox in its poll that they had experienced a security event in their container and Kubernetes environment in the last 12 months. Two-thirds of organizations said those incidents had involved a misconfiguration.

These findings highlight the need for organizations to enhance the security of their Kubernetes environments against misconfiguration incidents. In this blog post, we’ll narrow our focus and discuss how one type of misconfiguration in particular—embracing default pod communication—endangers organizations’ security. We’ll then discuss how organizations can use either Pod Security Policies (PSPs) or OPA Gatekeeper to ensure the security of their pods.

Understanding the Security Challenges of Pod Communication

To understand the security challenges inherent in default Kubernetes pod communication, it’s important that we first define what a pod is and does.

Pods consist of one or more containers, shared storage/network resources and specifications for running those containers, according to the Kubernetes website. When framed in Docker terms, pods act as groups of Docker containers that share namespaces and filesystem volumes. These small computing units help organizations to group containers together and have these resources collaborate on specific projects or sets of work.

Where organizations run into challenges is the way in which pods communicate by default. As noted elsewhere on Kubernetes website, the standard configuration for pods is non-isolated in that they are capable of accepting traffic from any source. This is a problem, as this type of open communication potentially enables malicious actors to abuse the Kubernetes environment for nefarious purposes. Digital attackers could stage an attack in which they create a malicious container and use that to compromise its corresponding pod, for instance. That actor could then abuse unrestricted communication between pods to move laterally throughout the Kubernetes environment, deploying cryptominers and installing infostealing malware along the way.

Using Security Context to Address These Challenges

Fortunately, organizations can address these security challenges associated with pods using what are known as security contexts. Kubernetes notes on its site that security contexts function as configurations that help to define the security properties of a pod or a container. These configurations include access controls that govern who can access a pod or container and whether a Kubernetes resource is privileged. With the right security contexts, organizations can therefore prevent unauthorized actors from gaining access to a container, from elevating privileges on a compromised resource and from moving laterally on the network.

Enforcing Security Context with Pod Security Policies

When it comes time to enforce a security context, organizations may choose to use pod security policies (PSPs). These cluster-level resources manage the specifications under which a pod is allowed to run on a system, notes Kubernetes. Pod security policies empower administrators to monitor how the file system is used and which containers are privileged, among other things.

After creating a pod security policy, administrators should authorize the user or target pod’s service account to use the policy. (They can do this by allowing the “use” verb on the policy.) It’s then that they can enforce those policies by enabling the admission controller. (If the order is reversed and organizations enable the admission controller before authorizing a policy, they could inadvertently prevent pods from spawning inside the cluster.)

Addressing PSPs’ Limitations with OPA Gatekeeper

All that said, PSPs are not without their drawbacks. Amazon notes on its AWS blog that PSPs can sometimes be a bit cumbersome; it’s only the first policy listed in alphabetical order on Kubernetes’ Role-Based Access Control (RBAC) that applies, after all. More than that, PSPs don’t cover all security concerns that an organization might have, and they’re not user extensible. Not only that, but they’ve been in beta for some time; there’s no guarantee that they’ll make it to General Availability or that they’ll operate in the same way that they do now if they do.

Many organizations are responding to these shortcomings by opting for Open Policy Agent (OPA) Gatekeeper. The advantage here is that Gatekeeper functions as an admission controller webhook on top of an OPA engine. In essence, this design makes Gatekeeper portable in that administrators can use it to detect non-noncompliant commits before they slow down the organization. It will also ensure that any resource added to or updated on the cluster complies with the policies defined in the OPA engine, which is a general-purpose engine for defining and enforcing policies. Through those means, administrators can control where images come from, specify that pods have defined resource limits and essentially enforce anything they could with PSPs while having the ability to make custom policies for other specs, Amazon explained.

Automating This Process

Organizations can protect their pods using either PSPs or OPA Gatekeeper. But this isn’t always that easy. As noted by StackRox, “Hardening pods using native controls can, at times, get quite complex, especially when running clusters at scale.” That’s why organizations should consider not manually implementing these controls on their own. Instead, they should look for solutions that can help them to automate policy enforcement. This can save teams time, allowing them to uphold best security and compliance practices across their environment.