Kubernetes is a popular container orchestration platform that offers a robust set of features for managing containerized workloads at scale. One of the key aspects of Kubernetes is its authentication and authorization system, which allows you to control who has access to your Kubernetes resources.
In Kubernetes, authentication is the process of verifying the identity of a user or service account, while authorization is the process of determining what actions a user or service account is allowed to perform. Kubernetes supports several authentication mechanisms, including client certificates, bearer tokens, and OpenID Connect.
In this article, we’ll focus on how to create a user in Kubernetes using client certificates. Client certificates provide a secure way to authenticate users and services, and are commonly used in production Kubernetes clusters.
Creating a client certificate for a user involves several steps, including generating a private key, creating a certificate signing request (CSR), and signing the CSR with a certificate authority (CA). Let’s walk through each step in detail.
The first step in creating a client certificate for a user is to generate a private key. The private key is used to sign the certificate and must be kept secret. To generate a private key, you can use the OpenSSL command-line tool, which is available on most Unix-based systems.
To generate a private key with OpenSSL, run the following command:
openssl genrsa -out user.key 2048
This command generates a new 2048-bit RSA private key and saves it to a file called user.key.
The next step is to create a certificate signing request (CSR) using the private key generated in step 1. The CSR contains information about the user, such as their name and email address, and is used to request a digital certificate from a certificate authority (CA).
To create a CSR with OpenSSL, run the following command:
openssl req -new -key user.key -out user.csr -subj "/CN=<username>/O=<orgname>"
Replace and with the desired username and organization name, respectively. The -subj flag specifies the subject of the CSR, which includes information such as the common name (CN) and organization (O) of the user.
The next step is to sign the CSR with a certificate authority (CA). A CA is a trusted entity that issues digital certificates, which are used to authenticate users and services. In a production environment, you would typically use a public CA such as Let’s Encrypt or DigiCert. However, for testing purposes, you can create a self-signed CA using OpenSSL.
To create a self-signed CA with OpenSSL, run the following commands:
openssl genrsa -out ca.key 2048 openssl req -new -x509 -key ca.key -out ca.crt -days 3650 -subj "/CN=kubernetes-ca"
The first command generates a new 2048-bit RSA private key for the CA and saves it to a file called ca.key. The second command generates a self-signed X.509 certificate for the CA and saves it to a file called ca.crt. The -subj flag specifies the subject of the certificate, which in this case is simply “kubernetes-ca”.
With the CA certificate and key in hand, you can now sign the user’s CSR to generate a digital certificate. To do this, run the following command:
openssl x509 -req -in user.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out user.crt
Once the user and the role binding are created, we need to generate a kubeconfig file for the user. This kubeconfig file contains information about the user and the cluster, which is used by kubectl to authenticate the user.
To generate a kubeconfig file, we can use the following command:
kubectl config set-credentials <username> --client-certificate=<path-to-cert> --client-key=<path-to-key> --embed-certs=true
This command sets up the user’s client certificate and key and embeds the CA certificate in the kubeconfig file. The kubeconfig file can then be accessed by the user to authenticate with the cluster.
To verify that the user has been set up correctly, we can switch to the user’s context and run a kubectl command:
kubectl config use-context <user-context> kubectl get pods
If the command returns a list of pods, the user has been successfully authenticated and authorized to access the Kubernetes cluster.
In summary, creating a user in Kubernetes involves the following steps:
A private key is a cryptographic key that is used to encrypt and decrypt data, as well as to digitally sign and verify messages. In the context of Kubernetes authentication, the private key is used to sign the user’s certificate signing request (CSR), which is then signed by the certificate authority (CA) to generate a digital certificate for the user.
To generate a private key for the user, we use the OpenSSL command-line tool, which is available on most Unix-based systems. The command to generate a private key with OpenSSL is:
openssl genrsa -out user.key 2048
This command generates a new 2048-bit RSA private key and saves it to a file called
-out flag specifies the output file name, and the
2048 argument specifies the key size in bits. A larger key size provides greater security, but also requires more computational resources to generate and use.
Once the private key is generated, it must be kept secure and protected from unauthorized access. The private key is used to sign the user’s CSR, which contains sensitive information such as the user’s name and email address. If the private key is compromised, an attacker could use it to generate fraudulent certificates and impersonate the user.
It is important to securely store the private key and restrict access to it. One common practice is to store the private key in a password-protected key store or hardware security module (HSM). In a Kubernetes cluster, the private key can be stored as a Kubernetes secret and mounted into a pod as a volume, where it can be accessed by the application running in the pod.
By following these steps, we can create a user in Kubernetes and enable them to access the cluster with the appropriate permissions. It is important to note that proper user management is essential for maintaining the security and integrity of a Kubernetes cluster.