Kubernetes RBAC : Le contrôle d'accès basé sur les rôles

Mise à jour : 14/12/2024

Quand on gère un cluster Kubernetes, la question de la sécurité se pose très vite : comment limiter l’accès aux ressources pour que seul ce qui est nécessaire soit autorisé ? C’est là qu’entre en jeu RBAC (Role-Based Access Control), un système de contrôle d’accès basé sur les rôles.

RBAC permet de définir qui peut effectuer quelle action sur quelles ressources. Imaginez que vous gérez une entreprise : certains employés peuvent consulter des données sensibles, d’autres non. Dans un cluster Kubernetes, c’est pareil. Avec RBAC, vous pouvez attribuer des rôles spécifiques aux utilisateurs, aux groupes ou aux applications, pour qu’ils aient seulement les permissions nécessaires à leurs tâches.

Historique de la gestion des accès Kubernetes

Lorsque Kubernetes a commencé à être adopté massivement, l’une des préoccupations majeures était la gestion des accès et des permissions. Les premières versions de Kubernetes utilisaient des mécanismes rudimentaires pour contrôler l’accès aux ressources du cluster, comme les certificats ou des politiques basées sur des fichiers JSON statiques. Ces solutions avaient deux gros défauts :

Manque de flexibilité : il était difficile d’adapter les permissions au fur et à mesure que les besoins évoluaient.
Gestion complexe : dans des clusters avec plusieurs utilisateurs, gérer les accès devenait rapidement un casse-tête.

Pour répondre à ces limites, Kubernetes a introduit le concept de Role-Based Access Control (RBAC) dans la version 1.6 (en 2017). Ce mécanisme s’inspire des systèmes RBAC classiques déjà largement utilisés dans les environnements d’entreprise, mais adapté aux besoins spécifiques des clusters Kubernetes.

Avec RBAC, la gestion des autorisations est devenue :

Centralisée : toutes les permissions sont définies directement dans le cluster.
Granulaire : les administrateurs peuvent accorder des permissions précises à des utilisateurs ou groupes d’utilisateurs sur des ressources spécifiques.
Extensible : RBAC peut être facilement combiné avec des outils comme Helm ou Kubernetes Operators ↗ pour des scénarios plus complexes.

En adoptant RBAC, Kubernetes a simplifié la gestion des accès, tout en renforçant la sécurité des clusters. Aujourd’hui, RBAC est activé par défaut dans presque toutes les distributions Kubernetes, et il constitue une bonne pratique incontournable pour tout administrateur ou développeur.

Fonctionnement et Concepts clés de RBAC

Pour comprendre comment utiliser RBAC dans Kubernetes, il est essentiel de saisir ses concepts fondamentaux et son fonctionnement. RBAC repose sur quatre ressources principales : Role, ClusterRole, RoleBinding et ClusterRoleBinding. Chaque élément joue un rôle précis dans la gestion des permissions au sein du cluster.

Role et ClusterRole

Ces deux types de ressources définissent les permissions applicables aux utilisateurs, groupes ou comptes de service.

Role : Un Role est limité à un namespace spécifique. Il permet de définir des permissions sur les ressources de ce namespace uniquement. Par exemple, on peut créer un rôle qui permet à un utilisateur de lister et lire les pods dans le namespace default.
ClusterRole : Contrairement au Role, un ClusterRole est global et s’applique à toutes les ressources du cluster, quel que soit le namespace. Il est idéal pour attribuer des permissions administratives ou accéder à des ressources globales comme les nœuds ou les volumes persistants.

Exemple d’un Role :

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list"]

Exemple d’un ClusterRole :

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: pod-reader-cluster
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list"]

RoleBinding et ClusterRoleBinding

Ces ressources permettent d’associer un rôle à un utilisateur, un groupe ou un compte de service.

RoleBinding : Lie un Role à un utilisateur ou groupe pour un namespace donné. Il est idéal pour appliquer des permissions limitées à une équipe ou un projet spécifique.
ClusterRoleBinding : Lie un ClusterRole à un utilisateur ou groupe à l’échelle du cluster. Utilisé pour donner des droits globaux ou accéder à des ressources hors d’un namespace.

