Kubernetes User Management: Creating Users, Groups and Service Accounts

In this blog post, we will take you through Kubernetes user management: creating users, groups and service accounts. Kubernetes came with one mission, to revolutionize how containers are orchestrated. With all this power, there comes a greater responsibility! As a result, securing your Kubernetes cluster is essential, and user management plays a crucial role. This blog post delves into creating users, groups, and service accounts – the building blocks for secure access control within your cluster.

Understanding Kubernetes User Management

Every request made to an API server in a Kubernetes cluster has to be authenticated. Access to every resource in the cluster is controlled through Role-Based access control (RBAC), a framework which assigns users and services specific roles for their specific tasks.

To read more on RBAC, you can check the guide below;

Introduction to Role-Based Access Control (RBAC) in Kubernetes

User management involves creating identities that can be used to interact with the cluster. The identities include:

• Users: Users are individual humans that can access Kubernetes API server for tasks like managing the cluster.
• Groups: Collections of users with similar roles or responsibilities. Groups simplify the assignment and control of roles in the cluster.
• Service Accounts: Service accounts are non-human identities used by applications running within the cluster to access specific resources without requiring explicit user credentials.

In RBAC, we call these, RBAC subjects.

Creating Users in Kubernetes

Kubernetes does not have objects which represent normal user accounts and as such, unlike service accounts, they cannot be added to the cluster through an API call, but rather, need to be created by the cluster administrator who then shares the credentials to the real users.

Kubernetes provides a command line tool, kubectl, that can be used to control the Kubernetes cluster manager. This command can be used in creating Kubernetes users.

If you have a running Kubernetes cluster, then you should already have the kubectl command installed.

You can check out our guides on how to setup a Kubernetes cluster if you haven’t set it up already.

Kubernetes Authentication Strategies

There are different ways in which a Kubernetes subject can be authenticated. Some of the approaches include:

• Client Certificates (X.509): Users present their X.509 client certificates signed by the Kubernetes cluster’s certificate authority (CA) to prove their identity during authentication.
• Token-Based Authentication: This involves integrating Kubernetes cluster with an external authentication provider (like Okta for example) which provide token for users. The tokens are presente to the Kubernetes API server for validation.
• OpenID Connect (OIDC): Kubernetes can be integrated with OIDC providers like Google or GitHub for user authentication.
• Service Account Tokens: Special tokens used by pods or applications running within the cluster to access resources without relying on user credentials directly. Service accounts are automatically created for each namespace and bound to specific RBAC roles, granting them the necessary permissions.
• Webhook Authentication: This is an approach whereby the Kubernetes API server makes a call to an external web service to verify user identity.

Create X509 Client Certificates for Normal User Accounts

For simplicity sake, we will learn how to create a Kubernetes user account that uses x.509 certificates for authentication. This approach requires that the user’s certificates be signed by the Kubernetes cluster CA for authenticity purposes.

The use of x509 certificates for authentication and access control in Kubernetes cluster, while it is one of the most secure method, is not as effective as such for production level deployments.

Some of the downfalls include:

• Client certificates require managing private keys on user machines. This poses a security risk if a private key is compromised, granting unauthorized access to the cluster. Storing private keys directly in the kubeconfig file is particularly risky.
• Manually rotating and distributing updated certificates to all users can be cumbersome and error-prone, potentially leading to security vulnerabilities.
• As the number of users grows, managing individual certificates and access becomes complex. Adding, removing, or updating user certificates requires manual intervention.
• The method doesn’t inherently provide a straightforward mechanism for managing groups of users. While you can include user group information when generating the certificate, managing and maintaining group membership directly within certificates can be cumbersome and less flexible compared to other authentication methods.

Therefore, to create a Kubernetes user account that uses x509 certificates for authenticating against the cluster.

Ideally, the user that needs access to the cluster resources via API should generate a CSR and share to Kubernetes administraor for them to generate a signed certificate for the user. However, for demo purposes, we are generating certificates for the user as the K8S administrator.

