Using Role-based Access Control (RBAC) to Tighten Kubernetes Security

In my most recent Kubernetes attack and defense webinar, I demonstrate a Kubernetes attack through a Scott Pilgrim-themed scenario. If you haven’t seen the Scott Pilgrim movie, definitely check it out!

The attacks in my webinar demonstrate defeating the “evil ex” bad guys of the movie as you escalate privilege through a Linux-based Kubernetes cluster. In one step, we gain a password through a monkey-in-the-middle (MitM) attack, where we intercept a communication between two containers in the cluster. It’s much easier than it sounds!

There are a number of defenses we discuss in the webinar. The most widely applicable is Kubernetes’ primary authorization rules language, called role-based access control (RBAC). RBAC is pretty easy to learn.

You use RBAC to help implement least privilege by defining what accounts (user accounts or service accounts) can perform what actions to what resources. You’d expect this would mean that we create a number of rule objects, like so:

User Jay may list pods

User Mary may list pods

User Alice may get, list, watch, create, update, patch, delete pods

To ease handling a large number of accounts, RBAC uses a sort of intermediate item called a binding. You create “roles,” which have a set of capabilities, then give each user one or more roles via a “rolebinding.” That last example would use a pair of custom roles:

Role pod-lister may list pods

Role pod-rw may get, list, watch, create, update, patch, delete pods

Then you create rolebindings, giving Jay and Mary the pod-lister role, while you give Alice the pod-rw role, like so:

User Jay has role pod-lister

User Mary has role pod-lister

User Alice has role pod-rw

Once this makes sense to you, you only need to grasp one additional concept. Kubernetes ties all of these to “namespaces,” an organizational unit that is customarily used to separate development teams or projects from one another in a cluster. So, you create these roles (sets of actions) and rolebindings (grants of roles to users) in one namespace at a time. For a rare set of cases where you need the capabilities to affect the entire cluster, not just one namespace, you can create “cluster roles” and “cluster rolebindings.”

But wait, you say, isn’t this all supposed to be expressed in YAML? (Footnote: YAML stands for “YAML Ain’t Markup Language). Yes, it is, but it’s quite a bit easier to understand the YAML when you know what it’s supposed to be doing.

Here’s the YAML version of “Role pod-lister may list pods”:

apiVersion: rbac.authorization.k8s.io/v1

kind: Role

metadata:

name: pod-lister

rules:

- apiGroups: [""]

verbs: ["list"]

resources: ["pods"]

Here’s the YAML version of “User Jay has role pod-lister”

kind: RoleBinding

apiVersion: rbac.authorization.k8s.io/v1

metadata:

name: user-jay-has-role-pod-lister

subjects:

- kind: User

name: jay

apiGroup: ""

roleRef:

kind: Role

name: pod-lister

apiGroup: ""

There’s a lot more you can learn about how to effectively and efficiently leverage RBAC, but what you’ve learned in this blog post is enough for you to defend the Kubernetes cluster we attack in my on-demand webinar. Follow along here: Attacking and Defending Kubernetes Scott Pilgrim–Style.