Kubernetes Authentication, Authorization & Audit. Part 2

Part 1 is here

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

https://pharosproduction.com

Follow our product Ludo — the reputational system of the Web3 world

https://ludo.com