Configurer le contrôle des accès basé sur les rôles

Cette page présente le système de contrôle d'accès basé sur les rôles (RBAC) fourni par Kubernetes et explique comment utiliser Kubernetes RBAC dans Google Kubernetes Engine (GKE).

Présentation

Kubernetes comprend un mécanisme intégré de contrôle des accès basé sur les rôles (RBAC). Ce système vous permet de configurer des ensembles d'autorisations ultraprécises pour définir la façon dont un utilisateur ou groupe d'utilisateurs Google Cloud peut interagir avec chaque objet Kubernetes dans un cluster ou dans un espace de noms spécifique au sein du cluster.

Le contrôle Kubernetes RBAC est activé par défaut.

Avant de commencer

Avant de commencer, effectuez les tâches suivantes :

• Assurez-vous d'avoir activé l'API Google Kubernetes Engine.
Activer l'API Google Kubernetes Engine
• Assurez-vous d'avoir installé le SDK Cloud.

Configurez les paramètres gcloud par défaut à l'aide de l'une des méthodes suivantes :

• Utilisez gcloud init pour suivre les instructions permettant de définir les paramètres par défaut.
• Utilisez gcloud config pour définir individuellement l'ID, la zone et la région de votre projet.

Utiliser gcloud init

Si le message d'erreur One of [--zone, --region] must be supplied: Please specify location s'affiche, effectuez les tâches ci-dessous.

1. Exécutez gcloud init et suivez les instructions :

   gcloud init

   Si vous utilisez SSH sur un serveur distant, utilisez l'option --console-only pour empêcher la commande d'ouvrir un navigateur :

   gcloud init --console-only

2. Suivez les instructions pour autoriser gcloud à utiliser votre compte Google Cloud.
3. Créez ou sélectionnez une configuration.
4. Choisissez un projet Google Cloud.
5. Choisissez une zone Compute Engine par défaut.

Remarque : Vous pouvez remplacer ces paramètres par défaut dans les commandes gcloud à l'aide des options --project, --zone et --region.

Utiliser gcloud config

• Définissez votre ID de projet par défaut :

  gcloud config set project project-id

• Si vous travaillez avec des clusters zonaux, définissez votre zone de calcul par défaut :

  gcloud config set compute/zone compute-zone

• Si vous utilisez des clusters régionaux, définissez votre région de calcul par défaut :

  gcloud config set compute/region compute-region

• Mettez à jour gcloud vers la dernière version :

  gcloud components update

Remarque : Vous pouvez remplacer ces paramètres par défaut dans les commandes gcloud à l'aide des options --project, --zone et --region.

Interagir avec la gestion de l'authentification et des accès

Vous pouvez contrôler l'accès à votre cluster GKE à l'aide d'Identity and Access Management (IAM) et de Kubernetes RBAC :

• IAM n'est pas spécifique à Kubernetes. Cette solution fournit des fonctions de gestion des identités pour de nombreux produits Google Cloud et fonctionne principalement au niveau du projet Google Cloud.

• Kubernetes RBAC est un composant essentiel de Kubernetes qui vous permet de créer et d’attribuer des rôles (ensembles d’autorisations) à tout objet ou type d’objet au sein d'un cluster.

Dans GKE, IAM et Kubernetes RBAC sont intégrés pour permettre aux utilisateurs d'effectuer des actions s’ils disposent des autorisations suffisantes selon chaque outil. C'est un élément important pour l'amorçage d'un cluster GKE, car par défaut, les utilisateurs Google Cloud ne disposent pas d'autorisation Kubernetes RBAC associée à des rôles (RoleBindings).

Pour autoriser des utilisateurs de comptes Google Cloud, le client doit d'abord être correctement configuré pour s'authentifier à l'aide de ces comptes. Par exemple, si vous utilisez kubectl, vous devez configurer la commande kubectl pour vous authentifier auprès de Google Cloud avant d'exécuter des commandes nécessitant une autorisation.

Remarque : De nombreux échecs semblant dus à des problèmes d'autorisation sont en réalité causés par l'impossibilité pour le cluster d'authentifier le client. Par exemple, l'authentification depuis des instances Compute Engine requiert une configuration particulière, décrite dans la documentation sur l'authentification kubectl.

