Gestion des droits avec RBAC

RBAC signifie Role-Based Access Control. Il s'agit d'un mécanisme de contrôle d'accès utilisé dans Kubernetes pour octroyer des autorisations granulaires à des utilisateurs, groupes ou applications (ServiceAccounts) au sein d'un cluster.

Les RBAC ont été introduits à partir de la version 1.8 de Kubernetes et utilisent l'API Group rbac.authorization.k8s.io pour la création des politiques d'accès. Ce mécanisme est activé par défaut sur tous les clusters Kubernetes modernes.

L'implémentation de RBAC se fait au travers de quatre types d'entités Kubernetes :

Le schéma ci-après montre trois façons d'aborder l'octroi d'accès :

1. Utilisation d'un Role en association avec un RoleBinding
   Application d'autorisations restreintes au Namespace car les entités RBAC utilisées sont namespacées

2. Utilisation d'un ClusterRole en association avec un RoleBinding
   Application d'autorisations globales (ClusterRole) limitées à un Namespace grâce au RoleBinding namespacé

3. Utilisation d'un ClusterRole en association avec un ClusterRoleBinding
   Application d'autorisations globales aux ressources du Cluster

Roles et ClusterRoles

Avant d'attribuer des autorisations aux utilisateurs avec RBAC, vous devez tout d'abord définir ces autorisations en tant que rôle. Les Roles et ClusterRoles accordent des autorisations. Le concept d'autorisation refusée n'existe pas.

Les Role sont utilisés pour accorder des autorisations dans un espace de noms. Si vous devez accorder des autoriations sur l'ensemble du cluster ou sur des ressources de cluster en dehors d'un espace de noms donné, vous pouvez utiliser les ClusterRoles à la place.

Role

Les Roles définissent ce que vous pouvez réaliser avec quelle ressource, au sein d'un Namespace particulier, car l'entité Role est namespacée. Ils sont composés de règles (rules) définissant chacune :

• apiGroups : Liste des groupes d'API concernés (obtenez la liste complète avec kubectl api-resources)

  • "" pour le groupe Core (Pods, Services, ConfigMaps, Secrets...)
  • apps pour les Deployments, StatefulSets, DaemonSets
  • rbac.authorization.k8s.io pour les RBAC
  • batch pour les Jobs et CronJobs
  • networking.k8s.io pour les Ingress et NetworkPolicies

• resources : Types d'objets Kubernetes concernés (Pods, Services, Deployments, Secrets...)

• verbs : Actions autorisées sur ces ressources

Verbes disponibles

Voici un exemple de Role mis en place pour le déploiement de l'opérateur Kopf :

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: [NAMESPACE]
  name: [NAME]
rules:
  - apiGroups: [zalando.org]
    resources: [kopfpeerings]
    verbs: [list, watch, patch, get]
 
  - apiGroups: [events.k8s.io]
    resources: [events]
    verbs: [create]
 
  - apiGroups: [batch]
    resources: [jobs]
    verbs: [create]
 
  - apiGroups: [""]
    resources: [services, events, namespaces]
    verbs: [get, list, watch, create, update, patch, delete]
 
  - apiGroups: [""]
    resources: [pods, persistentvolumeclaims]
    verbs: [create]

Ce Role donnera donc droit aux ressources :

• KopfPeerings qui appartient à l'ApiGroup zalando.org avec les verbes list, watch, patch et get
• Events qui appartient à l'ApiGroup events.k8s.io avec le verbe create
• Services, Events et Namespaces de l'ApiGroup Core ("") avec les verbes get, list, watch, create, update, patch et delete
• Jobs dans l'API Group batch avec le verbe create
• Pods et PersistentVolumeClaims dans l'ApiGroup Core ("") avec le verbe create

Roles par défaut

Kubernetes est livré avec un certain nombre de ClusterRoles prédéfinis que vous pouvez réutiliser via des RoleBindings :

Consultez la liste complète dans la documentation officielle.

ClusterRole

Les ClusterRoles se définissent comme les Roles mais s'appliquent à l'ensemble du cluster Kubernetes. Ils peuvent être utilisés de deux façons :

1. Avec un ClusterRoleBinding : Autorisations appliquées sur tout le cluster
2. Avec un RoleBinding : Autorisations applicables globalement mais restreintes à un Namespace spécifique

Cas d'usage des ClusterRoles

• Ressources non-namespacées : Nodes, PersistentVolumes, Namespaces, ClusterRoles...
• Modèles réutilisables : Définir une politique d'accès commune à appliquer dans plusieurs Namespaces
• Accès cluster-wide : Opérateurs, observabilité, controllers nécessitant une vue globale

