RBAC and PSPs Can Only Bring Your Kubernetes Security So Far

More and more organizations are adopting the Kubernetes container orchestration platform. As reported by Container Journal, a 2020 survey found that Kubernetes use grew to 48% of respondents in 2020—up from 27% two years earlier. This finding reflects how Kubernetes benefits those organizations that are looking to manage their containers in order to ensure there is no downtime.

For instance, Kubernetes uses load balancing to distribute container network traffic and ensure the deployment remains stable. The platform also enables admins to designate a desired state for their deployed containers, at which point Kubernetes will automatically change those containers’ actual state to the desired state at a controlled rate. Finally, Kubernetes’ documentation specifies how the platform is capable of killing and replacing containers that don’t respond to user-defined health checks.

The problem? Organizations that are adopting Kubernetes are experiencing plenty of security challenges along the way. In its “State of Container and Kubernetes Security - Fall 2020” report, for instance, StackRox found that 90% of survey respondents had experienced a security incident in their Kubernetes and container environments over the previous 12 months. Two-thirds of those respondents said that they had weathered a misconfiguration incident. This was followed by a major vulnerability incident (22%), a runtime incident (17%), and a failed audit (16%).

RBAC and PSPs as Limited Fixes

The findings above highlight the need for admins to help defend their organizations against a security incident. One of the ways they can do this is by using Role-Based Access Control (RBAC) as a way to restrict what can run in the cluster. According to Kubernetes’ website, RBAC enables admins to regulate access to an organization’s Kubernetes environment through the declaration of four objects. These are as follows:

• Role: This Kubernetes object creates a set of permissions within a specified namespace.
• ClusterRole: Like a Role, a ClusterRole defines permissions, but it enables admins to do so on non-namespaced resources. Admins can thereby use this object to assign the same permissions across individual namespaces, all namespaces or cluster-scoped resources.
• RoleBinding: This Kubernetes object takes the permissions defined within a Role and assigns them to a user or a set of users within a specific namespace.
• ClusterRoleBinding: Admins can use a ClusterRoleBinding to grant a user or a set of users the same level of permissions cluster-wide.

That being said, RBAC can take organizations’ Kubernetes security only so far. StackRox elaborated on the reason why in a blog post:

"While RBAC controls are a critical part of Kubernetes security, they do not provide the ability to control the settings, content, or configuration of cluster objects. For example, you may want to allow users in a database group to create and edit deployments in the database namespace, but any pod containers in that namespace should not run as the root user. You may also have a requirement that all resource objects in your cluster have a specific set of labels."

Some admins are turning to Pod Security Policies (PSPs) in response to specifically prevent their pod containers from running as root. These objects enforce a security context, which defines privilege and access control settings for a pod and container, in order to control what pods can be accepted into a system. They come in one of the following three varieties:

1. Privileged: This is an unrestricted PSP that allows for privilege escalations.
2. Baseline/Default: This type of PSP has some restrictions while still allowing for privilege escalations.
3. Restricted: This is the most heavily restricted PSP; it follows pod hardening best practices and does not allow for privilege escalations.

But PSPs aren’t airtight in their security functionality, either. Amazon noted in a blog post that PSPs are cumbersome to work with. They also don’t cover all security concerns such as defining resource limits for pods or ensuring that images come from a trusted registry. It’s therefore not surprising to hear industry chatter from TechTarget that PSPs, a beta feature that never made it to General Availability, could be deprecated as early as sometime in 2021.

Where That Leaves Organizations

Admins would be better off looking to something in addition to RBAC and other than PSPs to limit access to the cluster. In particular, they might want to consider looking into Open Policy Agent (OPA) Gatekeeper. A customizable admission webhook for Kubernetes, Gatekeeper lets admins specify configurations for customizing admission control and bring awareness to the state of their cluster. In doing so, it enables admins to limit the types of container registries from which images can be pulled, can define resource limits for pods and can perform other security functions that are beyond the scope of PSPs.

Admins can learn more about how they can use Gatekeeper to advance their organizations’ Kubernetes security by reading up about the project on GitHub. They can also learn more about Kubernetes security in general from kubernetes.io.