A common authentication strategy for user accounts is to use client certificates. In the following example, we'll create a user named Linda and generate a client cert for her:
// generate a private key for Linda
# openssl genrsa -out linda.key 2048
Generating RSA private key, 2048 bit long modulus
..............+++
..............+++
e is 65537 (0x10001)
// generate a certificate sign request (.csr) for Linda. Make sure /CN is equal to the username.
# openssl req -new -key linda.key -out linda.csr -subj "/CN=linda"
Next, we'll generate a cert for Linda via a private key and sign request files, along with the CA and private key of our cluster:
In minikube, it's under ~/.minikube/. For other self-hosted solutions, normally it's under /etc/kubernetes/. If you use kops to deploy the cluster, the location is under /srv/kubernetes, where you can find the path in the/etc/kubernetes/manifests/kube-apiserver.manifest file.
// generate a cert
# openssl x509 -req -in linda.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out linda.crt -days 30
Signature ok
subject=/CN=linda
Getting CA Private Key
We got Linda signed by our cluster cert; now we can set it into our kubeconfig file:
# kubectl config set-credentials linda --client-certificate=linda.crt --client-key=linda.key
User "linda" set.
We can use kubectl config view to verify the user is set:
# kubectl config view
current-context: minikube
kind: Config
users:
- name: linda
user:
client-certificate: /k8s-cookbooks-2e/ch8/linda.crt
client-key: /k8s-cookbooks-2e/ch8/linda.key
...
After the user is created, we can create a context to associate the namespace and cluster with this user:
# kubectl config set-context linda-context --cluster=minikube --user=linda
After that, Kubernetes should be able to identify linda and pass it to the authorization stage.