RoleBindings et ClusterRoleBindings

Une fois les rôles définis pour accorder les autorisations aux ressources, vous affectez ces autorisations RBAC au moyen d'un RoleBinding ou ClusterRoleBinding.

RoleBinding

Les RoleBinding associent un Role ou un ClusterRole à un ou plusieurs sujets (subjects) dans un namespace spécifique. Cette approche permet de séparer logiquement un cluster avec des utilisateurs uniquement capables d'accéder aux ressources de leur Namespace attribué.

Sujets (Subjects)

Un RoleBinding peut lier des autorisations à trois types de sujets :

Voici un exemple de RoleBinding utilisé dans la mise en place de l'opérateur Kopf :

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: kopf-operator-binding
  namespace: my-namespace
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: kopf-operator-role
subjects:
  - kind: ServiceAccount
    name: kopf-operator-sa
    namespace: my-namespace

ClusterRoleBinding

Un ClusterRoleBinding fonctionne de la même façon qu'un RoleBinding pour lier des rôles aux sujets, mais il s'applique à toutes les ressources du cluster, sans restriction de namespace.

Cas d'usage

• Administrateurs cluster : Accès complet pour la gestion du cluster
• Opérateurs Kubernetes : Controllers nécessitant une vue globale (cert-manager, ingress-controller...)
• Monitoring : Systèmes d'observabilité (Prometheus, Grafana...)
• Accès multi-namespaces : Utilisateurs devant gérer plusieurs namespaces

Voici un exemple de ClusterRoleBinding :

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: kopf-operator-cluster-binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: kopf-operator-cluster-role
subjects:
  - kind: ServiceAccount
    name: kopf-operator-sa
    namespace: operators

ServiceAccount

Les ServiceAccounts sont des identités utilisées par les Pods pour s'authentifier auprès de l'API Kubernetes. Ils permettent aux applications de communiquer avec le cluster de manière sécurisée.

Comportement par défaut

À la création d'un Namespace, Kubernetes crée automatiquement un ServiceAccount nommé default. Ce compte dispose de permissions très limitées :

Utilisation dans un Pod

Vous pouvez spécifier un ServiceAccount personnalisé dans vos Deployments ou Pods avec le champ serviceAccountName :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  namespace: my-namespace
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      serviceAccountName: my-service-account
      containers:
        - name: app
          image: my-app:latest

Token et authentification

Chaque ServiceAccount est associé à un Secret contenant un token JWT permettant l'authentification auprès de l'API Kubernetes :

# Lister les secrets associés à un ServiceAccount
kubectl get secrets -n my-namespace
 
# Extraire le token
kubectl get secret <secret-name> -n my-namespace -o jsonpath='{.data.token}' | base64 --decode

Groups

Les Groups sont des ensembles d'utilisateurs ou de ServiceAccounts partageant des autorisations communes. Kubernetes dispose de plusieurs groupes système prédéfinis, identifiables par le préfixe system:.

Groupes système courants

Lister les ClusterRoles système

Pour visualiser tous les ClusterRoles système disponibles :

kubectl get clusterroles | grep ^system:

Exemple de sortie :

system:aggregate-to-admin                                              363d
system:aggregate-to-edit                                               363d
system:aggregate-to-view                                               363d
system:auth-delegator                                                  363d
system:basic-user                                                      363d
system:certificates.k8s.io:certificatesigningrequests:nodeclient       363d
system:node                                                            363d

Cas pratiques

Ces exemples illustrent des scénarios fréquents de création de ServiceAccounts avec des autorisations limitées.

:::warning Sécurité Appliquez toujours le principe du moindre privilège : n'accordez que les autorisations strictement nécessaires. Évitez d'utiliser verbs: ["*"] en production. :::

Cas 1 : ServiceAccount limité à un Namespace unique

Contexte : Vous souhaitez créer un accès pour une application ou un utilisateur devant gérer un seul Namespace.

Avantages :

• Isolation stricte par Namespace
• Sécurité renforcée (accès impossible aux autres Namespaces)
• Idéal pour les environnements multi-tenants

Prérequis : Accès administrateur au cluster Kubernetes

# Le Namespace dans lequel vérouiller l'utilisateur
NAMESPACE="my-namespace"
 
# Le nom du ServiceAccount à créer
SERVICE_ACCOUNT="my-service-account"
 
# Le nom du Role à créer
ROLE="${SERVICE_ACCOUNT}-role"
 
# Le nom du RoleBinding à créer
ROLEBINDING="${ROLE}-binding"
 
