Autoriser des actions dans les clusters à l'aide du contrôle des accès basé sur les rôles

Cette page explique comment autoriser des actions sur les ressources de vos clusters Google Kubernetes Engine (GKE) à l'aide du mécanisme intégré de contrôle des accès basé sur les rôles (RBAC) dans Kubernetes.

RBAC est une fonctionnalité de sécurité de base de Kubernetes qui vous permet de créer des autorisations précises pour gérer les actions que les utilisateurs et les charges de travail peuvent effectuer sur les ressources de vos clusters. En tant qu'administrateur de plate-forme, vous créez des rôles RBAC et associez ces rôles à des objets, qui sont des utilisateurs authentifiés, tels que des comptes de service ou des groupes. Le contrôle Kubernetes RBAC est activé par défaut.

Avant de commencer

Avant de commencer, effectuez les tâches suivantes :

  • Activez l'API Google Kubernetes Engine.
    • Activer l'API Google Kubernetes Engine
  • Si vous souhaitez utiliser Google Cloud CLI pour cette tâche, installez puis initialisez gcloud CLI. Si vous avez déjà installé gcloud CLI, assurez-vous de disposer de la dernière version en exécutant la commande 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.

  • Pour autoriser une action, GKE recherche d'abord une stratégie RBAC. En l'absence de stratégie RBAC, GKE recherche les autorisations IAM.

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.

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 de Roles ou de ClusterRoles

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 de 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 Workspace membre du groupe gke-security-groups. Pour obtenir des instructions sur la configuration de Google Groupes pour RBAC, consultez la page Configurer Google Groupes pour RBAC.

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.iam.gserviceaccount.com
# Google Group
- kind: Group
  name: accounting-group@example.com
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Vérifier l'accès à l'API à l'aide de kubectl

kubectl fournit la sous-commande auth can-i pour interroger rapidement la couche d'autorisation de l'API. En tant qu'administrateur de plate-forme, vous devrez peut-être emprunter l'identité des utilisateurs pour déterminer les actions qu'ils peuvent effectuer. Vous pouvez utiliser auth can-i et transmettre une option --as supplémentaire.

Lorsque vous exécutez la commande kubectl auth can-i sans l'option --as, Identity and Access Management (IAM) effectue l'autorisation. En revanche, lorsque vous ajoutez l'option --as, Kubernetes RBAC effectue l'autorisation. Par conséquent, vous devrez créer les objets Role et RoleBinding nécessaires pour RBAC.

Pour en savoir plus, consultez la section Vérifier l'accès à l'API.

Utilisation de l'API et exemples

Pour obtenir des informations complètes sur l'utilisation de l'API Kubernetes lors 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, les journaux du serveur d'API enregistrent 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.

Limites

Les sections suivantes décrivent des mises en garde concernant l'utilisation de Kubernetes RBAC et d'IAM.

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.

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.

Les utilisateurs anonymes (system:unauthenticated) reçoivent à 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

Autorisation de créer ou de mettre à jour des rôles et des liaisons de rôles

Dans Kubernetes, vous ne pouvez créer ou mettre à jour un rôle ou une liaison de rôle avec des autorisations spécifiques que si vous remplissez les conditions suivantes :

  • Créer ou mettre à jour un rôle : vous devez disposer des mêmes autorisations que celles à attribuer au rôle. Autrement, vous devez être autorisé à exécuter le verbe escalate sur le rôle.
  • Créer ou mettre à jour une liaison de rôle : vous devez disposer des mêmes autorisations que celles accordées dans le rôle lié, avec le même niveau d'accès que la liaison de rôle. Autrement, vous devez être autorisé à exécuter le verbe bind sur le rôle référencé.

Si les autorisations que vous accordez dans le rôle vous ont été initialement accordées à l'aide d'une stratégie d'autorisation IAM au lieu du RBAC, votre demande de rôle ou de liaison de rôle peut échouer. Par exemple, considérons la requête de création de rôle suivante, provenant d'un utilisateur disposant des autorisations IAM container.pods.* et container.roles.create :

kubectl create role allowed-to-view-pods --resource pods --verb list,get

Si l'utilisateur n'a reçu les autorisations qu'en utilisant IAM, l'erreur suivante peut se produire :

Error from server (Forbidden): clusterroles.rbac.authorization.k8s.io "allowed-to-view-pods" is forbidden:
user "caller@example.com" (groups=["system:authenticated"]) is attempting to grant RBAC permissions not currently held:
{APIGroups:[""], Resources:["pods"], Verbs:["list" "get"]}

Pour contourner cette limitation, accordez à l'appelant les autorisations du rôle en utilisant RBAC au lieu d'IAM.

Vous pouvez également utiliser RBAC ou IAM pour accorder à l'appelant le verbe escalate, le verbe bind ou les deux. Toutefois, GKE ne recommande pas cette approche, car l'appelant peut ensuite accorder n'importe quelle autorisation à n'importe quel rôle.

Étapes suivantes