Exemple d’un RoleBinding :

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: bind-pod-reader
  namespace: default
subjects:
- kind: User
  name: "johndoe"  # Utilisateur à qui on attribue le rôle
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader  # Le rôle défini précédemment
  apiGroup: rbac.authorization.k8s.io

Exemple d’un ClusterRoleBinding :

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cluster-pod-reader-binding
subjects:
- kind: User
  name: "admin-user"  # Utilisateur avec des droits globaux
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: pod-reader-cluster
  apiGroup: rbac.authorization.k8s.io

Les Verbs : Préciser les actions possibles

Les verbs définissent les actions autorisées sur les ressources. Voici les verbs les plus utilisés dans Kubernetes :

get : Lire une ressource.
list : Lister les ressources.
create : Créer une ressource.
update : Modifier une ressource existante.
delete : Supprimer une ressource.
watch : Observer les modifications sur une ressource en temps réel.

Ces verbs sont utilisés dans les règles des Roles et ClusterRoles pour définir précisément les actions autorisées.

Créer un Lab Minikube pour Expérimenter RBAC

Dans cette section, nous allons configurer un cluster Kubernetes local avec Minikube pour tester le fonctionnement de RBAC. Ce lab pratique vous permettra de configurer un utilisateur fictif et de lui attribuer des permissions spécifiques via RBAC.

Pré-requis

Minikube : Installer Minikube
kubectl : Installer kubectl
OpenSSL : pour générer et signer des certificats.
Un terminal : Bash ou PowerShell.

Étape 1 : Démarrer un Cluster Minikube

Démarrez Minikube pour créer un cluster Kubernetes local :

minikube start

Vérifiez que le cluster fonctionne :

kubectl get nodes
NAME       STATUS   ROLES           AGE   VERSION
minikube   Ready    control-plane   10m   v1.31.0

Étape 2 : Créer un Namespace pour les Tests

Pour organiser les ressources RBAC, créez un namespace spécifique nommé rbac-lab :

kubectl create namespace rbac-lab

Vérifiez qu’il est bien créé :

kubectl get namespaces

NAME              STATUS   AGE
default           Active   10m
kube-node-lease   Active   10m
kube-public       Active   10m
kube-system       Active   10m
rbac-lab          Active   10m

Étape 3 : Déployer des Pods dans le Namespace

Ajoutez des pods de test pour simuler un environnement réel.

Fichier YAML : nginx-pods.yaml

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  namespace: rbac-lab
  labels:
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx
    ports:
    - containerPort: 80

Appliquez le fichier :

kubectl apply -f nginx-pods.yaml

Vérifiez que les pods sont en cours d’exécution :

kubectl get pods -n rbac-lab

NAME    READY   STATUS    RESTARTS   AGE
nginx   1/1     Running   0          10m

Étape 4 : Configurer un Role et RoleBinding

Créez un Role pour permettre de lire les pods dans le namespace rbac-lab.

Fichier YAML : role-pod-reader.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: rbac-lab
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list"]

Appliquez le Role :

kubectl apply -f role-pod-reader.yaml

Ensuite, liez ce Role à un utilisateur fictif nommé test-user via un

RoleBinding.

Fichier YAML : rolebinding-pod-reader.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods-binding
  namespace: rbac-lab
subjects:
- kind: User
  name: test-user
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Appliquez le RoleBinding :

kubectl apply -f rolebinding-pod-reader.yaml

Étape 5 : Configurer un Utilisateur `test-user`

Kubernetes nécessite des certificats valides pour authentifier les utilisateurs. Nous allons créer un certificat pour test-user et le signer avec la CA utilisée par Minikube.

Exporter la CA de Minikube Minikube utilise sa propre CA pour gérer les certificats. Récupérez les fichiers nécessaires :

minikube ssh -- sudo cat /var/lib/minikube/certs/ca.crt > ca.crt
minikube ssh -- sudo cat /var/lib/minikube/certs/ca.key > ca.key

Générer une clé privée pour test-user Créez une clé privée :
Terminal window
```
openssl genrsa -out test-user.key 2048
```
Générer une demande de signature de certificat (CSR) Créez un fichier CSR pour test-user :
Terminal window
```
openssl req -new -key test-user.key -out test-user.csr -subj "/CN=test-user"
```

