Autorisation RBAC

Introduction

Dans Kubernetes, l’autorisation est généralement gérée avec RBAC (Role-Based Access Control, contrôle d’accès basé sur les rôles).

• Utilisateur : un employé, comme « Jane ».
• Role : un badge d’accès avec des droits précis, par exemple « peut entrer dans la salle des serveurs » ou « peut lire des documents ».
• RoleBinding : l’action d’attribuer le badge d’accès à l’employé.

RBAC est important, car l’accès au cluster ne se limite pas à l’authentification. Une fois l’identité connue, le système doit encore déterminer quelles actions cette identité est autorisée à effectuer.

Dans cet atelier, vous allez jouer le rôle du responsable de la sécurité :

• Créer un « badge visiteur » (Role) qui permet de consulter les ressources sans les modifier.
• Attribuer ce badge à un utilisateur nommé jane.
• Vérifier que Jane peut consulter le cluster, mais que ses tentatives de modification sont refusées.

Définir le Role

Commencez par créer l’ensemble des autorisations. Nous voulons un rôle « en lecture seule ». Ce rôle autorise l’utilisateur à list et get des Pods, c’est-à-dire à les lire, mais pas à les create ni à les delete.

RBAC correspond à l’autorisation dans Kubernetes, et non à l’authentification. L’authentification répond à la question « Qui êtes-vous ? ». L’autorisation répond à la question « Que pouvez-vous faire ? ». Dans cet atelier, nous nous concentrons sur la seconde question en définissant explicitement les actions autorisées, appelées verbs, pour certains types de ressources.

Créez un fichier nommé role.yaml :

nano role.yaml

Collez le YAML suivant. Cette définition crée un Role autorisé à effectuer les actions get, watch et list sur les pods.

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

Enregistrez le fichier et quittez (Ctrl+X, Y, Enter).

Appliquez maintenant ce « badge » au cluster :

kubectl apply -f role.yaml

Vérifiez qu’il existe :

kubectl get roles

Vous devez voir pod-reader.

Lier le Role

Vous disposez maintenant du badge (pod-reader) et de l’employée (jane). Mais Jane ne possède pas encore le badge. Vous devez créer un RoleBinding pour les associer.

Un Role n’accorde aucune autorisation tant qu’il n’est pas référencé par un binding. Cette séparation est intentionnelle. Elle permet aux administrateurs de définir une seule fois des ensembles d’autorisations réutilisables, puis de les attribuer selon les besoins à différents utilisateurs, groupes ou comptes de service.

Créez un fichier nommé rolebinding.yaml :

nano rolebinding.yaml

Collez le contenu suivant. Il indique : « Lier le rôle pod-reader à l’utilisateur jane ».

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
  - kind: User
    name: jane ## The employee
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader ## The key card
  apiGroup: rbac.authorization.k8s.io

Enregistrez le fichier et quittez (Ctrl+X, Y, Enter).

Appliquez le binding :

kubectl apply -f rolebinding.yaml

Vous avez maintenant officiellement accordé à Jane un accès en lecture seule à l’espace de noms default.

Vérifier l’accès

Comment tester cet accès ? Il n’est pas nécessaire de se déconnecter puis de se reconnecter en tant que Jane. Kubernetes permet d’« usurper » l’identité d’un utilisateur pour tester ses autorisations avec l’option --as.

Il s’agit d’une technique pratique d’administration. Les vérifications d’autorisations sont plus sûres lorsque vous pouvez simuler une identité avant d’accorder réellement l’accès à un utilisateur ou à un compte d’automatisation. Vous pouvez ainsi vérifier que la configuration correspond à l’objectif prévu, sans provoquer d’effets de bord inutiles dans le cluster.

Vérifiez que Jane peut lister les Pods :

kubectl auth can-i list pods --as jane

La sortie doit être yes.

Vous pouvez également vérifier qu’elle peut obtenir les détails d’un Pod précis :

kubectl auth can-i get pods --as jane

La sortie doit également être yes.

Cela confirme que le RoleBinding fonctionne. Le badge ouvre bien les portes !

Vérifier les restrictions

La sécurité concerne également ce que vous ne pouvez pas faire. Comme Jane possède uniquement le rôle pod-reader, elle doit être strictement empêchée d’effectuer des modifications.

C’est le principe du moindre privilège en pratique. Au lieu d’accorder un accès étendu en espérant que chacun l’utilisera avec précaution, vous commencez par accorder les autorisations minimales nécessaires à la tâche, puis vous ne les élargissez qu’en cas de besoin opérationnel réel.

Vérifiez si Jane peut créer un Pod :

kubectl auth can-i create pods --as jane

La sortie doit être no.

Vérifiez si Jane peut supprimer un Pod :

kubectl auth can-i delete pods --as jane

La sortie doit être no.

Si Jane essayait réellement d’exécuter ces commandes, le serveur d’API refuserait sa requête avec une erreur « Forbidden ». Cela confirme que votre cluster est sécurisé et respecte le principe du moindre privilège.

Résumé

Dans cet atelier, vous avez sécurisé votre cluster avec RBAC.

Vous avez réussi à :

1. Créer un Role (« badge d’accès ») avec des autorisations limitées en lecture seule.
2. Créer un RoleBinding pour attribuer ce badge à l’utilisateur jane.
3. Vérifier que jane peut consulter les ressources, mais pas les modifier.

Il s’agit de la base de la sécurité Kubernetes dans un environnement multi-utilisateur. Ne donnez jamais un accès administrateur complet à tout le monde !