Bien que Kubernetes RBAC puisse être utilisé à la place d'IAM dans presque tous les cas, les utilisateurs de GKE doivent au moins disposer de l'autorisation IAM container.clusters.get dans le projet contenant le cluster. Cette autorisation est incluse dans le rôle container.clusterViewer, ainsi que dans les autres rôles les plus privilégiés. L'autorisation container.clusters.get est requise pour que les utilisateurs puissent s'authentifier auprès des clusters du projet, mais ne les autorise à effectuer aucune action dans ces clusters. L'autorisation peut alors être fournie par IAM ou Kubernetes RBAC.

Conditions préalables à l'utilisation de Kubernetes RBAC sur un cluster GKE version 1.11.x ou antérieure

Dans les clusters GKE exécutant une version 1.11.x ou antérieure de GKE, IAM ne permet pas de créer un objet Kubernetes RBAC Role ou ClusterRole. Cependant, le rôle IAM Administrateur de Kubernetes Engine donne la possibilité de créer un objet Kubernetes RBAC RoleBinding ou ClusterRoleBinding pour tout utilisateur, y compris soi-même. Cet objet peut être utilisé pour associer les utilisateurs Google Cloud à des rôles RBAC prédéfinis.

Plus spécifiquement, le rôle RBAC prédéfini cluster-admin accorde aux utilisateurs des autorisations complètes sur le cluster. Par conséquent, pour amorcer un utilisateur et lui permettre de créer des objets RBAC Role et ClusterRole, exécutez la commande suivante en remplaçant user-account par l'adresse Google Cloud de l'utilisateur cible.

kubectl create clusterrolebinding cluster-admin-binding \
  --clusterrole cluster-admin \
  --user user-account

Remarque : La valeur de user-account est sensible à la casse. Pour éviter les erreurs, saisissez l'adresse e-mail de l'utilisateur cible en minuscules.

Google Groupes pour GKE

Beta

Ce produit ou cette fonctionnalité est disponible dans sa version préliminaire, et peut changer ou bénéficier d'une assistance limitée. Pour en savoir plus, consultez les étapes de lancement des produits.

Auparavant, vous ne pouviez attribuer des rôles qu'aux comptes utilisateur Google Cloud ou aux comptes de service IAM. Google Groupes pour GKE (version bêta) vous permet d'attribuer des rôles aux membres d'un groupe Google Groups for Business. Avec ce mécanisme, les utilisateurs et les groupes eux-mêmes sont gérés par les administrateurs Google Workspace, complètement à l'extérieur de Kubernetes ou de Cloud Console. Ainsi, vos administrateurs de cluster n'ont pas besoin d'informations détaillées sur vos utilisateurs. Autre avantage, l'intégration avec vos pratiques de gestion des comptes utilisateur existantes, telles que la révocation d'accès lorsqu'un utilisateur quitte votre organisation.

Pour utiliser cette fonctionnalité, effectuez les tâches suivantes :

• Remplissez les conditions requises.
• Configurez Google Groupes.
• Créez un cluster avec la fonctionnalité activée.
• Associez les groupes Google Groupes à des ensembles d'autorisations de cluster.

Exigences

L'utilisation de Google Groupes pour GKE implique les exigences suivantes :

• Vous devez disposer d'un abonnement à Google Workspace ou à Cloud Identity.

Configurer Google Groupes pour une utilisation avec RBAC

La configuration de votre cluster pour l'utilisation de cette fonctionnalité et la syntaxe permettant de référencer un groupe Google dans Kubernetes RBAC sont détaillées plus bas sur cette page. Tout d'abord, vous devez configurer Google Groupes en procédant comme suit :

1. Dans votre domaine, créez un groupe Google nommé [e-mail]. Le nom du groupe doit être exactement gke-security-groups. Assurez-vous que le groupe gke-security-groups dispose de l'autorisation "Afficher la liste des membres" pour les "Membres du groupe". Consultez cet article pour découvrir comment définir ce paramètre dans la console d'administration Google Workspace.

   Vous pouvez également consulter le Centre d'aide Google Groupes pour en savoir plus sur la gestion des groupes dans Google Workspace.

2. S'ils n'existent pas déjà, créez des groupes qui représentent des groupes d'utilisateurs ou des groupes devant disposer d'autorisations différentes sur vos clusters. Chaque groupe doit disposer de l'autorisation "Afficher les membres" pour les "Membres du groupe".

