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:
From your existing Kubernetes client, run this command because you will need the Kubernetes Master address in the next step.
First, install openssl using chocolately
choco install openssl.light
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
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>
You will end up with files in
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”.
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
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
This page provides an overview for the role-based access control (RBAC) system provided by Kubernetes, and how you can…
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
Edit This Page The Kubernetes command-line tool, kubectl, allows you to run commands against Kubernetes clusters. You…
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).
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.
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.
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.
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.