# Le nom du Context pour le fichier kubeconfig
CLUSTER_NAME=$(kubectl config view --minify -o jsonpath='{.clusters[0].name}')
CONTEXT="${SERVICE_ACCOUNT}-${NAMESPACE}-${CLUSTER_NAME}"

kubectl create namespace ${NAMESPACE}

kubectl -n ${NAMESPACE} create serviceaccount ${SERVICE_ACCOUNT}

cat <<EOF > payload.yml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: ${ROLE}
  namespace: ${NAMESPACE}
rules:
  - apiGroups: ["*"]
    resources: ["*"]
    verbs: ["*"]
EOF
 
kubectl -n ${NAMESPACE} apply -f payload.yml

cat <<EOF > payload.yml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: ${ROLEBINDING}
  namespace: ${NAMESPACE}
subjects:
  - kind: ServiceAccount
    name: ${SERVICE_ACCOUNT}
    namespace: ${NAMESPACE}
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: ${ROLE}
EOF
 
kubectl -n ${NAMESPACE} apply -f payload.yml

# Le Certificat du Cluster
CLUSTER_CA_CRT=$(kubectl config view --minify --flatten -o=jsonpath='{.clusters[*].cluster.certificate-authority-data}' 2> /dev/null)
 
# Le Nom du Cluster
CLUSTER_NAME=$(kubectl config view --minify --flatten -o=jsonpath='{.clusters[*].name}')
 
# Le Endpoint API du Cluster
CLUSTER_ENDPOINT=$(kubectl config view --minify --flatten -o=jsonpath='{.clusters[*].cluster.server}')

# Le Secret associé au ServiceAccount
SERVICE_ACCOUNT_SECRET=$(kubectl -n ${NAMESPACE} get secrets -o jsonpath="{.items[?(@.metadata.annotations['kubernetes\.io/service-account\.name']=='${SERVICE_ACCOUNT}')].metadata.name}" 2> /dev/null)
 
# Le Token caché dans le Secret
SERVICE_ACCOUNT_TOKEN=$(kubectl -n ${NAMESPACE} get secret ${SERVICE_ACCOUNT_SECRET} -o jsonpath="{.data['token']}" 2> /dev/null | base64 --decode)

cat <<EOF > kubeconfig
apiVersion: v1
kind: Config
users:
  - name: ${SERVICE_ACCOUNT}
    user:
      token: ${SERVICE_ACCOUNT_TOKEN}
clusters:
  - name: ${CLUSTER_NAME}
    cluster:
      certificate-authority-data: ${CLUSTER_CA_CRT}
      server: ${CLUSTER_ENDPOINT}
contexts:
  - name: ${CONTEXT}
    context:
      cluster: ${CLUSTER_NAME}
      namespace: ${NAMESPACE}
      user: ${SERVICE_ACCOUNT}
current-context: ${CONTEXT}
EOF

# Commande en erreur : vous n'avez pas accès au NS kube-system
kubectl --kubeconfig=./kubeconfig -n kube-system get all
 
# Commande Ok : accès au namespace autorisé
kubectl --kubeconfig=./kubeconfig -n ${NAMESPACE} get all

Cas 2 : ServiceAccount limité à plusieurs namespaces

Contexte : Vous souhaitez créer un accès pour une application ou un utilisateur devant gérer plusieurs namespaces (par exemple : dev, staging).

Avantages :

• Réutilisation d'un seul ClusterRole pour plusieurs namespaces
• Gestion centralisée des permissions
• Évite la duplication de Roles

Prérequis : Accès administrateur au cluster Kubernetes

# Les Namespaces dans lesquels vérouiller l'utilisateur
NAMESPACE1="my-namespace"
NAMESPACE2="my-namespace-bis"
 
# Le nom du ServiceAccount à créer
SERVICE_ACCOUNT="my-service-account"
 
# Le nom du ClusterRole à créer
CLUSTERROLE="${SERVICE_ACCOUNT}-role"
 
# Le nom du RoleBinding à créer
ROLEBINDING="${CLUSTERROLE}-binding"
 
# Le nom du Context pour le fichier kubeconfig
CLUSTER_NAME=$(kubectl config view --minify -o jsonpath='{.clusters[0].name}')
CONTEXT="${SERVICE_ACCOUNT}-multi-ns-${CLUSTER_NAME}"

kubectl create namespace ${NAMESPACE1}
kubectl create namespace ${NAMESPACE2}

kubectl -n default create serviceaccount ${SERVICE_ACCOUNT}

