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 votre cluster ou dans un espace de noms spécifique au sein de votre cluster.

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

Avant de commencer

Avant de commencer, effectuez les tâches suivantes :

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 pour les clusters zonaux ou une région pour les clusters régionaux ou Autopilot.

Utiliser gcloud config

  • Définissez votre ID de projet par défaut : 
    gcloud config set project PROJECT_ID
  • Si vous utilisez des clusters zonaux, définissez votre zone de calcul par défaut : 
    gcloud config set compute/zone COMPUTE_ZONE
  • Si vous utilisez des clusters Autopilot ou 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

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.

Dans presque tous les cas, Kubernetes RBAC peut être utilisé à la place d'IAM. Les utilisateurs de GKE nécessitent au minimum l'autorisation IAM container.clusters.get dans le projet qui contient le cluster. Cette autorisation est incluse dans le rôle container.clusterViewer ainsi que dans d'autres rôles disposant de privilèges plus élevé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.

Google Groupes pour RBAC

Auparavant, vous ne pouviez attribuer des rôles qu'aux comptes utilisateur Google Cloud ou aux comptes de service IAM. Google Groupes pour RBAC 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 :

Exigences

Pour utiliser Google Groupes pour RBAC, vous devez avoir accès à Google Workspace ou à n'importe quelle édition de Cloud Identity.

Google Groupes pour RBAC n'est disponible que sur les clusters GKE standards.

Configurer Google Groupes pour 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é gke-security-groups@YOUR_DOMAIN. 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 gke-security-groups@YOUR_DOMAIN.

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 RBAC

Une fois que votre administrateur Google Groupes a configuré vos groupes, vous pouvez créer un cluster ou mettre à jour un cluster existant afin d'activer la fonctionnalité Google Groupes pour RBAC. Pour ce faire, utilisez l'outil gcloud ou Google Cloud Console.

Google Groupes pour RBAC n'est disponible que sur les clusters GKE standards.

gcloud

Créer un cluster

Pour créer un cluster et activer la fonctionnalité RBAC pour Google Groupes, exécutez la commande gcloud suivante, en remplaçant la valeur YOUR_DOMAIN par votre propre nom de domaine :

gcloud container clusters create CLUSTER_NAME \
  --security-group="gke-security-groups@YOUR_DOMAIN"

Mettre à jour un cluster existant

Pour mettre à jour un cluster existant afin d'activer la fonctionnalité Google Groupes pour RBAC, exécutez la commande gcloud suivante en remplaçant la valeur YOUR_DOMAIN par votre propre nom de domaine :

gcloud container clusters update CLUSTER_NAME \
  --security-group="gke-security-groups@YOUR_DOMAIN"

Console

Créer un cluster

Pour créer un cluster et activer la fonctionnalité Google Groupes pour RBAC, procédez comme suit dans Google Cloud Console :

  1. Accédez à la page Google Kubernetes Engine dans Cloud Console.

    Accéder à Google Kubernetes Engine

  2. Cliquez sur Créer.

  3. Choisissez le modèle de cluster standard.

  4. Dans le volet de navigation, sous Clusters, cliquez sur Sécurité.

  5. Cochez la case Activer Google Groupes pour RBAC.

  6. Dans le champ Groupe de sécurité, saisissez gke-security-groups@YOUR_DOMAIN.

  7. Cliquez sur Create (Créer).

Mettre à jour un cluster existant

Pour mettre à jour un cluster existant afin d'activer la fonctionnalité Google Groupes pour RBAC, procédez comme suit dans Google Cloud Console :

  1. Accédez à la page Google Kubernetes Engine dans Cloud Console.

    Accéder à Google Kubernetes Engine

  2. À côté du cluster que vous souhaitez modifier, cliquez sur Actions, puis sur Modifier.

  3. Sous l'onglet "Détails", cliquez sur Modifier Google Groupes pour RBAC dans le champ Google Groupes pour RBAC.

  4. Cochez la case Activer Google Groupes pour RBAC.

  5. Saisissez le nom de votre groupe de sécurité.

  6. Cliquez sur Enregistrer les modifications.

Vous êtes maintenant prêt à créer des objets RoleBindings et ClusterRoleBindings qui font référence à vos groupes Google.

Définir et attribuer des autorisations

Vous pouvez définir des règles RBAC dans les objets ClusterRole et Role, puis les attribuer avec les objets ClusterRoleBinding et RoleBinding comme suit :

  • ClusterRole : regroupement au niveau du cluster de ressources et d'opérations autorisées que vous pouvez attribuer à un utilisateur ou à un groupe à l'aide d'une liaison RoleBinding ou ClusterRoleBinding.
  • Role : regroupement d'espace de noms de ressources et d'opérations autorisées pouvant être attribuées à un utilisateur ou à un groupe d'utilisateurs à l'aide d'une liaison RoleBinding.
  • ClusterRoleBinding : attribuez un rôle ClusterRole à un utilisateur ou à un groupe pour tous les espaces de noms du cluster.
  • RoleBinding : attribuez un rôle Role ou ClusterRole à un utilisateur ou à un groupe au sein d'un espace de noms spécifique.

Lorsque vous utilisez une liaison RoleBinding pour attribuer un rôle ClusterRole à un utilisateur ou à un groupe, ces utilisateurs et groupes ne peuvent accéder qu'aux ressources de l'espace de noms que vous spécifiez dans la liaison RoleBinding. Si vous souhaitez que les utilisateurs ou les groupes accèdent aux ressources sur tous les espaces de noms, utilisez plutôt une liaison ClusterRoleBinding.

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 les ressources auxquelles la règle s'applique 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 :

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

Reportez-vous à la documentation sur l'API Role et ClusterRole pour obtenir la liste complète des champs autorisés.

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 sur un domaine validé Group Adresse e-mail d'un groupe Google Groupes, qui est lui-même membre du groupe Google Groupes gke-security-groups@YOUR_DOMAIN

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: janedoe@example.com
# Kubernetes service account
- kind: ServiceAccount
  name: johndoe
# IAM service account
- kind: User
  name: test-account@test-project-123456.google.com.iam.gserviceaccount.com
# Google Group
- kind: Group
  name: accounting-group@example.com
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 RBAC, 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. Accédez à la page Journaux d'audit de Cloud Console.

      Accéder aux 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.

  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. Accédez à la page Visionneuse de journaux de Cloud Console.

      Accéder à la 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_LOCATION"
resource.labels.cluster_name="CLUSTER_NAME"
protoPayload.resourceName="authorization.k8s.io/v1beta1/subjectaccessreviews"
protoPayload.response.spec.user="EMAIL_ADDRESS"

      Remplacez l'élément suivant :

      • CLUSTER_LOCATION : région ou zone de votre cluster.
      • CLUSTER_NAME : nom du cluster
      • EMAIL_ADDRESS : 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 de ClusterRoles et ClusterRoleBindings 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 my-iam-account@somedomain.com :

    displayName: Some Domain IAM service account
email: my-iam-account@somedomain.com
etag: BwWWja0YfJA
name: projects/project-name/serviceAccounts/my-iam-account@somedomain.com
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