3. Ajoutez ces groupes (pas les utilisateurs) comme membres de [e-mail].

Pour vérifier si un utilisateur donné est autorisé à créer, modifier ou afficher une ressource du cluster selon le groupe auquel il appartient, GKE vérifie si l'utilisateur est membre d'un groupe ayant accès à cette ressource et si ce groupe est membre direct du groupe gke-security-groups dans votre domaine.

Les informations sur les membres du groupe Google sont mises en cache pendant une courte période. La propagation des modifications de membres de groupe à tous vos clusters peut prendre quelques minutes. En plus de la latence des modifications apportées aux groupes, la mise en cache standard des identifiants utilisateur sur le cluster dure environ une heure.

Configurer votre cluster pour utiliser Google Groupes pour GKE

Remarque : Vous devez créer un nouveau cluster pour activer cette fonctionnalité.

Une fois que votre administrateur Google Groupes a configuré vos groupes, créez un cluster à l'aide de la commande gcloud et ajoutez l'option --security-group="[e-mail]" en utilisant votre propre nom de domaine.

Voici un exemple de commande de création de cluster :

gcloud beta container clusters create cluster-name \
  --security-group="[e-mail]"

Vous êtes maintenant prêt à créer des objets Role, ClusterRole, RoleBinding et ClusterRoleBinding qui font référence à vos groupes Google.

Définir et attribuer des autorisations

Vous définissez vos autorisations RBAC en créant les types d’objets Kubernetes suivants :

• ClusterRole ou Role : définissent un ensemble de types de ressources et d'opérations pouvant être affectés à un utilisateur ou à un groupe d'utilisateurs au sein d'un cluster (ClusterRole) ou d'un espace de noms (Role), mais ne spécifient pas l'utilisateur ou le groupe d'utilisateurs.
• ClusterRoleBinding ou RoleBinding : attribuent un objet ClusterRole ou Role à un utilisateur ou à un groupe d'utilisateurs. Un objet ClusterRoleBinding fonctionne avec un objet ClusterRole, et un objet RoleBinding avec un objet ClusterRole ou Role.

Les rôles RBAC sont uniquement de nature "additive" : ils n'impliquent aucune règle de "refus". Lors de la structuration de vos rôles RBAC, votre objectif est le suivant : accorder aux utilisateurs l'accès aux ressources du cluster.

Définir des autorisations à l'aide d'un objet Role ou ClusterRole

Vous définissez des autorisations dans un objet Role ou ClusterRole. Un objet Role définit l'accès aux ressources dans un seul espace de noms, tandis qu'un objet ClusterRole définit l'accès aux ressources dans l'ensemble du cluster.

Les objets Role et ClusterRole ont la même syntaxe. Chacun comporte une section rules dans laquelle vous définissez l'espace de noms, le type de ressource et les opérations autorisées pour le rôle. Par exemple, l'objet Role suivant accorde un accès en lecture (get, watch et list) à tous les pods de l'espace de noms accounting :

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

Remarque : Vous ne pouvez pas créer un objet Role qui définit des autorisations dont vous ne disposez pas déjà. Si le rôle IAM cluster-admin vous a été attribué, cela est suffisant.

Role vs ClusterRole

Sachant que les autorisations ClusterRole s'appliquent à l'ensemble du cluster, elles peuvent servir à contrôler l'accès à des types de ressources différents de ceux contrôlables avec un objet Role, y compris :

• Ressources à l'échelle du cluster, telles que les nœuds
• Points de terminaison REST hors ressources, tels que /healthz
• Ressources en espace de noms sur tous les espaces de noms (par exemple, tous les pods de l'ensemble du cluster, quel que soit l'espace de noms)

Attribuer des rôles avec RoleBinding ou ClusterRoleBinding

Après avoir créé un objet Role ou ClusterRole, vous l'attribuez à un utilisateur ou à un groupe d'utilisateurs en créant un objet RoleBinding ou ClusterRoleBinding. Les utilisateurs et les groupes sont appelés subjects et peuvent être l’un des éléments suivants :

