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 the requirements of your business are met, and see if the running RBAC objects need to be checked whether they perform their functions.

Our script

A certain organization accepts several groups to work with the new Kubernetes cluster. There is a requirement: you cannot interfere with 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 check showed that the groups could not see the pods of each other in their 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. Good thing the CLI tool Cubernethes kubectl gives you a set of tools to check your RBAC configuration. kubectl auth can-i

Can I? ("may I?")
can-i using the API just checks if it is possible to perform some action. The parameters it uses are as follows: kubectl auth can-i VERB [TYPE | TYPE/NAME | NONRESOURCEURL] kubectl auth can-i VERB [TYPE | TYPE/NAME | NONRESOURCEURL] 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 the --as= and --as-group= tags.

Update the command, use the imitation of another user:

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

We should see that with exit code 1 , the answer is “no”.

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 rules of RBAC, allowing the user from the group to change the number of running podov in the 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 } 

The --as and --as-group require 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!