Signer le certificat avec la CA de Minikube Utilisez la CA pour signer le certificat de test-user :

openssl x509 -req -in test-user.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out test-user.crt -days 365

Étape 6 : Ajouter l’Utilisateur dans le kubeconfig

Ajoutez l’utilisateur test-user à la configuration de Kubernetes pour qu’il puisse interagir avec le cluster.

Configurer les informations d’authentification de test-user :

kubectl config set-credentials test-user \
  --client-certificate=test-user.crt \
  --client-key=test-user.key

Créer un contexte pour test-user dans le namespace rbac-lab :

kubectl config set-context test-user-context \
  --cluster=minikube \
  --namespace=rbac-lab \
  --user=test-user

Basculer vers le contexte de test-user :
Terminal window
```
kubectl config use-context test-user-context
```

Étape 7 : Tester les Permissions

Une fois le contexte configuré, testez les permissions attribuées à test-user :

Lister les pods dans le namespace rbac-lab (autorisé) :

kubectl get pods
 NAME    READY   STATUS    RESTARTS   AGE
 nginx   1/1     Running   0          10m

Tenter de créer un pod dans le namespace rbac-lab (interdit) :

kubectl run unauthorized-pod --image=nginx
Error from server (Forbidden): pods is forbidden: User "test-user" cannot create resource "pods" in API group "" in the namespace "rbac-lab"

Vous devriez voir une erreur Forbidden, confirmant que RBAC restreint l’action.

Étape 8 : Nettoyer le Lab

Une fois vos tests terminés, nettoyez le lab pour éviter de laisser des configurations inutiles.

Supprimez le namespace et les rôles liés :

kubectl config use-context minikube
kubectl delete namespace rbac-lab
kubectl config delete-context test-user-context
kubectl config unset users.test-user

Arrêtez Minikube :
Terminal window
```
minikube stop
```

Conclusion

Nous avons vu comment mettre en place un environnement Kubernetes local avec Minikube pour expérimenter la gestion des accès avec RBAC. Ce lab pratique vous a permis de créer un utilisateur fictif, de lui attribuer des permissions via des Roles et des RoleBindings, et de tester la granularité des contrôles d’accès. Vous avez également appris à générer et signer des certificats pour simuler un utilisateur, ce qui est une excellente base pour maîtriser RBAC.

Mais ce n’est que le début ! Kubernetes offre bien plus de possibilités en matière de gestion des utilisateurs et d’authentification. Voici quelques pistes d’améliorations pour enrichir votre lab et répondre à des besoins plus avancés :

Dans ce lab, nous avons configuré un utilisateur individuel, mais Kubernetes offre également la possibilité de gérer des groupes d’utilisateurs, ce qui simplifie l’attribution des permissions à des équipes entières. Cette approche permet de définir des permissions globales pour des groupes, plutôt que de configurer chaque utilisateur individuellement. Par exemple, vous pouvez créer un RoleBinding qui associe un groupe d’utilisateurs nommé dev-team à un rôle pod-reader, donnant ainsi à toute l’équipe les permissions nécessaires pour lire les pods d’un namespace. Cette méthode est particulièrement utile dans les environnements collaboratifs où les équipes doivent partager des niveaux d’accès similaires.

Pour allez plus sur la gestion des utilisateurs dans Kubernetes, il est possible d’intégrer des systèmes d’authentification externe. Par exemple, au lieu de créer et gérer des certificats manuellement pour chaque utilisateur, vous pouvez connecter Kubernetes à un fournisseur d’identité centralisé tel que Keycloak, Okta, ou tout autre service compatible OAuth2/OpenID Connect. Cela simplifie grandement l’administration en permettant une gestion centralisée des comptes et des permissions. En milieu professionnel, une autre option couramment utilisée est l’intégration avec un annuaire LDAP. Cela permet de gérer efficacement les utilisateurs et groupes au niveau de l’entreprise, tout en alignant Kubernetes sur les pratiques existantes en matière de sécurité et de contrôle d’accès.

Alors, prêt à pousser vos expérimentations encore plus loin ? 😊