Kubernetes Roles and Users (RBAC For k8s)
As with any type of log-in mechanism, there’s always some kind of user and role. The user could be a standard person or even a service account. A role could be anything from
readonly to full
When it comes to Kubernetes, it’s not any different. Users, roles, and permissions are insanely important when it comes to figuring out who or what service account has access to what resources. It’s the make or break between having the ability to deploy an application and only being able to view the deployed application.
In this blog post, you’ll learn about Kubernetes roles and users. You’ll start with what RBAC is, followed by creating a new user to access Kubernetes resources, and finishing up wish creating a few role-specific Kubernetes specs.
When you’re assigning permissions to specific users or service accounts, you’re typically assigning some sort of role. The roles typically look something like:
Of course there are a ton of different roles, but those are the typical. RBAC (Role-Based Access Control) by definition is a way to define access to systems and applications based on roles assigned to users.
With RBAC you can pick and choose who and what resources have authorization to specific resources. Those resources can be anything from a Kubernetes cluster to deploying Kubernetes Deployment specs to a service account having access to specific Kubernetes-deployed applications.
Creating a User for Kubernetes
With a lot of cloud Kubernetes services today, you don’t have to worry too much about creating users for Kubernetes in the standard way (like you’ll see below). For example, if you have an Azure Kubernetes Service (AKS) cluster, the users can be managed via:
- RBAC from the Azure portal
- AKS-managed Azure Active Directory (AS)
For standard Kubernetes cluster deployments or even something like Minikube, you would create and manage the users to connect to those clusters.
Let’s learn what that would look like in a Linux environment.
First, create a new user via the terminal. You can call the user
useradd minkube && cd /home/minkube
Next, create a new SSL key for the minikube user.
openssl req -new -key minikube.key \\
-out minikube.csr \\
Once the SSL key is created, generate some certificates based on x509.
openssl x509 -req -in minikube.csr \\
-CA /etc/kubernetes/pki/ca.crt \\
-CAkey /etc/kubernetes/pki/ca.key \\
-out minikube.crt -days 500
After that, create a new hidden directory
.certs and move the certs into the hidden directory.
mkdir .certs && mv minikube.crt minikube.key .certs
Once the minikube user and the appropriate certs are created, you can use the
kubectl command to set credentials for the minikube user based on the certificates that you generated in the previous steps.
kubectl config set-credentials minikube \\
You can then use
kubectl to set your current Kubernetes context with whatever Kubernetes cluster you’re using.
kubectl config set-context minikube-context \\
Setting the context is setting a Kubernetes cluster in your Kubeconfig, which you’ll learn about in the next section. You’ll also learn more about the Kubernetes configuration, typically called
Typically under a users home directory will live a hidden directory called
.kube. Within the
.kube directory is where you’ll find a file called
config. That’s the Kubernetes configuration or Kubeconfig as the cool kids like to call it for short. Your Kubeconfig is how your system tells a Kubernetes cluster Hey! I have access to you and a few of your resources. Let me in!
From the command line, change directories into the
Next, read the config with the
When you look at the Kubeconfig, you’ll see several different pieces. The main four top-level sections are:
- Current Context
The clusters section is for defining one or more Kubernetes clusters, which includes the authentication certificate. The contexts section shows which Kubernetes clusters you have access to per your Kubeconfig. The user’s section defines what users have access to in the current and existing contexts. The current context defines what Kubernetes cluster you’re currently connected to from an authorization/usability perspective. For example, if you run
kubectl get pods from the command line, the return will be the Pods in the Kubernetes cluster that’s set as your current context.
last-update: Tue, 12 Apr 2022 15:23:37 EDT
last-update: Tue, 12 Apr 2022 15:23:37 EDT
- name: minikube
Notice how there’s the minikube user? That user is set and has access to the current cluster, but what roles and permissions does that user actually have? Let’s dive into that in the next section.
In the previous section, you learned about what a Kubeconfig is, and a Kubeconfig is your authentication method. It’s what allows you to connect to a Kubernetes cluster. In this section, you’ll learn about Roles, which is authorization. Authorization tells Kubernetes Hey, this user is in the cluster. Here’s what they can actually do while in the cluster.
First, let’s define a Role spec. The Role spec creates a new role so any user that’s connecting to the role can access specific resources.
The Role spec below identifies that in the default namespace, called
pod-reader, users have access to Pods. It’s essentially a
read role because the permissions are
- apiGroups: [""] # "" indicates the core API group
verbs: ["get", "watch", "list"]
Next, there’s the
RoleBinding Spec. This spec tells Kubernetes which Role spec to look for, the user associated with it, and which namespace to associate the RoleBinding with.
- kind: User
Congrats! Just like that, you have a fully-available RBAC policy for a user that can read Pods.
There are a bunch of great safeguards in place out of the box when it comes to Kubernetes user security. In fact, Kubernetes doesn’t even have its own user database, so it essentially allows you to figure out what you want to use. For an on-prem k8s cluster, you might use a scenario as we did in the Creating a User for Kubernetes section. If you’re using a cloud Kubernetes service like Azure Kubernetes Service (AKS), you might utilize something like Azure Active Directory.
In any case, you can control what users have access to what Kubeconfigs and ultimately what those users can do on the Kubernetes cluster with RBAC.