Check RBAC at Kubernetes

It's one thing to secure the Kubernetes cluster, but to support the protection is another problem. However, new tools have been added to Kubernetes: now it is much easier to do both.

In Kubernetes (since version 1.6), we introduced the role-based access control concept (RBAC), which allows administrators to define restriction policies for cluster users. That is, you create a user with limited access: you limit the user's access to resources like secrets or to certain namespaces.

In this post we will not understand how to implement RBAC. Decent sources, where this topic is dismantled completely, suffice:

• https://medium.com/containerum/configuring-permissions-in-kubernetes-with-rbac-a456a9717d5d
• https://www.cncf.io/blog/2018/08/01/demystifying-rbac-in-kubernetes/
• https://docs.bitnami.com/kubernetes/how-to/configure-rbac-in-your-kubernetes-cluster/
• https://kubernetes.io/docs/reference/access-authn-authz/rbac/

It is better to focus on how to make sure that your business requirements are met, and see if the running RBAC objects need to be checked: do they perform their functions?

Our script

A certain organization accepts several groups to work with the new Kubernetes cluster. There is a requirement: you can not intervene in the deployment of a neighboring group, so that unforeseen intergroup problems or downtime do not happen.

And now the cluster owner has deployed an RBAC cluster, thereby limiting access to a particular namespace. The first test showed that groups can not view the pods of each other in namespaces.

A week has passed. The cluster owner noticed that a user from an isolated namespace reads secrets from another namespace. How so? He applied RBAC!

Apply something applied, but, as in the work with the code, the system must be tested for compliance with the desired result. It’s good that the CLI tool Couberntes kubectlgives you a set of tools to check your RBAC configuration.kubectl auth can-i

Can I? ("Can I
can-iget it?") With the help of the API, it just checks if it is possible to perform some kind of action. He uses the following parameters: kubectl auth can-i VERB [TYPE | TYPE/NAME | NONRESOURCEURL]. Now the current user can check whether a certain action is available to him. Go:

kubectl auth can-i create pods

This should return a “yes” or “no” response with the appropriate exit code.

However, when trying to check the rights of another user, we will encounter a problem: the user under which we are authorized in the cluster is specified in the config file ./kube/config, and it is inconvenient to have separate configs for testing individual users. Fortunately, Kubernetes comes to the rescue again: he is able to imitate users with the help of tags --as=and --as-group=.

Update the command, use the imitation of another user:

kubectl auth can-i create pods --as=me

We should see that the exit code 1returns the “no” response.

And this is great, because we now have a set of commands that allow us to check whether a user or a group of users has access to any of the Kubernetes resources, from viewing the subtext to deleting secrets.

Automation

However, it is too early to stop: now we are able to implement a test sequence that describes the list of requirements, and run it as part of the CD conveyor. For the cause!

There is enough to choose from, there are enough languages ​​to implement: starting with Ava and Mocha in JavaScript and ending with Rspec. In this case, I implement a purely bash-evski test framework Bats .

Below is an example of running a test. He checks the work of the RBAC rules that allow a user from a group to change the number of running pods in a namespace. Executed if the attribute "executable" has been set. Or - using bats filename.

#!/usr/bin/env bats
@test "Team namespaces can scale deployments within their own namespace" {
    run kubectl auth can-i update deployments.apps --subresource="scale" --as-group="$group" --as="$user" -n $ns 
    [ "$status" -eq 0 ]
    [ "$output" == "yes" ]
  done
}

Commands --asand --as-grouprequire the use of the following RBAC rules:

rules:
- apiGroups:
  - authorization.k8s.io
  resources:
  - selfsubjectaccessreviews
  - selfsubjectrulesreviews
  verbs:
  - create

Here is a simple method for you how to implement validation of your RBAC rules in Kubernetes. By making it part of the Kubernetes pipeline, we will significantly strengthen the RBAC policy. The method is tested in practice: to catch changes that violate access policies, it turns out much faster!

Thanks for taking the time to read this post!