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 administrator.

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.

RBAC

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:

• readonly
• readwrite
• write
• admin
• owner

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 minikube

useradd minkube && cd /home/minkube

Next, create a new SSL key for the minikube user.

openssl req -new -key minikube.key \
  -out minikube.csr \
  -subj "/CN=minikube"

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 \
  -CAcreateserial \
  -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 \
  --client-certificate=/home/minikube/.certs/minikube.crt \
  --client-key=/home/minikube/.certs/minikube.key

You can then use kubectl to set your current Kubernetes context with whatever Kubernetes cluster you’re using.

kubectl config set-context minikube-context \
  --cluster=kubernetes --user=minikube

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 kubeconfig.

Kubeconfig (Authentication)

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 .kube configuration.

cd ~/.kube

Next, read the config with the cat command.

cat config

When you look at the Kubeconfig, you’ll see several different pieces. The main four top-level sections are:

• Clusters
• Contexts
• Users
• 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.

apiVersion: v1
clusters:
- cluster:
    certificate-authority: /Users/michael/.minikube/ca.crt
    extensions:
    - extension:
        last-update: Tue, 12 Apr 2022 15:23:37 EDT
        provider: minikube.sigs.k8s.io
        version: v1.25.1
      name: cluster_info
    server: https://127.0.0.1:57578
  name: minikube
contexts:
- context:
    cluster: minikube
    extensions:
    - extension:
        last-update: Tue, 12 Apr 2022 15:23:37 EDT
        provider: minikube.sigs.k8s.io
        version: v1.25.1
      name: context_info
    namespace: default
    user: minikube
  name: minikube
current-context: minikube
kind: Config
preferences: {}
users:
- name: minikube
  user:
    client-certificate: /Users/michael/.minikube/profiles/minikube/client.crt
    client-key: /Users/michael/.minikube/profiles/minikube/client.key

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.

user: minikube

Roles (Authorization)

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 get, watch, and list.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""] # "" indicates the core API group
  resources: ["pods"]
  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.

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

Congrats! Just like that, you have a fully-available RBAC policy for a user that can read Pods.

Wrapping Up

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.