website/content/fr/docs/reference/access-authn-authz/rbac.md

title	content_type	aliases	weight
Utilisation de l'autorisation RBAC	concept	/fr/rbac/	70

Le contrôle d'accès basé sur les rôles (RBAC) est une méthode permettant de réguler l'accès aux ressources informatiques ou réseau en fonction des rôles des utilisateurs individuels au sein de votre organisation.

L'autorisation RBAC utilise le rbac.authorization.k8s.io {{< glossary_tooltip text="API group" term_id="api-group" >}} pour prendre les décisions d'autorisation, ce qui vous permet de configurer dynamiquement les politiques via l'API Kubernetes.

Pour activer RBAC, démarrez le {{< glossary_tooltip text="API server" term_id="kube-apiserver" >}} avec l'indicateur --authorization-mode défini sur une liste séparée par des virgules qui inclut RBAC ; par exemple :

kube-apiserver --authorization-mode=Example,RBAC --other-options --more-options

Objets de l'API

L'API RBAC déclare quatre types d'objets Kubernetes : Role, ClusterRole, RoleBinding et ClusterRoleBinding. Vous pouvez décrire les objets, ou les modifier, en utilisant des outils tels que kubectl, comme tout autre objet Kubernetes.

{{< caution >}} Ces objets, de par leur conception, imposent des restrictions d'accès. Si vous apportez des modifications à un cluster au fur et à mesure de votre apprentissage, consultez prévention de l'escalade des privilèges et amorçage pour comprendre comment ces restrictions peuvent vous empêcher d'effectuer certaines modifications. {{< /caution >}}

Role and ClusterRole