cat <<EOF > payload.yml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: ${CLUSTERROLE}
rules:
  - apiGroups: ["*"]
    resources: ["*"]
    verbs: ["*"]
EOF
 
kubectl apply -f payload.yml

cat <<EOF > payload.yml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: ${ROLEBINDING}-${NAMESPACE1}
  namespace: ${NAMESPACE1}
subjects:
  - kind: ServiceAccount
    name: ${SERVICE_ACCOUNT}
    namespace: default
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: ${CLUSTERROLE}
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: ${ROLEBINDING}-${NAMESPACE2}
  namespace: ${NAMESPACE2}
subjects:
  - kind: ServiceAccount
    name: ${SERVICE_ACCOUNT}
    namespace: default
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: ${CLUSTERROLE}
EOF
 
kubectl apply -f payload.yml

# Le Certificat du Cluster
CLUSTER_CA_CRT=$(kubectl config view --minify --flatten -o=jsonpath='{.clusters[*].cluster.certificate-authority-data}' 2> /dev/null)
 
# Le Nom du Cluster
CLUSTER_NAME=$(kubectl config view --minify --flatten -o=jsonpath='{.clusters[*].name}')
 
# Le Endpoint API du Cluster
CLUSTER_ENDPOINT=$(kubectl config view --minify --flatten -o=jsonpath='{.clusters[*].cluster.server}')

# Le Secret associé au ServiceAccount
SERVICE_ACCOUNT_SECRET=$(kubectl -n default get secrets -o jsonpath="{.items[?(@.metadata.annotations['kubernetes\.io/service-account\.name']=='${SERVICE_ACCOUNT}')].metadata.name}" 2> /dev/null)
 
# Le Token caché dans le Secret
SERVICE_ACCOUNT_TOKEN=$(kubectl -n default get secret ${SERVICE_ACCOUNT_SECRET} -o jsonpath="{.data['token']}" 2> /dev/null | base64 --decode)

cat <<EOF > kubeconfig
apiVersion: v1
kind: Config
users:
  - name: ${SERVICE_ACCOUNT}
    user:
      token: ${SERVICE_ACCOUNT_TOKEN}
clusters:
  - name: ${CLUSTER_NAME}
    cluster:
      certificate-authority-data: ${CLUSTER_CA_CRT}
      server: ${CLUSTER_ENDPOINT}
contexts:
  - name: ${CONTEXT}
    context:
      cluster: ${CLUSTER_NAME}
      namespace: ${NAMESPACE1}
      user: ${SERVICE_ACCOUNT}
current-context: ${CONTEXT}
EOF

# Commande en erreur : vous n'avez pas accès au NS kube-system
kubectl --kubeconfig=./kubeconfig -n kube-system get all
 
# Commandes Ok : accès aux deux namespaces autorisés
kubectl --kubeconfig=./kubeconfig -n ${NAMESPACE1} get all
kubectl --kubeconfig=./kubeconfig -n ${NAMESPACE2} get all

Bonnes pratiques

Principe du moindre privilège

Exemple de Role restrictif :

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

Séparation des responsabilités

• Développeurs : Accès en lecture/écriture sur leurs namespaces (edit role)
• Ops/SRE : Accès administrateur multi-namespaces avec RoleBindings ciblés
• Administrateurs : Seul le strict minimum devrait avoir cluster-admin

Utiliser les Roles prédéfinis

Privilégiez les ClusterRoles prédéfinis quand ils correspondent à vos besoins :

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: developers-edit
  namespace: dev
subjects:
  - kind: Group
    name: dev-team
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: edit  # Role prédéfini Kubernetes
  apiGroup: rbac.authorization.k8s.io

ServiceAccounts dédiés

Créez un ServiceAccount par application avec des permissions spécifiques :

apiVersion: v1
kind: ServiceAccount
metadata:
  name: app-backend
  namespace: production

Audit et révision

• Lister les RoleBindings :

  Terminal

  kubectl get rolebindings --all-namespaces

• Vérifier les permissions d'un ServiceAccount :

  Terminal

  kubectl auth can-i --list --as=system:serviceaccount:my-namespace:my-sa

• Tester une action spécifique :

  Terminal

  kubectl auth can-i create pods --as=system:serviceaccount:my-namespace:my-sa -n my-namespace

Gestion des tokens

# Créer un token avec expiration (1 heure)
kubectl create token my-service-account -n my-namespace --duration=1h
 
# Créer un token avec expiration longue (1 an)
kubectl create token my-service-account -n my-namespace --duration=8760h

Éviter les ClusterRoleBindings inutiles

