As explained in the Kubernetes docs, Kubernetes doesn't have objects to represent normal user accounts. Therefore, they need to be managed externally (check the Kubernetes Authentication documentation in the See also section for more details). This recipe will show you how to create and manage user accounts using private keys.

Let's perform the following steps to create a user account:

1. Create a private key for the example user. In our example, the key file is user3445.key:

$ openssl genrsa -out user3445.key 2048

2. Create a certificate sign request (CSR) called user3445.csr using the private key we created in Step 1. Set the username (/CN) and group name (/O) in the -subj parameter. In the following example, the username is john.geek, while the group is development:

$ openssl req -new -key user3445.key 
-out user3445.csr 
-subj "/CN=john.geek/O=development"

3. To use the built-in signer, you need to locate the cluster-signing certificates for your cluster. By default, the ca.crt and ca.key files should be in the /etc/kubernetes/pki/ directory.If you are using kops to deploy, your cluster signing keys can be downloaded from s3://$BUCKET_NAME/$KOPS_CLUSTER_NAME/pki/private/ca/*.key and s3://$BUCKET_NAME/$KOPS_CLUSTER_NAME/pki/issued/ca/*.crt. Once you've located the keys, change the CERT_LOCATION mentioned in the following code to the current location of the files and generate the final signed certificate:

$ openssl x509 -req -in user3445.csr 
-CA CERT_LOCATION/ca.crt 
-CAkey CERT_LOCATION/ca.key 
-CAcreateserial -out user3445.crt 
-days 500

4. If all the files have been located, the command in Step 3 should return an output similar to the following:

Signature ok
subject=CN = john.geek, O = development
Getting CA Private Key

Before we move on, make sure you store the signed keys in a safe directory. As an industry best practice, using a secrets engine or Vault storage is recommended. You will learn more about Vault storage later in this chapter IN the Securing credentials using HashiCorp Vault recipe. 

5. Create a new context using the new user credentials:

$ kubectl config set-credentials user3445 --client-certificate=user3445.crt --client-key=user3445.key
$ kubectl config set-context user3445-context --cluster=local --namespace=secureapp --user=user3445

6. List the existing context using the following comment. You will see that the new user3445-context has been created:

$ kubectl config get-contexts
CURRENT NAME                    CLUSTER AUTHINFO NAMESPACE
*       service-account-context local   kubecfg
        user3445-context        local   user3445 secureapp

7. Now, try to list the pods using the new user context. You will get an access denied error since the new user doesn't have any roles and new users don't come with any roles assigned to them by default:

$ kubectl --context=user3445-context get pods
Error from server (Forbidden): pods is forbidden: User "john.geek" cannot list resource "pods" in API group "" in the namespace "secureapps"

8. Optionally, you can base64 encode all three files (user3445.crt, user3445.csr, and user3445.key) using the openssl base64 -in <infile> -out <outfile> command and distribute the populated config-user3445.yml file to your developers. An example file can be found in this book's GitHub repository in the src/chapter9/rbac directory. There are many ways to distribute user credentials. Review the example using your text editor:

$ cat config-user3445.yaml

With that, you've learned how to create new users. Next, you will create roles and assign them to the user.