Créer un dossier « lab08 » et se mettre dans ce dossier.
mkdir lab08
cd lab08
Créez un « namespace » avec la commande suivante:
kubectl create ns ns-test
Ensuite pour basculer vers ce « namespace » il faut utiliser la commande
kubectl config set-context --current --namespace=ns-test, mais dans notre cas on va utiliser un addon « kubens »
Installez et configurez « kubens » avec les commandes suivantes:
arkade get kubens
sudo mv /home/ubuntu/.arkade/bin/kubens /usr/local/bin/
Ensuite basculez sur le namespace « ns-test »
kubens ns-test
Revenez sur le namespace “default”
kubens default
La gestion des droits dans Kubernetes s’appuie sur RBAC pour fonctionner (Role-Based Access Control pour contrôle d’accès par rôles). Il s’agit d’un mécanisme qui permet de contrôler les droits d’accès des services déployés dans un cluster Kubernetes. Pour mémoire, RBAC a été introduit en version 1.6 et il est stable depuis la version 1.8.
Lancez la commande suivante afin de vérifier l’activation RBAC:
kubectl api-versions | grep rbac
La première étape est l’ajout d’un utilisateur « david » pour gérer que le namespace « ns-test » de notre cluster k8s. Kubernetes supporte plusieurs moyens pour l’authentification, pour cet utilisateur on va utiliser l’authentification par certificat.
Le mécanisme d’authentification par certificat s’appuie sur la génération d’une clé, la création d’un certificat associé à cette clé et la signature de ce dernier auprès de l’autorité de certification du cluster Kubernetes.
La première opération va consister à générer une clé à l’aide de la commande « openssl » suivie des options suivantes:
mkdir -p ~/.kube/users
cd ~/.kube/users
Ensuite
openssl genrsa -out david.key 2048
Deuxième étape : générez un certificat associé à cette clé embarquant un champ sujet. Pour être précis, il s’agit de générer une demande de certificat (CSR pour Certificate Signing Request). Le sujet sera structuré de la manière suivante:
Ce sujet, dans le cas de l’utilisateur david qui sera administrateur et fait partie de l’organisation « adm », prendra la forme suivante : « /CN=david/O=adm »
openssl req -new -key david.key \
-out david.csr \
-subj "/CN=david/O=adm"
Revenez dans le répertoire de lab.
cd /home/ubuntu/lab10
Une fois le CSR obtenu, il va falloir le soumettre au CA du cluster Kubernetes. Comme toujours dans Kubernetes, cela passe par un objet, ici un « CertificateSigningRequest ». Le fichier « user_signingrequest.yaml » correspondant est le suivant:
apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
name: david
spec:
request: [remplacez par csr_en_base_64]
signerName: kubernetes.io/kube-apiserver-client
#expirationSeconds: 157680000 # 5 ans (A partir de k8s 1.22)
usages:
- client auth
Le contenu est assez simple. Le nom d’utilisateur, correspondant au CN dans la demande de certificat, il est renseigné dans la section metadata. L’élément le plus important est dans la partie spec, l’option « request ». Il s’agit de la valeur du CSR obtenu précédemment, mais en base 64. Lancez la commande suivante pour l’obtenir.
mcert=$(cat ~/.kube/users/david.csr | base64 | tr -d "\n")
echo $mcert
Une fois le yaml est compléter créez l’objet avec la commande suivante:
kubectl apply -f user_signingrequest.yaml
Interrogez le cluster pour savoir si des demandes de certificats sont en cours
kubectl get csr
On retrouve bien notre demande en attente d’approbation. On va donc la valider avec la commande suivante:
kubectl certificate approve david
Récupérez le certificat signé
kubectl get csr david -o jsonpath='{.status.certificate}'| base64 -d > ~/.kube/users/david.crt
Ajoutez l’utilisateur dans « kubeconfig »
kubectl config set-credentials david \
--client-certificate=/home/ubuntu/.kube/users/david.crt \
--client-key=/home/ubuntu/.kube/users/david.key
Ajoutez un contexte « david@kubelabs » pour l’utilisateur « david »
kubectl config set-context david@kubelabs \
--cluster=kubelabs \
--user=david \
--namespace=ns-test
Listez les contextes
kubectl config get-contexts
Basculez sur le contexte « david@kubelabs » avec la commande « kubectl config use-context david@kubelabs » ou avec un addon « kubectx »
arkade get kubectx
sudo mv /home/ubuntu/.arkade/bin/kubectx /usr/local/bin/
Ensuite
kubectx david@kubelabs
Listez les pods dans les « namespace »
kubectl get pods --all-namespaces
L’utilisateur bien que déclaré sur le cluster ne dispose d’aucun droit. Revenez sur le contexte par défaut.
kubectx kubelabs
Il est nécessaire de créer un objet « Rôle » « rôle-admin-ns-test ». Ce rôle est admin sur le « namespace » « ns-test ».
On va utiliser la manifeste role-ns.yaml suivant:
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: ns-test
name: admin-of-ns-test
rules:
- apiGroups: ["*"]
resources: ["*"]
verbs: ["*"]
Appliquez ce rôle
kubectl apply -f role-ns.yaml
Le rôle étant créé, il faut l’associer au nouveau user « david ». Pour cela on passe par un objet « RoleBinding ». Cet objet permet tout simplement d’associer un rôle à un utilisateur au sein d’un « namespace ». Voici le manifeste role-binding.yaml.
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: ns-test-admin
namespace: ns-test
subjects:
- kind: User
name: david
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: admin-of-ns-test
apiGroup: rbac.authorization.k8s.io
Appliquez ce manifeste Basculez sur le contexte « david@kubelabs »
kubectx david@kubelabs
Testez et validez le rôle avec les commandes suivantes:
kubectl get pods
kubectl auth can-i list nodes
kubectl auth can-i list nodes
kubectl auth can-i '*' services
kubectl auth can-i --list
Basculez sur le contexte « kubelabs »
kubectx kubelabs