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.
