Kubernetes Authentication, Authorization & Audit. Part 2
Certificates for users (X.509)
The classic way of working with certificates involves.
Key generation:
mkdir -p ~/mynewuser/.certs/
openssl genrsa -out ~/.certs/mynewuser.key 2048
Generating a certificate request:
openssl req -new -key ~/.certs/mynewuser.key -out ~/.certs/mynewuser.csr -subj "/CN=mynewuser/O=company"
Processing a certificate request using the Kubernetes cluster CA keys, obtaining a user certificate (to obtain a certificate, you must use an account that has access to the Kubernetes cluster CA key, which by default is located in /etc/kubernetes/pki/ca.key):
openssl x509 -req -in ~/.certs/mynewuser.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out ~/.certs/mynewuser.crt -days 500
And now creating a K8s configuration file:
Cluster description (indicate the address and location of the CA certificate file for a specific cluster installation)
kubectl config set-cluster kubernetes - certificate-authority=/etc/kubernetes/pki/ca.crt - server=https://192.168.100.200:6443
or — as a non-recommended option — you can omit the root certificate (then kubectl will not check the correctness of the cluster’s API-server)
kubectl config set-cluster kubernetes --insecure-skip-tls-verify=true --server=https://192.168.100.200:6443
adding a user to the configuration file
kubectl config set-credentials mynewuser --client-certificate=.certs/mynewuser.crt --client-key=.certs/mynewuser.key
adding context
kubectl config set-context mynewuser-context --cluster=kubernetes --namespace=target-namespace --user=mynewuser
assign default context
kubectl config use-context mynewuser-context
After the above manipulations, a config of the following type will be created in the .kube/config file
apiVersion: v1
clusters:
- cluster:
certificate-authority: /etc/kubernetes/pki/ca.crt
server: https://192.168.100.200:6443
name: kubernetes
contexts:
- context:
cluster: kubernetes
namespace: target-namespace
user: mynewuser
name: mynewuser-context
current-context: mynewuser-context
kind: Config
preferences: {}
users:
- name: mynewuser
user:
client-certificate: /home/mynewuser/.certs/mynewuser.crt
client-key: /home/mynewuser/.certs/mynewuser.key
To make it easier to transfer the config between accounts and servers, it is useful to edit the values of the following keys
- certificate-authority
- client-certificate
- client-key
To do this, you can encode the files specified in them using base64 and write them in the config, adding the suffix -data to the name of the keys, i.e. getting certificate-authority-data.
Certificates with kubeadm
With the release of Kubernetes 1.15, working with certificates has become much easier thanks to the alpha version of its support in the Kubeadm utility. For example, this is how generating a configuration file with user keys might now look like
kubeadm alpha kubeconfig user --client-name=mynewuser --apiserver-advertise-address 192.168.100.200
The required advertise address can be found in the API-server config, which by default is located in /etc/kubernetes/manifests/kube-apiserver.yaml
The resulting config will be output to stdout. It should be saved in the user account’s ~/.kube/config or the file specified in the KUBECONFIG environment variable.
You can say Hi to us at Pharos Production — a software development company
Follow our product Ludo — the reputational system of the Web3 world