Un Role ou ClusterRole RBAC contient des règles qui représentent un ensemble de permissions. Les permissions sont purement additives (il n'y a pas de "deny" règles).

A Role always sets permissions within a particular {{< glossary_tooltip text="namespace" term_id="namespace" >}}; when you create a Role, you have to specify the namespace it belongs in. Un rôle définit toujours les autorisations dans un {{< glossary_tooltip text="namespace" term_id="namespace" >}} particulier; lorsque vous créez un Role, vous devez spécifier le namespace auquel il appartient.

ClusterRole, by contrast, is a non-namespaced resource. The resources have different names (Role and ClusterRole) because a Kubernetes object always has to be either namespaced or not namespaced; it can't be both. ClusterRole, en revanche, est une ressource sans namespace. Les ressources portent des noms différents (Role et ClusterRole) parce qu'un objet Kubernetes doit toujours être soit avec un namespace ou soit sans namespace; Il ne peut pas être les deux.

Les ClusterRoles ont plusieurs usages. Vous pouvez utiliser une ClusterRole pour :

1. définir les autorisations sur les ressources avec un namespace et obtenir l'accès à l'intérieur d'un ou plusieurs namespaces
2. définir les permissions sur les ressources avec un namespace et obtenir l'accès à travers tous les namespaces.
3. définir les permissions sur les ressources à l'échelle du cluster

Si vous souhaitez définir un rôle au sein d'un namespace, utilisez un Role; si vous souhaitez définir un rôle à l'échelle du cluster, utilisez un ClusterRole.

Role example

Voici un exemple de rôle dans le namespace "default" qui peut être utilisé pour accorder un accès en lecture aux {{< glossary_tooltip text="pods" term_id="pod" >}}:

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"]

ClusterRole example

Une ClusterRole peut être utilisée pour accorder les mêmes permissions qu'un rôle. Étant donné que les ClusterRoles sont à l'échelle des clusters, vous pouvez également les utiliser pour accorder l'accès à :

• des ressources à l'échelle du cluster (comme {{< glossary_tooltip text="nodes" term_id="node" >}})

• des endpoints non liés aux ressources (comme /healthz)

• des ressources à namespaces (comme les pods), dans tous les namespaces.

  Par exemple : vous pouvez utiliser un ClusterRole pour autoriser un utilisateur particulier à exécuter kubectl get pods --all-namespaces

Voici un exemple de ClusterRole qui peut être utilisé pour accorder un accès en lecture à {{< glossary_tooltip text="secrets" term_id="secret" >}} dans un namespace particulier, ou dans tous les namespaces (selon la façon dont il est lié) :

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  # "namespace" omitted since ClusterRoles are not namespaced
  name: secret-reader
rules:
- apiGroups: [""]
  #
  # at the HTTP level, the name of the resource for accessing Secret
  # objects is "secrets"
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

Le nom d'un Role ou d'un objet ClusterRole doit être un nom de segment de chemin valide.

RoleBinding et ClusterRoleBinding

Un RoleBinding accorde les permissions définies dans un rôle à un utilisateur ou à un ensemble d'utilisateurs. Il contient une liste de sujets (utilisateurs, groupes, ou comptes de service), et une référence au rôle accordé. Un RoleBinding accorde des permissions dans un namespace spécifique alors qu'un ClusterRoleBinding accorde cet accès à l'échelle du cluster.

Le nom d'un objet RoleBinding ou ClusterRoleBinding doit être un nom de segment de chemin valide.

Exemples de RoleBinding

Voici un exemple de RoleBinding qui accorde le Role "pod-reader" à l'utilisateur "jane" dans le namespace "default". Ceci permet à "jane" de lire les pods dans le namespace "default".

apiVersion: rbac.authorization.k8s.io/v1
# This role binding allows "jane" to read pods in the "default" namespace.
# You need to already have a Role named "pod-reader" in that namespace.
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
# You can specify more than one "subject"
- kind: User
  name: jane # "name" is case sensitive
  apiGroup: rbac.authorization.k8s.io
roleRef:
  # "roleRef" specifies the binding to a Role / ClusterRole
  kind: Role #this must be Role or ClusterRole
  name: pod-reader # this must match the name of the Role or ClusterRole you wish to bind to
  apiGroup: rbac.authorization.k8s.io

Un RoleBinding peut également faire référence à un ClusterRole pour accorder les permissions définies dans ce ClusterRole aux ressources du namespace du RoleBinding. Ce type de référence vous permet de définir un ensemble de rôles communs à l'ensemble de votre cluster, puis de les réutiliser dans plusieurs namespaces.

Par exemple, même si le RoleBinding suivant fait référence à un ClusterRole, "dave" (le sujet, sensible à la casse) ne pourra lire que les Secrets dans le namespace "development", car le namespace du RoleBinding (dans son metadata) est "development".

apiVersion: rbac.authorization.k8s.io/v1
# This role binding allows "dave" to read secrets in the "development" namespace.
# You need to already have a ClusterRole named "secret-reader".
kind: RoleBinding
metadata:
  name: read-secrets
  #
  # The namespace of the RoleBinding determines where the permissions are granted.
  # This only grants permissions within the "development" namespace.
  namespace: development
subjects:
- kind: User
  name: dave # Name is case sensitive
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

Exemple de ClusterRoleBinding

Pour accorder des permissions sur l'ensemble d'un cluster, vous pouvez utiliser un ClusterRoleBinding. Le ClusterRoleBinding suivant permet à tout utilisateur du groupe "manager" de lire secrets dans n'importe quel namespace.

apiVersion: rbac.authorization.k8s.io/v1
# This cluster role binding allows anyone in the "manager" group to read secrets in any namespace.
kind: ClusterRoleBinding
metadata:
  name: read-secrets-global
subjects:
- kind: Group
  name: manager # Name is case sensitive
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

Après avoir créé un lien, vous ne pouvez pas modifier le Role ou le ClusterRole auquel il fait référence. Si vous essayez de modifier le roleRef d'un lien, vous obtenez une erreur de validation. Si vous souhaitez changer le roleRef d'un lien, vous devez supprimer l'objet binding et en créer un autre.

Il y a deux raisons à cette restriction :

1. Rendre roleRef immuable permet d'accorder à quelqu'un la permission update sur un objet de liaison existant, afin qu'il puisse gérer la liste des sujets, sans pouvoir changer le rôle qui est accordé à ces sujets.
2. Un lien vers un rôle différent est un lien fondamentalement différent. Le fait d'exiger qu'un lien soit supprimé/créé afin de modifier le roleRef garantit que la liste complète des sujets dans le binding est destinée à recevoir le nouveau rôle (par opposition à l'activation ou à la modification accidentelle uniquement du roleRef sans vérifier que tous les sujets existants doivent recevoir les permissions du nouveau rôle).

L'utilitaire de ligne de commande kubectl auth reconcile crée ou met à jour un fichier manifeste contenant des objets RBAC, et gère la suppression et la recréation des objets de liaison si nécessaire pour modifier le rôle auquel ils se réfèrent. Voir utilisation de la commande et exemples pour plus d'informations.

Référence aux ressources

Dans l'API Kubernetes, la plupart des ressources sont représentées et accessibles à l'aide d'une chaîne de caractères de leur nom d'objet, comme pods pour un Pod. RBAC fait référence aux ressources en utilisant exactement le même nom que celui qui apparaît dans l'URL du endpoint de l'API concerné. Certaines API Kubernetes impliquent une subresource, comme les logs d'un Pod. Une requête pour les logs d'un Pod ressemble à ceci :

GET /api/v1/namespaces/{namespace}/pods/{name}/log

Dans ce cas, pods est le namespaced ressource pour les ressources Pods, et log est une sous-ressource de pods. Pour représenter cela dans un rôle RBAC, utilisez une barre oblique (/) pour délimiter la ressource et la sous-ressource. Pour permettre à un sujet de lire pods et d'accéder également à la sous-ressource log pour chacun de ces Pods, vous écrivez :

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

Vous pouvez également faire référence à des ressources par leur nom pour certaines demandes par le biais de la liste resourceNames. Lorsque cela est spécifié, les demandes peuvent être limitées à des instances individuelles d'une ressource. Voici un exemple qui limite son sujet seulement à get ou update une {{< glossary_tooltip term_id="ConfigMap" >}} nommée my-configmap:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: configmap-updater
rules:
- apiGroups: [""]
  #
  # at the HTTP level, the name of the resource for accessing ConfigMap
  # objects is "configmaps"
  resources: ["configmaps"]
  resourceNames: ["my-configmap"]
  verbs: ["update", "get"]

{{< note >}} Vous ne pouvez pas restreindre les demandes create ou deletecollection par leur nom de ressource. Pour create, cette limitation est due au fait que le nom du nouvel objet peut ne pas être connu au moment de l'autorisation. Si vous limitez list ou watch par le nom de la ressource, les clients doivent inclure un sélecteur de champ metadata.name dans leur demande de list ou watch qui correspond au nom de la ressource spécifiée afin d'être autorisés. Par exemple, kubectl get configmaps --field-selector=metadata.name=my-configmap {{< /note >}}

Plutôt que de faire référence à des ressources et des verbes individuels, vous pouvez utiliser le symbole astérisque * pour faire référence à tous ces objets. Pour les nonResourceURLs, vous pouvez utiliser le symbole astérisque * comme suffixe de correspondance glob et pour les apiGroups et les resourceNames un ensemble vide signifie que tout est autorisé. Voici un exemple qui autorise l'accès pour effectuer toute action actuelle et future sur toutes les ressources actuelles et futures (remarque, ceci est similaire au rôle cluster-admin intégré).

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: example.com-superuser  # DO NOT USE THIS ROLE, IT IS JUST AN EXAMPLE
rules:
- apiGroups: ["example.com"]
  resources: ["*"]
  verbs: ["*"]

{{< caution >}} L'utilisation d'astérisques dans les entrées de ressources et de verbes peut entraîner l'octroi d'un accès trop permissif à des ressources sensibles. Par exemple, si un nouveau type de ressource est ajouté, ou si une nouvelle sous-ressource est ajoutée, ou si un nouveau verbe personnalisé est coché, l'utilisation de l'astérisque accorde automatiquement l'accès, ce qui peut être indésirable. Le principe du moindre privilège doit être employé, en utilisant des ressources et des verbes spécifiques pour garantir que seules les autorisations nécessaires au bon fonctionnement de la charge de travail sont appliquées. {{< /caution >}}

ClusterRoles agrégés

Vous pouvez agréger plusieurs ClusterRoles en un seul ClusterRole combiné. Un contrôleur, qui s'exécute dans le cadre du plan de contrôle du cluster, recherche les objets ClusterRole avec une aggregationRule définie. L'aggregationRule définit un label {{< glossary_tooltip text="selector" term_id="selector" >}} que le contrôleur utilise pour faire correspondre d'autres objets ClusterRole qui devraient être combinés dans le champ de règles de celui-ci.

{{< caution >}} Le plan de contrôle écrase toutes les valeurs que vous spécifiez manuellement dans le champ rules d'un ClusterRole agrégé. Si vous souhaitez modifier ou ajouter des règles, faites-le dans les objets ClusterRole qui sont sélectionnés par l'aggregationRule. {{< /caution >}}

Voici un exemple de ClusterRole agrégé :

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: monitoring
aggregationRule:
  clusterRoleSelectors:
  - matchLabels:
      rbac.example.com/aggregate-to-monitoring: "true"
rules: [] # The control plane automatically fills in the rules

Si vous créez un nouvel ClusterRole qui correspond au sélecteur d'étiquette d'une ClusterRole agrégé existant, ce changement déclenche l'ajout des nouvelles règles dans le ClusterRole agrégé. Voici un exemple qui ajoute des règles au ClusterRole "monitoring", en créant un autre ClusterRole étiqueté rbac.example.com/aggregate-to-monitoring: true.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: monitoring-endpoints
  labels:
    rbac.example.com/aggregate-to-monitoring: "true"
# When you create the "monitoring-endpoints" ClusterRole,
# the rules below will be added to the "monitoring" ClusterRole.
rules:
- apiGroups: [""]
  resources: ["services", "endpointslices", "pods"]
  verbs: ["get", "list", "watch"]

Les rôles par défaut destinés aux utilisateurs utilisent l'agrégation ClusterRole. Cela vous permet, en tant qu'administrateur de cluster, d'inclure des règles pour les ressources personnalisées, telles que celles servies par {{< glossary_tooltip term_id="CustomResourceDefinition" text="CustomResourceDefinitions" >}} ou les serveurs API agrégés, afin d'étendre les rôles par défaut.

Par exemple : les ClusterRoles suivants permettent aux rôles par défaut "admin" et "edit" de gérer la ressource personnalisée nommée CronTab, tandis que le rôle "view" ne peut effectuer que des actions de lecture sur les ressources CronTab. Vous pouvez supposer que les objets CronTab sont nommés "crontabs" dans les URLs telles que vues par le serveur API.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: aggregate-cron-tabs-edit
  labels:
    # Add these permissions to the "admin" and "edit" default roles.
    rbac.authorization.k8s.io/aggregate-to-admin: "true"
    rbac.authorization.k8s.io/aggregate-to-edit: "true"
rules:
- apiGroups: ["stable.example.com"]
  resources: ["crontabs"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: aggregate-cron-tabs-view
  labels:
    # Add these permissions to the "view" default role.
    rbac.authorization.k8s.io/aggregate-to-view: "true"
rules:
- apiGroups: ["stable.example.com"]
  resources: ["crontabs"]
  verbs: ["get", "list", "watch"]

Role examples

Les exemples suivants sont des extraits d'objets Role ou ClusterRole, montrant uniquement la section rules.

Autoriser la lecture des ressources "pods" dans l' {{< glossary_tooltip text="API Group" term_id="api-group" >}} central :

rules:
- apiGroups: [""]
  #
  # at the HTTP level, the name of the resource for accessing Pod
  # objects is "pods"
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

Autoriser la lecture/écriture des Déploiements (au niveau HTTP : objets avec "deployments" dans la partie ressource de leur URL) dans les groupes API "apps" :

rules:
- apiGroups: ["apps"]
  #
  # at the HTTP level, the name of the resource for accessing Deployment
  # objects is "deployments"
  resources: ["deployments"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

Autorise la lecture des Pods dans le groupe d'API central, ainsi que de lire ou d'écrire des ressources Job dans le groupe d'API "batch" :

rules:
- apiGroups: [""]
  #
  # at the HTTP level, the name of the resource for accessing Pod
  # objects is "pods"
  resources: ["pods"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["batch"]
  #
  # at the HTTP level, the name of the resource for accessing Job
  # objects is "jobs"
  resources: ["jobs"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

Autoriser la lecture d'un ConfigMap nommé "my-config" (doit être lié avec un RoleBinding pour limiter à un seul ConfigMap dans un seul namespace).

rules:
- apiGroups: [""]
  #
  # at the HTTP level, the name of the resource for accessing ConfigMap
  # objects is "configmaps"
  resources: ["configmaps"]
  resourceNames: ["my-config"]
  verbs: ["get"]

Autoriser la lecture des ressources "nodes"dans le groupe central (parce qu'un Node est à l'échelle-du-cluster, il doit être dans un ClusterRole lié à un ClusterRoleBinding pour être effectif) :

rules:
- apiGroups: [""]
  #
  # at the HTTP level, the name of the resource for accessing Node
  # objects is "nodes"
  resources: ["nodes"]
  verbs: ["get", "list", "watch"]

Autorise les requêtes GET et POST vers l'endpoint non ressource /healthz et tous les subpaths (doit être dans un ClusterRole lié à un ClusterRoleBinding pour être effectif) :

rules:
- nonResourceURLs: ["/healthz", "/healthz/*"] # '*' in a nonResourceURL is a suffix glob match
  verbs: ["get", "post"]

Référence à des subjects

Un RoleBinding ou ClusterRoleBinding lie un rôle à des sujets. Les sujets peuvent être des groupes, des utilisateurs ou des {{< glossary_tooltip text="ServiceAccounts" term_id="service-account" >}}.

Kubernetes représente les noms d'utilisateurs sous forme de chaînes de caractères. Il peut s'agir: de noms simples, tels que "alice"; de noms de style e-mail, tels que "bob@example.com"; ou des IDs d'utilisateur numériques représentés sous forme de chaîne de caractères. Il vous appartient, en tant qu'administrateur de cluster, de configurer les modules d'authentification afin que l'authentification produise des noms d'utilisateur dans le format que vous souhaitez.

{{< caution >}} Le préfixe system: est réservé à l'utilisation du système Kubernetes, vous devez donc vous assurer que vous n'avez pas d'utilisateurs ou de groupes dont le nom commence par system: par accident. En dehors de ce préfixe spécial, le système d'autorisation RBAC ne requiert aucun format pour les noms d'utilisateurs. {{< /caution >}}

Dans Kubernetes, les modules Authenticator fournissent des informations sur les groupes. Les groupes, comme les utilisateurs, sont représentés sous forme de chaînes de caractères et cette chaîne n'a aucune exigence de format, si ce n'est que le préfixe system: est réservé.

Les ServiceAccounts ont des noms préfixés par system:serviceaccount:, et appartiennent à des groupes qui ont des noms préfixés par system:serviceaccounts:.

{{< note >}}

• system:serviceaccount: (singulier) est le préfixe pour les noms d'utilisateur des comptes de service.
• system:serviceaccounts: (pluriel) est le préfixe pour les groupes de comptes de service. {{< /note >}}

Exemples de RoleBinding

Les exemples suivants sont des extraits de RoleBinding qui ne montrent que la section des subjects.

Pour un utilisateur nommé alice@example.com :

subjects:
- kind: User
  name: "alice@example.com"
  apiGroup: rbac.authorization.k8s.io

Pour un groupe nommé frontend-admins:

subjects:
- kind: Group
  name: "frontend-admins"
  apiGroup: rbac.authorization.k8s.io

Pour le compte de service par défaut dans le namespace "kube-system" :

subjects:
- kind: ServiceAccount
  name: default
  namespace: kube-system

Pour tous les comptes de service dans le namespace "qa" :

subjects:
- kind: Group
  name: system:serviceaccounts:qa
  apiGroup: rbac.authorization.k8s.io

Pour tous les comptes de service dans n'importe quel namespace :

subjects:
- kind: Group
  name: system:serviceaccounts
  apiGroup: rbac.authorization.k8s.io

Pour tous les utilisateurs authentifiés :

subjects:
- kind: Group
  name: system:authenticated
  apiGroup: rbac.authorization.k8s.io

Pour tous les utilisateurs non authentifiés :

subjects:
- kind: Group
  name: system:unauthenticated
  apiGroup: rbac.authorization.k8s.io

Pour tous les utilisateurs :

subjects:
- kind: Group
  name: system:authenticated
  apiGroup: rbac.authorization.k8s.io
- kind: Group
  name: system:unauthenticated
  apiGroup: rbac.authorization.k8s.io

Rôles par défaut et liaisons de rôles

Les serveurs API créent un ensemble d'objets ClusterRole et ClusterRoleBinding par défaut. Beaucoup d'entre eux sont préfixés system:, ce qui indique que la ressource est directement gérée par le plan de contrôle du cluster. Tous les ClusterRoles et ClusterRoleBindings par défaut sont étiquetés avec kubernetes.io/bootstrapping=rbac-defaults.

{{< caution >}} Faites attention lorsque vous modifiez les ClusterRoles et les ClusterRoleBindings dont les noms ont un préfixe system:. Les modifications apportées à ces ressources peuvent entraîner des clusters non fonctionnels. {{< /caution >}}

Auto-reconciliation

À chaque démarrage, le serveur API met à jour les rôles de cluster par défaut avec toutes les permissions manquantes, et met à jour les liaisons de rôles de cluster par défaut avec tous les sujets manquants. Cela permet au cluster de réparer les modifications accidentelles, et aide à maintenir les rôles et les liaisons de rôles à jour lorsque les autorisations et les sujets changent dans les nouvelles versions de Kubernetes.

Be aware that missing default permissions and subjects can result in non-functional clusters. Pour ne pas participer à cette reconciliation, définissez l'annotation rbac.authorization.kubernetes.io/autoupdate sur un rôle ou un rolebinding de cluster par défaut sur false. Sachez que les autorisations et les sujets par défaut manquants peuvent entraîner des clusters non fonctionnels.

L'auto-réconciliation est activée par défaut si l'autorisateur RBAC est actif.

Rôles de détection de l'API

Les liaisons de rôles par défaut autorisent les utilisateurs authentifiés et non authentifiés à lire les informations de l'API qui sont jugées sûres pour être accessibles au public (y compris les CustomResourceDefinitions). Pour désactiver l'accès anonyme non authentifié, ajoutez --anonymous-auth=false à la configuration du serveur d'API.

Pour afficher la configuration de ces rôles via kubectl, exécutez :

kubectl get clusterroles system:discovery -o yaml

{{< note >}} Si vous modifiez ce ClusterRole, vos modifications seront écrasées au redémarrage du serveur API via l'auto-reconciliation. Pour éviter cet écrasement, ne modifiez pas manuellement le rôle ou désactivez l'auto-reconciliation. {{< /note >}}

Rôles de détection de l'API RBAC de Kubernetes

ClusterRole par défaut	ClusterRoleBinding par défaut	Description
system:basic-user	system:authenticated group	Permet à un utilisateur d'accéder en lecture seule aux informations de base le concernant. Avant la v1.14, ce rôle était également lié à system:unauthenticated par défaut.
system:discovery	system:authenticated group	Permet un accès en lecture seule aux points de terminaison de découverte d'API nécessaires pour découvrir et négocier un niveau d'API. Avant la v1.14, ce rôle était également lié à l'option system:unauthenticated par défaut.
system:public-info-viewer	system:authenticated and system:unauthenticated groups	Permet un accès en lecture seule à des informations non sensibles sur le cluster. Introduit dans Kubernetes v1.14.

Rôle des utilisateurs

Certains des ClusterRoles par défaut ne sont pas précédés du préfixe system:. Il s'agit de rôles destinés à l'utilisateur. Ils incluent les rôles de super-utilisateur (cluster-admin), les rôles destinés à être accordés à l'échelle du cluster à l'aide de ClusterRoleBindings, et les rôles destinés à être accordés dans des namespaces particuliers à l'aide de RoleBindings (admin, edit, view).

Les ClusterRoles des utilisateurs utilisent l'agrégation de ClusterRole pour permettre aux administrateurs d'inclure des règles pour les ressources personnalisées sur ces ClusterRoles. Pour ajouter des règles aux rôles admin, edit, ou view, créez une ClusterRole avec un ou plusieurs des labels suivants :

metadata:
  labels:
    rbac.authorization.k8s.io/aggregate-to-admin: "true"
    rbac.authorization.k8s.io/aggregate-to-edit: "true"
    rbac.authorization.k8s.io/aggregate-to-view: "true"

ClusterRole par défaut	ClusterRoleBinding par défaut	Description
cluster-admin	system:masters groupe	Permet au super-utilisateur d'effectuer n'importe quelle action sur n'importe quelle ressource. Lorsqu'il est utilisé dans un ClusterRoleBinding, il donne un contrôle total sur chaque ressource dans le cluster et dans tous les namespaces. Lorsqu'il est utilisé dans un RoleBinding, il donne un contrôle total sur chaque ressource dans le namespace du role binding, y compris le namespace lui-même.
admin	Aucun	Permet l'accès administrateur, destiné à être accordé au sein d'un espace de nom en utilisant un RoleBinding. S'il est utilisé dans un RoleBinding, il permet un accès en lecture/écriture à la plupart des ressources d'un namespace, y compris la possibilité de créer des rôles et des liaisons de rôles dans le namespace. Ce rôle ne permet pas l'accès en écriture au quota de ressources ou au namespace lui-même. Ce rôle ne permet pas non plus l'accès en écriture aux EndpointSlices (ou Endpoints) dans les clusters créés à l'aide de Kubernetes v1.22+. Plus d'informations sont disponibles dans la section "Accès en écriture pour les EndpointSlices et les Endpoints".
edit	Aucun	Permet l'accès en lecture/écriture à la plupart des objets d'un namespace. Ce rôle ne permet pas de visualiser ou de modifier les rôles ou les liaisons de rôles. Cependant, ce rôle permet d'accéder aux Secrets et d'exécuter des Pods comme n'importe quel ServiceAccount du namespace, il peut donc être utilisé pour obtenir les niveaux d'accès API de n'importe quel ServiceAccount du namespace. Ce rôle ne permet pas non plus d'accéder en écriture aux EndpointSlices (ou Endpoints) dans les clusters créés à l'aide de Kubernetes v1.22+. Plus d'informations sont disponibles dans la section "Write Access for EndpointSlices and Endpoints".
view	Aucun	Permet un accès en lecture seule pour voir la plupart des objets d'un namespace. Il ne permet pas de visualiser les rôles ou les liens entre les rôles. Ce rôle ne permet pas de visualiser les Secrets, car la lecture du contenu des Secrets permet d'accéder aux informations d'identification du ServiceAccount dans le namespace, ce qui permettrait d'accéder à l'API en tant que tout ServiceAccount dans l'espace de noms (une forme d'escalade des privilèges). Ce rôle ne permet pas de consulter les secrets, car la lecture du contenu des secrets permet d'accéder aux informations d'identification du ServiceAccount dans le namespace, ce qui permettrait d'accéder à l'API en tant que n'importe quel ServiceAccount dans le namespace (une forme d'escalade des privilèges).

Rôles des composants de base

ClusterRole par défaut	ClusterRoleBinding par défaut	Description
system:kube-scheduler	utilisateur system:kube-scheduler	Permet l'accès aux ressources requises par le composant {{< glossary_tooltip term_id="kube-scheduler" text="scheduler" >}}.
system:volume-scheduler	system:kube-scheduler user	Permet l'accès aux ressources de volume requises par le composant kube-scheduler.
system:kube-controller-manager	utilisateur system:kube-controller-manager	Permet l'accès aux ressources requises par le composant {{< glossary_tooltip term_id="kube-controller-manager" text="gestionnaire de contrôleur" >}}. Les autorisations requises par les contrôleurs individuels sont détaillées dans les rôles des contrôleurs.
system:node	Aucun	Permet l'accès aux ressources requises par le kubelet, y compris l'accès en lecture à tous les secrets, et l'accès en écriture à tous les objets d'état des pods. Vous devriez utiliser le Node authorizer et le plugin d'admission NodeRestriction au lieu du rôle system:node, et autoriser l'octroi d'un accès API aux kubelets en fonction des Pods programmés pour s'exécuter sur eux. Le rôle system:node n'existe que pour la compatibilité avec les clusters Kubernetes mis à niveau à partir de versions antérieures à la v1.8.
system:node-proxier	system:kube-proxy user	Permet l'accès aux ressources requises par le composant {{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}}.

Other component roles

Default ClusterRole	Default ClusterRoleBinding	Description
system:auth-delegator	None	Allows delegated authentication and authorization checks. This is commonly used by add-on API servers for unified authentication and authorization.
system:heapster	None	Role for the Heapster component (deprecated).
system:kube-aggregator	None	Role for the kube-aggregator component.
system:kube-dns	kube-dns service account in the kube-system namespace	Role for the kube-dns component.
system:kubelet-api-admin	None	Allows full access to the kubelet API.
system:node-bootstrapper	None	Allows access to the resources required to perform kubelet TLS bootstrapping.
system:node-problem-detector	None	Role for the node-problem-detector component.
system:persistent-volume-provisioner	None	Allows access to the resources required by most dynamic volume provisioners.
system:monitoring	system:monitoring group	Allows read access to control-plane monitoring endpoints (i.e. {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}} liveness and readiness endpoints (/healthz, /livez, /readyz), the individual health-check endpoints (/healthz/*, /livez/*, /readyz/*), and /metrics). Note that individual health check endpoints and the metric endpoint may expose sensitive information.

Roles for built-in controllers

The Kubernetes {{< glossary_tooltip term_id="kube-controller-manager" text="controller manager" >}} runs {{< glossary_tooltip term_id="controller" text="controllers" >}} that are built in to the Kubernetes control plane. When invoked with --use-service-account-credentials, kube-controller-manager starts each controller using a separate service account. Corresponding roles exist for each built-in controller, prefixed with system:controller:. If the controller manager is not started with --use-service-account-credentials, it runs all control loops using its own credential, which must be granted all the relevant roles. These roles include:

• system:controller:attachdetach-controller
• system:controller:certificate-controller
• system:controller:clusterrole-aggregation-controller
• system:controller:cronjob-controller
• system:controller:daemon-set-controller
• system:controller:deployment-controller
• system:controller:disruption-controller
• system:controller:endpoint-controller
• system:controller:expand-controller
• system:controller:generic-garbage-collector
• system:controller:horizontal-pod-autoscaler
• system:controller:job-controller
• system:controller:namespace-controller
• system:controller:node-controller
• system:controller:persistent-volume-binder
• system:controller:pod-garbage-collector
• system:controller:pv-protection-controller
• system:controller:pvc-protection-controller
• system:controller:replicaset-controller
• system:controller:replication-controller
• system:controller:resourcequota-controller
• system:controller:root-ca-cert-publisher
• system:controller:route-controller
• system:controller:service-account-controller
• system:controller:service-controller
• system:controller:statefulset-controller
• system:controller:ttl-controller

Privilege escalation prevention and bootstrapping

The RBAC API prevents users from escalating privileges by editing roles or role bindings. Because this is enforced at the API level, it applies even when the RBAC authorizer is not in use.

Restrictions on role creation or update

You can only create/update a role if at least one of the following things is true:

1. You already have all the permissions contained in the role, at the same scope as the object being modified (cluster-wide for a ClusterRole, within the same namespace or cluster-wide for a Role).
2. You are granted explicit permission to perform the escalate verb on the roles or clusterroles resource in the rbac.authorization.k8s.io API group.

For example, if user-1 does not have the ability to list Secrets cluster-wide, they cannot create a ClusterRole containing that permission. To allow a user to create/update roles:

1. Grant them a role that allows them to create/update Role or ClusterRole objects, as desired.
2. Grant them permission to include specific permissions in the roles they create/update:
   • implicitly, by giving them those permissions (if they attempt to create or modify a Role or ClusterRole with permissions they themselves have not been granted, the API request will be forbidden)
   • or explicitly allow specifying any permission in a Role or ClusterRole by giving them permission to perform the escalate verb on roles or clusterroles resources in the rbac.authorization.k8s.io API group

Restrictions on role binding creation or update

You can only create/update a role binding if you already have all the permissions contained in the referenced role (at the same scope as the role binding) or if you have been authorized to perform the bind verb on the referenced role. For example, if user-1 does not have the ability to list Secrets cluster-wide, they cannot create a ClusterRoleBinding to a role that grants that permission. To allow a user to create/update role bindings:

1. Grant them a role that allows them to create/update RoleBinding or ClusterRoleBinding objects, as desired.
2. Grant them permissions needed to bind a particular role:
   • implicitly, by giving them the permissions contained in the role.
   • explicitly, by giving them permission to perform the bind verb on the particular Role (or ClusterRole).

For example, this ClusterRole and RoleBinding would allow user-1 to grant other users the admin, edit, and view roles in the namespace user-1-namespace:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: role-grantor
rules:
- apiGroups: ["rbac.authorization.k8s.io"]
  resources: ["rolebindings"]
  verbs: ["create"]
- apiGroups: ["rbac.authorization.k8s.io"]
  resources: ["clusterroles"]
  verbs: ["bind"]
  # omit resourceNames to allow binding any ClusterRole
  resourceNames: ["admin","edit","view"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: role-grantor-binding
  namespace: user-1-namespace
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: role-grantor
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: user-1

When bootstrapping the first roles and role bindings, it is necessary for the initial user to grant permissions they do not yet have. To bootstrap initial roles and role bindings:

• Use a credential with the "system:masters" group, which is bound to the "cluster-admin" super-user role by the default bindings.

Command-line utilities

kubectl create role

Creates a Role object defining permissions within a single namespace. Examples:

• Create a Role named "pod-reader" that allows users to perform get, watch and list on pods:

  kubectl create role pod-reader --verb=get --verb=list --verb=watch --resource=pods
  

• Create a Role named "pod-reader" with resourceNames specified:

  kubectl create role pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod
  

• Create a Role named "foo" with apiGroups specified:

  kubectl create role foo --verb=get,list,watch --resource=replicasets.apps
  

• Create a Role named "foo" with subresource permissions:

  kubectl create role foo --verb=get,list,watch --resource=pods,pods/status
  

• Create a Role named "my-component-lease-holder" with permissions to get/update a resource with a specific name:

  kubectl create role my-component-lease-holder --verb=get,list,watch,update --resource=lease --resource-name=my-component
  

kubectl create clusterrole

Creates a ClusterRole. Examples:

• Create a ClusterRole named "pod-reader" that allows user to perform get, watch and list on pods:

  kubectl create clusterrole pod-reader --verb=get,list,watch --resource=pods
  

• Create a ClusterRole named "pod-reader" with resourceNames specified:

  kubectl create clusterrole pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod
  

• Create a ClusterRole named "foo" with apiGroups specified:

  kubectl create clusterrole foo --verb=get,list,watch --resource=replicasets.apps
  

• Create a ClusterRole named "foo" with subresource permissions:

  kubectl create clusterrole foo --verb=get,list,watch --resource=pods,pods/status
  

• Create a ClusterRole named "foo" with nonResourceURL specified:

  kubectl create clusterrole "foo" --verb=get --non-resource-url=/logs/*
  

• Create a ClusterRole named "monitoring" with an aggregationRule specified:

  kubectl create clusterrole monitoring --aggregation-rule="rbac.example.com/aggregate-to-monitoring=true"
  

kubectl create rolebinding

Grants a Role or ClusterRole within a specific namespace. Examples:

• Within the namespace "acme", grant the permissions in the "admin" ClusterRole to a user named "bob":

  kubectl create rolebinding bob-admin-binding --clusterrole=admin --user=bob --namespace=acme
  

• Within the namespace "acme", grant the permissions in the "view" ClusterRole to the service account in the namespace "acme" named "myapp":

  kubectl create rolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp --namespace=acme
  

• Within the namespace "acme", grant the permissions in the "view" ClusterRole to a service account in the namespace "myappnamespace" named "myapp":

  kubectl create rolebinding myappnamespace-myapp-view-binding --clusterrole=view --serviceaccount=myappnamespace:myapp --namespace=acme
  

kubectl create clusterrolebinding

Grants a ClusterRole across the entire cluster (all namespaces). Examples:

• Across the entire cluster, grant the permissions in the "cluster-admin" ClusterRole to a user named "root":

  kubectl create clusterrolebinding root-cluster-admin-binding --clusterrole=cluster-admin --user=root
  

• Across the entire cluster, grant the permissions in the "system:node-proxier" ClusterRole to a user named "system:kube-proxy":

  kubectl create clusterrolebinding kube-proxy-binding --clusterrole=system:node-proxier --user=system:kube-proxy
  

• Across the entire cluster, grant the permissions in the "view" ClusterRole to a service account named "myapp" in the namespace "acme":

  kubectl create clusterrolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp
  

kubectl auth reconcile

Creates or updates rbac.authorization.k8s.io/v1 API objects from a manifest file.

Missing objects are created, and the containing namespace is created for namespaced objects, if required.

Existing roles are updated to include the permissions in the input objects, and remove extra permissions if --remove-extra-permissions is specified.

Existing bindings are updated to include the subjects in the input objects, and remove extra subjects if --remove-extra-subjects is specified.

Examples:

• Test applying a manifest file of RBAC objects, displaying changes that would be made:

  kubectl auth reconcile -f my-rbac-rules.yaml --dry-run=client
  

• Apply a manifest file of RBAC objects, preserving any extra permissions (in roles) and any extra subjects (in bindings):

  kubectl auth reconcile -f my-rbac-rules.yaml
  

• Apply a manifest file of RBAC objects, removing any extra permissions (in roles) and any extra subjects (in bindings):

  kubectl auth reconcile -f my-rbac-rules.yaml --remove-extra-subjects --remove-extra-permissions
  

ServiceAccount permissions

Default RBAC policies grant scoped permissions to control-plane components, nodes, and controllers, but grant no permissions to service accounts outside the kube-system namespace (beyond discovery permissions given to all authenticated users).

This allows you to grant particular roles to particular ServiceAccounts as needed. Fine-grained role bindings provide greater security, but require more effort to administrate. Broader grants can give unnecessary (and potentially escalating) API access to ServiceAccounts, but are easier to administrate.

In order from most secure to least secure, the approaches are:

1. Grant a role to an application-specific service account (best practice)

   This requires the application to specify a serviceAccountName in its pod spec, and for the service account to be created (via the API, application manifest, kubectl create serviceaccount, etc.).

   For example, grant read-only permission within "my-namespace" to the "my-sa" service account:

   kubectl create rolebinding my-sa-view \
     --clusterrole=view \
     --serviceaccount=my-namespace:my-sa \
     --namespace=my-namespace
   

2. Grant a role to the "default" service account in a namespace

   If an application does not specify a serviceAccountName, it uses the "default" service account.

   {{< note >}} Permissions given to the "default" service account are available to any pod in the namespace that does not specify a serviceAccountName. {{< /note >}}

   For example, grant read-only permission within "my-namespace" to the "default" service account:

   kubectl create rolebinding default-view \
     --clusterrole=view \
     --serviceaccount=my-namespace:default \
     --namespace=my-namespace
   

   Many add-ons run as the "default" service account in the kube-system namespace. To allow those add-ons to run with super-user access, grant cluster-admin permissions to the "default" service account in the kube-system namespace.

   {{< caution >}} Enabling this means the kube-system namespace contains Secrets that grant super-user access to your cluster's API. {{< /caution >}}

   kubectl create clusterrolebinding add-on-cluster-admin \
     --clusterrole=cluster-admin \
     --serviceaccount=kube-system:default
   

3. Grant a role to all service accounts in a namespace

   If you want all applications in a namespace to have a role, no matter what service account they use, you can grant a role to the service account group for that namespace.

   For example, grant read-only permission within "my-namespace" to all service accounts in that namespace:

   kubectl create rolebinding serviceaccounts-view \
     --clusterrole=view \
     --group=system:serviceaccounts:my-namespace \
     --namespace=my-namespace
   

4. Grant a limited role to all service accounts cluster-wide (discouraged)

   If you don't want to manage permissions per-namespace, you can grant a cluster-wide role to all service accounts.

   For example, grant read-only permission across all namespaces to all service accounts in the cluster:

   kubectl create clusterrolebinding serviceaccounts-view \
     --clusterrole=view \
    --group=system:serviceaccounts
   

5. Grant super-user access to all service accounts cluster-wide (strongly discouraged)

   If you don't care about partitioning permissions at all, you can grant super-user access to all service accounts.

   {{< warning >}} This allows any application full access to your cluster, and also grants any user with read access to Secrets (or the ability to create any pod) full access to your cluster. {{< /warning >}}

   kubectl create clusterrolebinding serviceaccounts-cluster-admin \
     --clusterrole=cluster-admin \
     --group=system:serviceaccounts
   

Write access for EndpointSlices and Endpoints

Kubernetes clusters created before Kubernetes v1.22 include write access to EndpointSlices (and Endpoints) in the aggregated "edit" and "admin" roles. As a mitigation for CVE-2021-25740, this access is not part of the aggregated roles in clusters that you create using Kubernetes v1.22 or later.

Existing clusters that have been upgraded to Kubernetes v1.22 will not be subject to this change. The CVE announcement includes guidance for restricting this access in existing clusters.

If you want new clusters to retain this level of access in the aggregated roles, you can create the following ClusterRole:

{{< codenew file="access/endpoints-aggregated.yaml" >}}

Upgrading from ABAC

Clusters that originally ran older Kubernetes versions often used permissive ABAC policies, including granting full API access to all service accounts.

Default RBAC policies grant scoped permissions to control-plane components, nodes, and controllers, but grant no permissions to service accounts outside the kube-system namespace (beyond discovery permissions given to all authenticated users).

While far more secure, this can be disruptive to existing workloads expecting to automatically receive API permissions. Here are two approaches for managing this transition:

Parallel authorizers

Run both the RBAC and ABAC authorizers, and specify a policy file that contains the legacy ABAC policy:

--authorization-mode=...,RBAC,ABAC --authorization-policy-file=mypolicy.json

To explain that first command line option in detail: if earlier authorizers, such as Node, deny a request, then the RBAC authorizer attempts to authorize the API request. If RBAC also denies that API request, the ABAC authorizer is then run. This means that any request allowed by either the RBAC or ABAC policies is allowed.

When the kube-apiserver is run with a log level of 5 or higher for the RBAC component (--vmodule=rbac*=5 or --v=5), you can see RBAC denials in the API server log (prefixed with RBAC). You can use that information to determine which roles need to be granted to which users, groups, or service accounts.

Once you have granted roles to service accounts and workloads are running with no RBAC denial messages in the server logs, you can remove the ABAC authorizer.

Permissive RBAC permissions

You can replicate a permissive ABAC policy using RBAC role bindings.

{{< warning >}} The following policy allows ALL service accounts to act as cluster administrators. Any application running in a container receives service account credentials automatically, and could perform any action against the API, including viewing secrets and modifying permissions. This is not a recommended policy.

kubectl create clusterrolebinding permissive-binding \
  --clusterrole=cluster-admin \
  --user=admin \
  --user=kubelet \
  --group=system:serviceaccounts

{{< /warning >}}

After you have transitioned to use RBAC, you should adjust the access controls for your cluster to ensure that these meet your information security needs.