Login to the control plane and generate the user’s private key.

mkdir ~/.kube/users

We have optionally decided to store the per-user certificates file in the above directory. You can choose you convenient location.

mkdir ~/.kube/users/alice

Next, using OpenSSL, generate user’s private key;

cd ~/.kube/users/alice

openssl genra -out alice.key 2048

Next, generate the user’s Certificate Signing Request (CSR). Note that the Common Name will be treated as the username.

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

When prompted for a passphrase, provide it and proceed.

After that, use the CSR to generate the user’s certificate and sign using the Kubernetes CA. Usually, the CA certificate and key are stored in the directory /etc/kubernetes/pki/ on the Kubernetes master node

sudo openssl x509 -req -in alice.csr \
	-CA /etc/kubernetes/pki/ca.crt \
	-CAkey  /etc/kubernetes/pki/ca.key \
	-CAcreateserial \
	-out alice.crt \
	-days 365

Sample output;

Certificate request self-signature ok
subject=CN = alice, O = infra

Update ownership!

sudo chown $USER: alice.crt

Add User’s Credentials to Kubeconfig

What is Kubeconfig File in a Kubernetes Cluster? Kubeconfig file is used to store Kubernetes user authentication information such as certificates, private keys etc. So, once you have the user certificate generated and signed by the cluster CA as shown above, you need to add the user’s credentials into the Kubeconfig file.

To add the credentials into Kubeconfig, the command, kubectl config set-credentials, can be used. All you need is the username (to name the credential), user’s private key and certificate files.

kubectl config set-credentials alice --client-certificate ./alice.crt --client-key ./alice.key

Sample output;

User "alice" set.

Read more on;

kubectl config set-credentials --help

Listing Users in Kubernetes

You can check the available users using the kubectl config get-users command;

kubectl config get-users

NAME
alice
kubernetes-admin

To get more details;

kubectl config view

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: DATA+OMITTED
    server: https://192.168.122.60:6443
  name: kubernetes
contexts:
- context:
    cluster: kubernetes
    namespace: apps
    user: kubernetes-admin
  name: kubernetes-admin@kubernetes
current-context: kubernetes-admin@kubernetes
kind: Config
preferences: {}
users:
- name: alice
  user:
    client-certificate: users/alice/alice.crt
    client-key: users/alice/alice.key
- name: kubernetes-admin
  user:
    client-certificate-data: DATA+OMITTED
    client-key-data: DATA+OMITTED

Set a Context for Kubernetes User

So, what exactly is a context in Kubernetes? A context refers to a combination of a cluster, a user, and a namespace that you want to interact with when executing kubectl commands.

In layman’s language, assume you are a delivery guy delivering goods to multiple neighborhoods in a city (clusters in Kubernetes). Before you set out for delivery, you need to know which houses specifically you are going to in those neighborhoods (namespaces in Kubernetes). This is setting out a context. In Kubernetes, this is like specifying a cluster and namespace to work on, as a specific user.

You can set a context for a user in Kubernetes using kubectl config set-context command.

kubectl config set-context <name of the context> --cluster=<name of the cluster> --user=<username> --namespace=<namespace>

You can create new clusters/namespaces. However, for this specific example, I will use the default cluster and namespace to set user’s context.

To get available clusters;

kubectl config get-clusters

NAME
kubernetes

To get available namespaces;

kubectl get namespaces

NAME              STATUS   AGE
apps              Active   34h
calico-system     Active   4d17h
default           Active   4d18h
kube-node-lease   Active   4d18h
kube-public       Active   4d18h
kube-system       Active   4d18h
tigera-operator   Active   4d18h

Having the required details at hand, proceed to set user’s context.

kubectl config set-context alice --cluster=kubernetes --user=alice --namespace=default

If you omit the –namespace flag, the namespace will default to default.

Switch to Kubernetes User’s Context

To switch to the user’s context, use kubectl config use-context <context> command. For example, to switch to alice’s context created above;

