Kubernetes Roles and Users (RBAC For k8s)
Tags: kubernetes, docker, git, cloud
Published: 2022-05-18 10:44:47

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](https://minikube.sigs.k8s.io/docs/start/), 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`

```jsx
useradd minkube && cd /home/minkube
```

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

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

Once the SSL key is created, generate some certificates based on x509.

```jsx
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.

```jsx
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.

```jsx
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.

```jsx
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.

```jsx
cd ~/.kube
```

Next, read the config with the `cat` command.

```jsx
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.

```jsx
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.

```jsx
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`.

```jsx
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.

```jsx
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.