Organizations are bringing a variety of new technologies into their IT infrastructure as they continue to undergo their digital transformations. Many are embracing containers and Kubernetes, in particular. In a 2020 report, for instance, 56% of surveyed organizations expected their use of containers to increase within the next 12 months, wrote The Enterprisers Project. Another survey referenced in the same report found that more than three quarters (78%) of participating organizations were using Kubernetes in some form or another.

These findings raise the following question: why are so many organizations using containers and Kubernetes? To answer that question, it’s imperative that you first understand what containers and Kubernetes are. A crucial part of the equation is having a familiarity with the benefits that containers and Kubernetes offer to organizations.

Containers

Kubernetes defines a container image as a “ready-to-run software package, containing everything needed to run an application: the code and any runtime it requires, application and system libraries, and default values for any essential settings.” In consisting of an application and all of its dependencies, a container image is standalone. That means it’ll produce the same behavior on whichever machine it runs regardless of that machine’s underlying host OS or infrastructure.

Portability isn’t the only benefit afforded by containers, either. As noted elsewhere by Kubernetes, containers enable organizations to split their applications into smaller portions and dynamically deploy/manage those individual parts. Such functionality lets developers quickly and easily release fixes and/or new functionality without taking down an entire application.

Kubernetes

Containers can’t continue to grow in number without eventually affecting the way that organizations do business. At some point, organizations will end up with too many containers for their administrators to manage manually. It’s at that point when organizations might consider going with a solution like Kubernetes.

An open-source container-orchestration platform, Kubernetes helps organizations to streamline the process of managing their containerized workloads and services. For instance, administrators can use Kubernetes to specify the desired state of their deployed containers by removing existing containers or even creating new ones. They can also automate the process of replacing containers that fail or killing others that don’t meet user-defined health checks, functionality which allows them to keep their apps and other container-supported services always running.

With New Technologies Come New Risks

Notwithstanding the benefits discussed above, many organizations are suffering security incidents with their container and Kubernetes deployments. The fall 2020 edition of the “State of Container and Kubernetes Security” reported that 90% of survey respondents had experienced a security incident in their container and Kubernetes environments over the last 12 months. On a related note, nearly half (44%) of respondents to that survey said that they had delayed moving applications into development as a result of security concerns.

Fortunately, there’s lots of things that organizations can do to secure their containers and Kubernetes deployments. This article will focus in on organizations’ use of two different types of policies: Network Policies and Pod Security Policies. It will then explain what each of these policies can do and how they can protect organizations accordingly.

Kubernetes Network Policies

Kubernetes explains elsewhere in its documentation that administrators can use Network Policies to specify how they’d like a specific pod, or a group of one or more containers that share network resources, to communicate with other pods and network entities. Typically, Network Policies consist of three identifiers: allowed pods, namespaces and IP blocks. Those identifiers allow administrators to enforce the Network Policy and thereby shape the traffic that’s going to and emanating from a selected pod or group of pods.

Administrators have cause to consider using Network Policies in a security context because of the way in which pods communicate by default. Left alone, these groups of containers are not isolated, meaning they accept traffic from any source. This means that a malicious actor could compromise a single pod and then use that pod’s default configuration to communicate with all other pods and containers in the Kubernetes environment. Subsequently, administrators can use Network Policies to restrict communication to and from a selected pod or group of pods.

There’s also a “nuclear option” available to administrators. Indeed, they can craft a “default-deny-all” Network Policy that effectively isolates all pods. This means that only those connections listed in other Kubernetes Network Policies are allowed.

StackRox wrote in 2019 about the rationale for embracing such a policy:

Without such a policy, it is very easy to run into a scenario where you delete a network policy, hoping to forbid the connections listed in it, but find that the result is that all connections to some pods suddenly become permitted – including ones that weren’t allowed before. Such a scenario occurs when the network policy you deleted was the only one that applied to a particular pod, which means that the deletion of the network policy caused the pod to become “non-isolated”.

In crafting a “default-deny-all” rule, however, it’s important for administrators to remember that Network Policies are namespaced resources. Administrators will therefore need to create the same “default-deny-all” policy for each namespace within which they’d like to isolate their pods.

Pod Security Policies

Aside from managing the communication between pods, administrators also need to control who can access pods and their containers. This effort begins with using what’s known as security context. As explained by Kubernetes on its website, a security context specifies the privilege or access control settings for a selected pod or container. Examples of security contexts include discretionary access control, which limits the permission to access an object based on specific user IDs (UIDs) and group IDs (GIDs), as well as Linux Privileges, which allocates some privileges but not all the super rights that are available to a root user.

Kubernetes allows administrators to enforce their desired security contexts using Pod Security Policies (PSPs), which contain specifications for the conditions under which a pod is allowed to run within a system. Not all Pod Security Policies are created equal, however. These cluster-level resources come in the following three types:

• Privileged: Pod Security Policies have no restrictions. As such, these types of policies typically cover system- and infrastructure-level workloads that fall under the purview of privileged, trusted users. Administrators can enforce this type of policy by not applying any constraints rather than creating a specific policy.
• Baseline/Default: These types of Pod Security Policies are a little more restricted than privileged frameworks. While they aim to make it easy for administrators to help their organizations adopt common containerized workloads, baseline/default Pod Security Policies are designed to prevent known privilege escalations. Such rules therefore appeal to application operators and developers of non-critical applications.
• Restricted: By far the most restrictive category, restricted Pod Security Policies seek to harden pods against digital threats—even while sacrificing some compatibility. Restricted Pod Security Policies work best for operators and developers of apps that are critical to security. They also are optimal in cases where low-trust users are involved.

To use a Pod Security Policy, administrators need to create a policy with certain security contexts in mind. They then need to authorize the requesting user or target pod’s service account by allowing the “use” verb on the resulting Pod Security Policy. Otherwise, the rule won’t do anything. Finally, they can activate the policy by enabling the admission controller.

Pod Security Policies aren’t as widely used as they once were, though. StackRox wrote that this changing landscape boils down to certain shortcomings among Pod Security Policies:

As their name indicates, PSPs only apply to pods, making their coverage limited, and they also introduce complexity and overhead that must be managed for each deployment. PSPs are not nearly as flexible as other options such as OPA Gatekeeper, which provides a Kubernetes admission controller on top of the OPA policy engine to flexibly enforce policies on pods as well as other resource types. Some Kubernetes platforms, such as Azure Kubernetes Service (AKS), have opted to deprecate support for Pod Security Policies and instead implement policy enforcement using OPA Gatekeeper.

Per a post on Kubernetes’ blog, OPA Gatekeeper opens up the ability for users to leverage configurations and not code to customize admission control to pods and their respective containers. This resource also enables users to look beyond a single object under evaluation by gaining insight into the state of the entire cluster.

Just the Beginning of Security

This article provides a brief overview of how organizations can begin tackling security in their containers and Kubernetes environments. That being said, it doesn’t address security in its entirety. For instance, it doesn’t address how organizations can exercise caution when pulling images from other sources, and it doesn’t provide guidance on how administrators can scan those images for known weaknesses. The blog post also doesn’t get into how administrators can use configurations to effectively manage secrets within their Kubernetes and container environments.

For more recommendations on how administrators can secure their employers’ Kubernetes and containers, review Kubernetes’ security concepts here.

About the Author: David Bisson is an information security writer and security junkie. He’s a contributing editor to IBM’s Security Intelligence, Tripwire’s The State of Security Blog, and a contributing writer to Bora. He also regularly produces written content for Zix and a number of other companies in the digital security space.