Préférez les RoleBindings même avec des ClusterRoles pour limiter la portée :

# ✅ Bon : ClusterRole appliqué à un namespace
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: dev-team-binding
  namespace: dev
roleRef:
  kind: ClusterRole
  name: edit
  apiGroup: rbac.authorization.k8s.io
subjects:
  - kind: Group
    name: dev-team
    apiGroup: rbac.authorization.k8s.io

Troubleshooting

Erreur : "User cannot list resource"

Symptôme :

Error from server (Forbidden): pods is forbidden: User "system:serviceaccount:my-ns:my-sa" cannot list resource "pods"

Causes possibles :

1. Le ServiceAccount n'a pas les permissions nécessaires
2. Le RoleBinding n'est pas dans le bon namespace
3. Le verb "list" n'est pas accordé

Solution :

# Vérifier les permissions actuelles
kubectl auth can-i list pods --as=system:serviceaccount:my-ns:my-sa -n my-ns
 
# Lister les RoleBindings du namespace
kubectl get rolebindings -n my-ns
 
# Décrire le RoleBinding pour voir les permissions
kubectl describe rolebinding <name> -n my-ns

Erreur : "Unable to connect to the server"

Symptôme :

Unable to connect to the server: x509: certificate signed by unknown authority

Causes :

• Le certificat CA du cluster est manquant ou invalide dans le kubeconfig

Solution :

# Régénérer le certificat CA
CLUSTER_CA_CRT=$(kubectl config view --minify --flatten -o=jsonpath='{.clusters[*].cluster.certificate-authority-data}')
# Mettre à jour le kubeconfig avec le bon certificat

ServiceAccount non trouvé dans le Pod

Symptôme :

Error: secrets "default-token-xxxxx" not found

Causes :

• Le ServiceAccount spécifié n'existe pas dans le Namespace
• À partir de K8s 1.24, les tokens ne sont plus créés automatiquement

Solution :

# Vérifier que le ServiceAccount existe
kubectl get sa -n my-namespace
 
# Créer le ServiceAccount si nécessaire
kubectl create sa my-service-account -n my-namespace
 
# Pour K8s 1.24+, créer le token manuellement
kubectl create token my-service-account -n my-namespace

Permissions insuffisantes malgré un ClusterRole

Symptôme : Un ClusterRole est défini mais l'utilisateur n'a pas les permissions.

Causes :

• Manque de RoleBinding ou ClusterRoleBinding pour lier le ClusterRole au sujet

Solution :

# Vérifier les bindings existants
kubectl get clusterrolebindings | grep <cluster-role-name>
kubectl get rolebindings --all-namespaces | grep <cluster-role-name>
 
# Créer le binding manquant
kubectl create rolebinding my-binding --clusterrole=<role-name> --serviceaccount=<ns>:<sa-name> -n <namespace>

Impossible de modifier un RoleBinding

Symptôme :

Error: roleRef is immutable

Causes :

• Le champ roleRef d'un RoleBinding ne peut pas être modifié après création

Solution :

# Supprimer et recréer le RoleBinding
kubectl delete rolebinding <name> -n <namespace>
kubectl create rolebinding <name> --role=<new-role> --serviceaccount=<ns>:<sa> -n <namespace>

Commandes utiles récapitulatives

# Lister tous les Roles d'un namespace
kubectl get roles -n <namespace>
 
# Lister tous les ClusterRoles
kubectl get clusterroles
 
# Lister tous les RoleBindings
kubectl get rolebindings --all-namespaces
 
# Lister tous les ClusterRoleBindings
kubectl get clusterrolebindings
 
# Décrire les permissions d'un Role
kubectl describe role <role-name> -n <namespace>
 
# Vérifier si un utilisateur peut effectuer une action
kubectl auth can-i <verb> <resource> --as=<user> -n <namespace>
 
# Voir toutes les permissions d'un utilisateur
kubectl auth can-i --list --as=<user> -n <namespace>
 
# Créer un Role rapidement
kubectl create role pod-reader --verb=get,list,watch --resource=pods -n <namespace>
 
# Créer un RoleBinding rapidement
kubectl create rolebinding read-pods --role=pod-reader --serviceaccount=<ns>:<sa> -n <namespace>
 
# Créer un ServiceAccount
kubectl create serviceaccount <sa-name> -n <namespace>
 
# Créer un token pour un ServiceAccount (K8s 1.24+)
kubectl create token <sa-name> -n <namespace> --duration=<duration>
 
# Supprimer un RoleBinding
kubectl delete rolebinding <name> -n <namespace>