kubectl config use-context alice

Command Output;

Switched to context "alice".

Confirm;

kubectl config get-contexts

CURRENT   NAME                          CLUSTER      AUTHINFO           NAMESPACE
*         alice                         kubernetes   alice              default
          kubernetes-admin@kubernetes   kubernetes   kubernetes-admin   default

The asterisk (*) next to a context indicates the current active context.

You can also use kubectl config view command to check the contexts.

Deleting User Accounts

To delete user context or user credentials;

kubectl config delete-context <context-name>

kubectl config delete-user <user>

In the next tutorial, we will cover user role and rolebinding to enforce least privilege principle on users.

In the meantime, use the command kubectl auth can-i –help to see what the user is allowed on specific resources.

Creating Groups in Kubernetes

In Kubernetes, user groups are not directly created within the cluster itself. However, user groups can be simulated using Role-Based Access Control (RBAC) roles/cluster roles and roles/cluster roles bindings. We will explore this in our next guide.

If you are using X509 certificate authentication strategy, however, you can to define user groups while creating a user’s CSR, by specifying the respective group as a value of the Organization subject name component.

For example, to create a user called bob, who is in the devs group, you can generate a CSR as follows;

mkdir ~/.kube/users/bob

openssl genrsa -out ~/.kube/users/bob/bob.key 2048

openssl req -new -key ~/.kube/users/bob/bob.key -out ~/.kube/users/bob/bob.csr -subj "/CN=bob/O=devs"

If the user should be a member of multiple groups, specify them as multiple organizations on the command line;

openssl req -new -key ~/.kube/users/bob/bob.key -out ~/.kube/users/bob/bob.csr -subj "/CN=bob/O=infra/O=devs"

Then sign the CSR and generate user certificate.

sudo openssl x509 -req -in ~/.kube/users/bob/bob.csr 

sudo openssl x509 -req -in ~/.kube/users/bob/bob.csr  \
	-CA /etc/kubernetes/pki/ca.crt \
	-CAkey  /etc/kubernetes/pki/ca.key \
	-CAcreateserial \
	-out ~/.kube/users/bob/bob.crt \
	-days 365

sudo chown $USER: ~/.kube/users/bob/bob.crt

Then add user credentials to Kubeconfig;

kubectl config set-credentials bob --client-certificate ~/.kube/users/bob/bob.crt --client-key ~/.kube/users/bob/bob.key

You can then define user roles as per the group using RBAC.

Creating Service Accounts in Kubernetes Cluster

Create Service Accounts

You can easily use kubectl create serviceaccount command to create service accounts in a Kubernetes cluster. By default, Kubernetes has a service account called default.

For example, to create a service account called monitoring;

kubectl create serviceaccount monitoring

Read more on;

 kubectl create serviceaccount --help

You can also create a service account using a manifest file. In the simplest form, create a YAML file;

vim svc-monitoring.yml

apiVersion: v1
kind: ServiceAccount
metadata:
  name: monitoring

Then apply the manifest;

kubectl apply -f svc-monitoring.yml

Or simply;

kubectl apply -f - <<EOL
apiVersion: v1
kind: ServiceAccount
metadata:
  name: monitoring
EOL

Listing Service Accounts

List service accounts using the command;

kubectl get serviceaccounts

Get Service Account Details

To retrieve more details about a service account;

kubectl get serviceaccounts -o yaml <account-name>

For example;

 kubectl get serviceaccounts -o yaml monitoring

Or;

kubectl describe serviceaccounts <account-name>

Deleting Service Accounts

If you want to delete a service account, use kubectl delete serviceaccounts command.

kubectl delete serviceaccounts monitoring

Assign Users, Groups and Service Account Roles

In our next tutorial, we will delve further into assigning roles to Kubernetes users, user groups or even service accounts.

Until then, that concludes our guide on how to create Users, Groups and Service Accounts in a Kubernetes cluster.

Further Reading

Read more on Kubernetes authentication page.