User RBAC on Kubernetes Simplified

A useful tool to get you going using minikube on Windows

Kubernetes supports the concept of user accounts and service accounts. In a nutshell, Role-Based Access Control (RBAC) is used to protect and control access to the Kubernetes API. Here how the accounts are broken down:

• user accounts are for humans (e.g. k8s admins) that need access to the Kubernetes API
• service accounts are for applications (e.g. pods) that need access to the Kubernetes API

As usual, here is a link to the official documentation: https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/

What we are going to do is provide a quick way to help you understand how RBAC works with users and a script to help simplify your life.

A simple use case

You have just hired your 1st Systems Engineer named “dar”, with another 2 new hires starting in a few weeks. You now need to enforce some basic security so that not everyone has keys to everything.

Step 1. Install OpenSSL and run scripts to make your life easier

Because we are working with both minikube on Windows and a Linux client, I will provide examples on how to use scripts for both versions. I don’t have access to MacOS right now or else I’d offer that too.

Both examples will require you to clone this repo:

https://github.com/airwavetechio/kubernetes-rbac

From your existing Kubernetes client, run this command because you will need the Kubernetes Master address in the next step.

kubectl cluster-info

For Windows

First, install openssl using chocolately

choco install openssl.light

Make sure you reboot after you install OpenSSL

After you reboot your computer, run this batch file to generate the proper user certificates and config files

kubernetes-rbac\k8s_usergen.bat <username> <group> https://SERVER_IP:PORT

For Linux

apt-get install openssl

Run this bash script to generate the proper user certificates and config files

./kubernetes-rbac/k8s_usergen.sh <username> <group> https://<SERVER_IP>:<PORT>

BOTH

You will end up with files in

./kubernetes-rbac/users/<username>/

WIndows file output

Linux file output

What just happened?

We had in our possession the Kubernetes .crt and .key files. In my example, I’m assuming those files are in C:\Users\Tony\.minikube (my default installation of minikube using Chocolately) but you can change that variable inside of the script to fit your env. We used those Kubernetes .crt and .key files to sign a new set of User .crt and .key files as shown above. The .crt and .key file are then used to create a config file. The kubectl config file is now ready for distribution, but hold off on that for now.

Step 2. Understanding Users, Groups, Role Bindings

We’ve just created a user’s cert and Kubernetes config on your local machine. Before we continue, we need to set up the test namespace airwave-rbac because when we apply the next few .yml files, they will need to be applied to this namespace.

kubectl apply -f namespace.json

We want to create a role called airwave-rbac-su-role that will allow only certain read-only privileges of resource pods for group “superusers”.

Excerpt from https://raw.githubusercontent.com/airwavetechio/kubernetes-rbac/master/rbac-user-rolebinding.yml

We need to apply the role and bindings to the Kubernetes cluster so that it knows that the group “superusers” has access.

kubectl apply -f rbac-user-rolebinding.yml

Service Account (User/Group) > Role Binding > Role

GROUPS

Taking a timeout out from the use case for a moment, I wanted to talk about Kubernetes RBAC Groups. I initially thought I could add a user to a group, and then bind a Role or a ClusterRole to that group. I was so wrong! Simply put, whatever rules/options you want to set, be sure those choices have a concept of Groups since Kubernetes doesn’t have a native user/group feature.

An easy example of this is for environments that use GKE/GCP. They use Google Groups (Beta) to manage Users > Groups and it just maps to that.

Role-based access control | Kubernetes Engine Documentation | Google Cloud

You can sort of mimic this behavior without being on GKE but you, the admin, must keep track of groups and permissions. There are some open-source utilities out there that help visualize RBAC in a more meaningful way, which I will cover in a future story, but it’s going to be on you. For now, this is how you can achieve groups.

When creating your CSR, you specify the Common Name and the Organizational Name. To brush up on OpenSSL parameters from a Kubernetes stand point:

CN = Common Name (e.g., username, user id) — A string, you define it.

O = Organizational Unit Name (e.g., group) — The group you add this user too, also a string. This will help so you won’t have to bind each user to a role, but rather once with a group.

In our example, we create a group called “supergroup” and since this is set up in the Role binding, we should be all good. As written earlier, you have to manage it.

Step 3. Configure your new client

This portion represents what Dar would do on her first day when setting up her machine. We are assuming Dar is running Ubuntu on her laptop. The config should also work on Windows, although I haven’t tested it. Shame on me.

Get the latest version of kubectl

Install and Set Up kubectl

Copy the kubectl config file that was generated earlier to your Linux host at ~/.kube/. The following screenshots show copying the config file from the Windows Host filesystem to the Linux Guest using the VMWare shared folders option. This shared folder isn’t available in Hyper-V (I tried).

You can see how getting pods works, but getting the namespaces doesn’t.

Test it out by running the commands

kubectl get pods

This works because I have already set the proper context for you. Try running a negative test.

kubectl get ns

What just happened?

Since you did most of the heavy lifting of creating the account, signing the certs, and then distributing the config file, all the new user has to do is install the kubectl binary and copy the config file to the proper location.

Testing Groups

If you want to test groups, create a new user, and try using the new config without having to apply any new roles or role bindings to Kubernetes.

Generate a new user “tony” that’s in the “superusers” group

Give the file to Tony so he can have access as

Step 4. ClusterRoles and ClusterRoleBindings

We are going to repeat Step2 but just change the files.

Let’s start with the negative test by trying to list the pods of the kube-system namespace.

kubectl get pods -n kube-system

This happens because we only applied Roles, which are at the namespace level.

To simplify this example, we are creating a new cluster role with the same pod permissions but we are binding the group “superusers” to the Cluster Role.

Excerpt from https://raw.githubusercontent.com/airwavetechio/kubernetes-rbac/master/rbac-user-clusterrolebinding.yml

kubectl apply -f rbac-user-clusterrolebinding.yml

Now trying again…

Now you can apply these permissions to pods across the cluster.

Step 5. Clean Up

Hopefully, you learned a few things about RBAC. I know I did while writing this, especially about how to use Groups.

Here are the instructions to clean up.

kubectl delete -f rbac-user-clusterrolebinding.yml
kubectl delete -f rbac-user-rolebinding.yml
kubectl delete -f namespace.json

I hope you enjoyed this quick tutorial on RBAC and learned a thing or 2 about basic authorization in Kubernetes. Let me know how this can be improved.