Type d'objet	Valeur de kind	Valeur de name
Compte utilisateur Google Cloud	User	Adresse e-mail enregistrée dans Google Cloud
Compte de service Kubernetes	ServiceAccount	Nom d'un objet Kubernetes ServiceAccount dans le cluster
Compte de service IAM	User	Adresse e-mail du compte de service IAM générée automatiquement
Adresse du groupe Google (version bêta) sur un domaine validé	Group	Adresse e-mail d'un groupe Google Groupes, qui est lui-même membre du groupe Google Groupes [e-mail]

L'objet RoleBinding suivant attribue le rôle pod-reader à un utilisateur, à un compte de service Kubernetes, à un compte de service IAM et à un groupe Google Groupes :

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: pod-reader-binding
  namespace: accounting
subjects:
# Google Cloud user account
- kind: User
  name: [e-mail]
# Kubernetes service account
- kind: ServiceAccount
  name: johndoe
# IAM service account
- kind: User
  name: [e-mail]
# Google Group
- kind: Group
  name: [e-mail]
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Utilisation de l'API et exemples

Pour obtenir des informations complètes sur l'utilisation de l'API Kubernetes dans le cadre de la création des objets Role, ClusterRole, RoleBinding et ClusterRoleBinding nécessaires pour le contrôle RBAC, consultez la section Utiliser l'autorisation de contrôle des accès basé sur les rôles de la documentation de Kubernetes.

Dépannage et débogage

Pour déboguer les problèmes liés à RBAC, utilisez le journal d'audit des activités d'administration, qui est activé par défaut sur tous les clusters. Si l'accès à une ressource ou à une opération est refusé en raison d'autorisations insuffisantes, le serveur d'API enregistre une erreur RBAC DENY, ainsi que des informations supplémentaires telles que l'appartenance implicite et explicite de l'utilisateur à un groupe. Si vous utilisez Google Groupes pour GKE, google groups apparaît dans le message de journal.

Problèmes de débogage liés à l'intégration de Google Groupes

Les instructions suivantes vous permettent d'afficher les journaux pour vérifier si vos clusters ont été correctement configurés pour utiliser Google Groupes dans les objets RoleBinding RBAC.

Prérequis

Avant de commencer à examiner les journaux, vérifiez les points suivants :

• Vous n'avez pas interagi avec le cluster que vous souhaitez tester (par exemple, vous n'avez pas exécuté de commandes kubectl) pendant au moins une heure. L'authentification est mise en cache pendant une heure et vous devez vous assurer que la requête est enregistrée à ce moment-là.
• Vous êtes membre d'au moins un des groupes inclus dans gke-security-groups. Cela garantit que certaines informations Google Groupes sont renseignées dans les journaux.

Configurer des journaux

Pour utiliser les journaux pour le débogage de Google Groupes avec RBAC :

1. Activez la journalisation de l'accès aux données pour votre projet Google Cloud. Pour activer la journalisation, procédez comme suit :

   1. Dans Cloud Console, accédez à la page Journaux d'audit dans le menu IAM.

      Accéder à la page "Journaux d'audit"

   2. Dans le tableau, sélectionnez API Kubernetes Engine.

   3. Dans le menu Type de journal, sélectionnez :

      • Lecture administrateur
      • Lecture de données
      • Écriture de données

   4. Cliquez sur Enregistrer.

   Pour en savoir plus sur l'activation des journaux d'audit, consultez la section Configurer des journaux d'accès aux données avec Cloud Console dans la documentation des outils de gestion Cloud.

   Important : L'activation des journaux d'audit entraîne des frais. Si vous n'avez activé les journaux d'audit qu'à des fins de test, vous devez les désactiver une fois les tests terminés afin d'éviter des frais.

2. Exécutez une commande à l'aide de kubectl dans le cluster. Cela peut être simplement kubectl create ns helloworld.

