Voyons comment autoriser l'accès à notre cluster kubernetes:

Avec mot de passe et ou tokens

Bien que ca ne soit pas la solution a privilégier, il est possible d'utiliser des fichiers CSV contenant des login/pass pour déclarer des utilisateurs.


Il suffira de passer le chemin du ficher csv en paramètre au démarrage de l'api-server:

  • Basic-auth-file 

k8s-users.csv

Le format: Password, User Name, User ID, (Group: optionnel)
pass1,user1,u1,group1
pass2,user2,u2,group2

Ensuite, on utilise l'argument --basic-auth-file=k8s-users.csv au lancement de l'apiserver (voir dans /etc/kubernetes/manifest/*yaml)

Et se connecter a l'api-serveur : 

curl -v -k https://localhost:6443/api/v1/pods -u "user1:password123"
  • Token-auth-file:

Même principe, mais avec des tokens au lieu des mots de passe.

Avec les certificats

Après quelques recherches, on comprend vite que k8s est d'avantage porté sur l'utilisation de certificats pour l'authentification des clients.

A noter que pour k8s, un utilisateur est simplement une valeur dans le champ CN du certificat (/CN=toto ci dessous)

//Creation du certificat pour l'utilisateur "toto"

//Clé privé de toto 
openssl genrsa -out toto.key 2048

// Demande de signature (CSR) 
openssl req -new -key toto.key -subj "/CN=toto" -out toto.csr

A présent, notre CSR doit être traité par kubernetes pour avoir le certificat final.
Deux solutions: le signer depuis le controlplane 'a la main' ou utiliser les CertificateSingingRequest de k8s.

  • Signature manuelle du certificat: 
// Signature a la main depuis le controlplane: 
// openssl x509 -req -in toto.csr -CA kubernetes-root-ca.crt -CAkey kubernetes-root-ca.key  -out toto.crt

  • Signature via kubernetes

Kubernetes propose un service de signature des CSR via son API et l'objet de CertificateSigningRequest: 

// Créer un objet CertificateSigningRequest
// Pensez a mettre à jour le champ request: avec votre CSR encodé en base64
apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
  name: toto-csr
  spec:
  request: xxxxxxxxxxxxxxxxx.....VOTRECSR......yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy=      
  signerName: kubernetes.io/kube-apiserver-client
  expirationSeconds: 86400  # one day
  usages: 
  - client auth

$ k apply -f myuser-csr.yaml 

// On retrouve notre csr, en état pending
$ k get csr                                                                      NAME     AGE   SIGNERNAME                            REQUESTOR   REQUESTEDDURATION   CONDITION         
toto-csr   33m   kubernetes.io/kube-apiserver-client   theadmin     24h                 Pending  

// Approbation du certificat
$ k certs approve myuser-csr

// Le CSR a été traité par kubernetes et passe en approved/Issued 
$k get csr                                                                      NAME     AGE   SIGNERNAME                            REQUESTOR   REQUESTEDDURATION   CONDITION         
toto-csr   33m   kubernetes.io/kube-apiserver-client   theadmin     24h                 Approved,Issued   

// Récupération du certificat signé
k get csr toto -o jsonpath='{.status.certificate}' | base64 -d > toto.crt
  • Notes

Comme dit précédement, c'est le champ Subject du certificat qui définit le user ou et ses groupes.

On peut dont tout a fait créer un user avec les droits d'admin en précisant le groupe "system:masters" pendant la création du CSR:

-subj "/CN=supertoto/O=system:masters"

  • Références

https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/#normal-user

https://killercoda.com/chadmcrowell/course/cka/kubernetes-create-user