Kubernetes Beginner’s Guide Part 6: Role-Based Access Control

In this installment of our Kubernetes blog series, we’ll explore an essential security practice to protect your Kubernetes cluster – implementing Role-Based Access Control (RBAC). Security is a crucial aspect of any production-grade system, and Kubernetes is no exception. To follow along, you’ll want a local install of minikube and openssl so that we can create multiple users and test access control out using different contexts.

Role-Based Access Control (RBAC)

RBAC is a method for regulating access to computer or network resources based on the roles of individual users within your organization. It can help you configure who has access to your Kubernetes system and the associated permissions that they have, to do various operations, within it. With a local minikube install, you get a user named “minikube” by default and you can see this by opening the main configuration file for minikube:

code ~/.kube/config

The above command will open up minikube’s configuration file in VSCode. If you don’t have VSCode installed, please open that file in the editor of your choice. Depending on your own local setup, you may have multiple clusters, contexts and users specified here. Take a note of the certificate-authority specification within the minikube cluster configuration. We’ll be using this to create a self-signed certificate which we’ll then use to create a test-user, for our own explorations.

First, create our test-user’s private key using openssl:

openssl genrsa -out testuser.key 2048

Next we’ll create a Certificate Signing Request (CSR) for the user using the key we generated.

openssl req -new -key testuser.key -out testuser.csr -subj "/CN=testuser/O=tester/O=testing.xyz"

Next, let’s self-sign that certificate using the certificate authority that we took note of earlier, the one recognized by our minikube cluster. Make any changes to the command below, to match your own local setup.

openssl x509 -req -CA ~/.minikube/ca.crt -CAkey ~/.minikube/ca.key -CAcreateserial -days 730 -in testuser.csr -out testuser.crt

Next, we’ll add that test user to the minikube cluster.

kubectl config set-credentials testuser --client-certificate=testuser.crt --client-key=testuser.key

Next, let’s create a new context for this user. A context is a reference to a particular cluster, user and their default namespace.

kubectl config set-context testuser-minikube --cluster=minikube --user=testuser --namespace=default

You can verify that the new user and context has been setup by reopening the minikube config file and inspecting the latest changes.

Switch to the new context that we just created:

kubectl config use-context testuser-minikube

By switching to this context, we’ve instructed the kubectl utility to process any commands that we issue to the particular cluster, user and namespace that’s defined within it.

Now let’s try getting a list of pods:

kubectl get pods

Assuming that your context correctly switched to this brand user, you should see an error in your terminal, signifying that this user doesn’t have the permissions to do so.

Now, let’s switch back to the minikube administrative user context.

kubectl config use-context minikube

Now try to list the pods out again. You should see the pods in your cluster (if any) without any permission related errors. Now, as an administrator, let’s assign the necessary permissions to allow our testuser to list out pods. But instead of directly applying the permissions to a given user, let’s create an appropriate role so that we can better administer access at larger scales. In Kubernetes, we do so by setting up roles and role-bindings.

Roles and Role Bindings

First, let’s create a read-pods-role.yaml file with the following contents:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list"]

Next, apply the configurations that we specified in the file above.

kubectl apply -f read-pods-role.yaml

Our next objective is to assign this new role to testuser that we created earlier in this exercise. For that, let’s create a read-pods-rolebinding.yaml file.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: User
  name: testuser
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Apply this configuration.

kubectl apply -f read-pods-rolebinding.yaml

With this new role and binding in place, switch context back to testuser-minikube and try to kubectl get pods once again. This time, it should allow the testuser to do so.

Closing Thoughts

Congratulations! You’ve figured out how to setup roles and attach users to those roles within Kubernetes. In large-scale systems, setting up permissions using RBAC will certainly help in easing the burden of administration when compared to assigning ad-hoc permissions.