3. Saisissez une requête personnalisée sur la page Visionneuse de journaux. Pour exécuter la requête, procédez comme suit :

   1. Dans Cloud Console, accédez à la page Visionneuse de journaux du menu Journalisation.

      Accéder à la page "Visionneuse de journaux"

   2. Cliquez sur la flèche dans le champ Aperçu de la requête en haut de la page.

   3. Dans la liste déroulante qui s'affiche, copiez et collez la requête suivante :

      resource.type="k8s_cluster"
      resource.labels.location="cluster-region"
      resource.labels.cluster_name="cluster-name"
      protoPayload.resourceName="authorization.k8s.io/v1beta1/subjectaccessreviews"
      protoPayload.response.spec.user="email-address"
      

      Où :

      • cluster-region est la région ou la zone de votre cluster.
      • cluster-name est le nom du cluster.
      • email-address est l'adresse e-mail enregistrée de votre compte Google.

   4. Sélectionnez Exécuter la requête. Au moins un résultat doit s'afficher. Si ce n'est pas le cas, essayez d'élargir la période.

   5. Sélectionnez le cluster que vous souhaitez examiner.

   6. Cliquez sur Développer les champs imbriqués.

   7. Le champ protoPayload.request.spec.group contient les groupes pour lesquels :

      • Les groupes sont membres de gke-security-group.
      • Vous êtes membre du groupe.

      Cette liste doit correspondre à l'ensemble des groupes dont vous êtes membre. Si aucun groupe n'apparaît, il y a peut-être un problème avec la configuration des groupes.

4. Restaurez la journalisation de l'accès aux données avec les paramètres précédents pour éviter des frais supplémentaires (si vous le souhaitez).

Limites

Les sections suivantes décrivent des mises en garde relatives à l'utilisation de Kubernetes RBAC.

Rôles de découverte par défaut

Les clusters sont créés avec un ensemble d'objets ClusterRole et ClusterRoleBinding par défaut. Les requêtes effectuées avec des identifiants valides sont placées dans le groupe system:authenticated, tandis que toutes les autres requêtes appartiennent à system:unauthenticated. Avant la version 1.14 de Kubernetes, les groupes system:authenticated et system:unauthenticated accordent tous deux par défaut les objets ClusterRole system:basic-user et system:discovery.

Le ClusterRole system:basic-user permet aux utilisateurs de faire en sorte que SelfSubjectAccessReviews teste leurs autorisations dans le cluster. Le rôle system:discovery permet aux utilisateurs de lire les API de découverte, qui peuvent révéler des informations sur les définitions de ressources personnalisées (CustomResourceDefinitions) ajoutées au cluster.

À partir de Kubernetes 1.14, les utilisateurs anonymes (system:unauthenticated) recevront à la place le ClusterRole system:public-info-viewer, qui accorde un accès en lecture seule aux API /healthz et /version.

Pour afficher les points de terminaison d'API autorisés par le ClusterRole system:discovery, exécutez la commande suivante :

kubectl get clusterroles system:discovery -o yaml

Erreur Forbidden pour les comptes de service sur les instances de VM Google Cloud

L'erreur suivante peut se produire lorsque l'instance de VM ne dispose pas du niveau d'accès userinfo-email :

Error from server (Forbidden): error when creating ... "role-name" is forbidden: attempt to grant extra privileges:...

Supposons par exemple que la VM dispose du niveau d'accès cloud-platform, et non du niveau d'accès userinfo-email. Lorsque la VM obtient un jeton d'accès, Google Cloud associe ce jeton au niveau d'accès cloud-platform. Lorsque le serveur de l'API Kubernetes demande à Google Cloud l'identité associée au jeton d'accès, il reçoit l'ID unique du compte de service, et non l'adresse e-mail du compte de service.

Pour effectuer l'authentification, créez une VM avec le niveau d'accès userinfo-email ou créez une liaison de rôle utilisant l'ID unique.

Pour créer une instance de VM avec le niveau d'accès userinfo-email, exécutez la commande suivante :

gcloud compute instances create instance-name \
    --service-account service-account-email \
    --scopes userinfo-email

Pour créer une liaison de rôle utilisant l'ID unique d'un compte de service pour une VM existante, procédez comme suit :

1. Identifiez l'ID unique du compte de service :

   gcloud iam service-accounts describe service-account-email
   

   Par exemple, le résultat suivant affiche l'ID uniqueId pour le compte de service [e-mail] :

   displayName: Some Domain IAM service account
   email: [e-mail]
   etag: BwWWja0YfJA
   name: projects/project-name/serviceAccounts/[e-mail]
   oauth2ClientId: '123456789012345678901'
   projectId: project-name
   uniqueId: '123456789012345678901'
   

2. Créez une liaison de rôle à l'aide de l'ID uniqueId du compte de service :

   kubectl create clusterrolebinding clusterrolebinding-name \
     --clusterrole cluster-admin \
     --user unique-id
   

Étape suivante

• Découvrez comment créer des stratégies IAM.