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 :

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

  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.

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

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

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

  • Cloud 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, Cloud 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.

Bien que Kubernetes RBAC puisse être utilisé à la place de Cloud IAM dans presque tous les cas, les utilisateurs de GKE doivent au moins disposer de l'autorisation Cloud 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 être fournie par Cloud 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, Cloud IAM ne peut pas créer un objet Kubernetes RBAC Role ou ClusterRole. Cependant, le rôle Cloud 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 e-mail de l'utilisateur Google Cloud cible.

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

Google Groupes pour GKE

Auparavant, vous ne pouviez attribuer des rôles qu'aux comptes utilisateur Google Cloud ou aux comptes de service Cloud IAM. Google Groupes pour GKE (version bêta) vous permet d’attribuer des rôles aux membres d’un groupe Google Groupes G Suite. Avec ce mécanisme, les utilisateurs et les groupes eux-mêmes sont gérés par les administrateurs G Suite, 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

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

  • Vous devez disposer d'un abonnement G Suite ou Cloud Identity.

Configurer Google Groupes pour une utilisation avec RBAC

La configuration de votre cluster pour l'utilisation de cette fonctionnalité ainsi que la syntaxe permettant de référencer un groupe Google Groupes G Suite 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 G Suite nommé gke-security-groups@yourdomain.com. Le nom du groupe doit être exactement gke-security-groups. Assurez-vous que le groupe gke-security-groups dispose de l'autorisation "Afficher les membres" pour les "Membres du groupe". Consultez cet article pour découvrir comment définir ce paramètre dans la console d'administration G Suite.

    Vous pouvez également consulter le centre d'aide Google Groupes pour plus d'informations sur la gestion des groupes dans G Suite.

  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@yourdomain.com.

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. L'utilisateur doit également faire partie du même domaine que le groupe et le cluster. Cela signifie que l'autorisation interdomaine ne fonctionne pas avec cette fonctionnalité.

Les informations sur les membres du groupe Google Groupes G Suite 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

Une fois que votre administrateur Google Groupes G Suite configure vos groupes, créez un cluster à l'aide de la commande gcloud et ajoutez l'option --security-group="gke-security-groups@yourdomain.com", en remplaçant la valeur par votre propre nom de domaine.

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

gcloud beta container clusters create cluster-name \
  --security-group="gke-security-groups@yourdomain.com"

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

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 "s'ajoutent" : 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"]

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, notamment :

  • Ressources à l'échelle du cluster, telles que les nœuds
  • Points de terminaison 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 Cloud IAM User Adresse e-mail du compte de service Cloud IAM générée automatiquement
Adresse du groupe Google Groupes G Suite (version bêta) sur un domaine validé Group Adresse e-mail d'un groupe Google Groupes, lui-même membre du groupe Google Groupes gke-security-groups@yourdomain.com

L'objet RoleBinding suivant attribue le rôle pod-reader à un utilisateur, à un compte de service Kubernetes, à un compte de service Cloud 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
# Cloud IAM service account
- kind: User
  name: test-account@test-project-123456.google.com.iam.gserviceaccount.com
# G Suite 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 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 Cloud 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.

  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 de votre 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:basic-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