Step-by-Step Guide to Creating a Kubernetes User and Adding It to a Kubeconfig File (RBAC)

Managing users in Kubernetes involves several key steps, from creating the user to configuring access via certificates and finally adding them to a kubeconfig file. In this detailed guide, we'll walk through the process of creating a user, generating a certificate, approving it, and configuring access using a kubeconfig file.

Overview

Key Concepts:

• Kubernetes Users: Unlike traditional Linux users, Kubernetes users are entities with access rights to the cluster. Kubernetes does not store user accounts but relies on external systems or certificate-based authentication.

• Certificates: Users are authenticated using X.509 certificates, which prove their identity to the Kubernetes API server.

• RBAC (Role-Based Access Control): RBAC is used to manage permissions for users within the cluster.

Steps Covered:

1. Generate a private key and certificate signing request (CSR) for the user.

2. Approve the CSR to generate a user certificate.

3. Create a Kubernetes role and role binding for the user.

4. Add the user to the kubeconfig file.

5. Test access using the new user credentials.

Step 1: Generate a Private Key and Certificate Signing Request (CSR)

The first step is to create a private key and a CSR for the user. The private key is used to authenticate the user, while the CSR is sent to the Kubernetes API server to request a certificate.

1. Generate the Private Key:
   

   openssl genrsa -out user1.key 2048
   

   This command generates a 2048-bit RSA private key for the user.

2. Generate the CSR:
   

   openssl req -new -key user1.key -out user1.csr -subj "/CN=user1/O=dev-team"
   

   This command generates a CSR using the private key. The -subj parameter specifies the subject of the certificate:

* CN (Common Name): The name of the user (user1).



O (Organization): The group to which the user belongs (dev-team).

Step 2: Submit and Approve the CSR in Kubernetes

Now that you have the CSR, submit it to Kubernetes to generate a certificate.

1. Create a CSR Object in Kubernetes:
   

   cat <<EOF | kubectl apply -f -
   apiVersion: certificates.k8s.io/v1
   kind: CertificateSigningRequest
   metadata:
     name: user1-csr
   spec:
     request: $(cat user1.csr | base64 | tr -d '\n')
     signerName: kubernetes.io/kube-apiserver-client
     usages:
     - client auth
   EOF
   

   This YAML file creates a CSR object in Kubernetes. The request field contains the base64-encoded CSR.

2. Approve the CSR:
   

   kubectl certificate approve user1-csr
   

   This command approves the CSR, allowing Kubernetes to issue the certificate.

3. Retrieve the Certificate:

   Once approved, you can retrieve the certificate using the following command:
   

   kubectl get csr user1-csr -o jsonpath='{.status.certificate}' | base64 --decode > user1.crt
   

   This command extracts the issued certificate and saves it as user1.crt.

Step 3: Create a Role and Role Binding for the User

The next step is to define the permissions the user will have in the Kubernetes cluster. This is done using Kubernetes RBAC (Role-Based Access Control).

1. Create a Role:
   

   cat <<EOF | kubectl apply -f -
   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     namespace: default
     name: dev-role
   rules:
   - apiGroups: [""]
     resources: ["pods"]
     verbs: ["get", "list", "watch"]
   EOF
   

   This YAML file creates a role named dev-role in the default namespace, granting the user read-only access to pods.

2. Create a Role Binding:
   

   cat <<EOF | kubectl apply -f -
   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: dev-role-binding
     namespace: default
   subjects:
   - kind: User
     name: user1
     apiGroup: rbac.authorization.k8s.io
   roleRef:
     kind: Role
     name: dev-role
     apiGroup: rbac.authorization.k8s.io
   EOF
   

   This YAML file binds the dev-role to the user1 in the default namespace.

Step 4: Add the User to the Kubeconfig File

To allow the user to interact with the Kubernetes cluster using kubectl, you must add their credentials to the kubeconfig file.

1. Add the User Configuration:
   

   kubectl config set-credentials user1 --client-certificate=user1.crt --client-key=user1.key
   

   This command adds the user1 credentials to the kubeconfig file, pointing to the certificate and key files generated earlier.

2. Add the Cluster Information:
   

   kubectl config set-cluster my-cluster --server=https://<api-server-url> --certificate-authority=/path/to/ca.crt
   

   Replace <api-server-url> with your Kubernetes API server’s URL. This command adds the cluster information to the kubeconfig file.

3. Create a Context for the User:
   

   kubectl config set-context user1-context --cluster=my-cluster --namespace=default --user=user1
   

   This command creates a context that links the user1 credentials with the my-cluster cluster and the default namespace.

4. Use the Context:
   

   kubectl config use-context user1-context
   

   This command switches the current context to user1-context, meaning all kubectl commands will be executed using user1's credentials.

Step 5: Test the User’s Access

Finally, test the user’s access to ensure everything is configured correctly.

1. Test Access to Pods:
   

   kubectl get pods
   

   If everything is set up correctly, this command should list the pods in the default namespace, as per the permissions defined in the dev-role.

2. Test Unauthorized Actions:

   Try to perform an action that user1 does not have permission to execute, such as deleting a pod:
   

   kubectl delete pod <pod-name>
   

   This should fail with a permission error, confirming that the RBAC is working as expected.

Conclusion

This guide walked through the entire process of creating a Kubernetes user, generating and approving a certificate, configuring access via a kubeconfig file, and testing the user’s permissions. By following these steps, you can securely manage user access to your Kubernetes cluster, ensuring that each user has the appropriate level of access based on their role within the organization.