Contrôle d'accès

Ce document décrit les différences entre Identity and Access Management (IAM) et le contrôle des accès basé sur les rôles (RBAC, Role-Based Access Control) Kubernetes dans Google Kubernetes Engine pour vous aider à gérer l'accès aux ressources de votre projet. Ce document suppose que vous connaissez les éléments suivants :

Ce document s'adresse aux spécialistes de la sécurité qui contrôlent l'accès aux autorisations et qui souhaitent comprendre les différences et les points communs entre IAM et RBAC. Pour en savoir plus sur les rôles courants et les exemples de tâches que nous citons dans le contenuGoogle Cloud , consultez Rôles utilisateur et tâches courantes de GKE.

Gérer l'accès aux ressources GKE

Lorsque vous créez un projet Google Cloud , vous êtes le seul utilisateur du projet. Par défaut, aucun autre utilisateur n'a accès à votre projet ou à ses ressources, y compris aux ressources Google Kubernetes Engine (GKE). GKE accepte plusieurs options de gestion de l'accès aux ressources de votre projet et de ses clusters par le biais du contrôle des accès basé sur les rôles (RBAC, Role-Based Access Control).

Ces mécanismes présentent des fonctionnalités communes, mais ils ciblent différents types de ressources. Chacun est expliqué dans une section dédiée de cette page, mais pour résumer :

  • Kubernetes RBAC est intégré à Kubernetes et permet d'accorder des autorisations précises pour des objets de clusters Kubernetes. Les autorisations existent en tant qu'objets ClusterRole ou Role dans le cluster. Les objets RoleBinding attribuent des rôles auxutilisateurs Kubernetes, aux Google Cloud utilisateurs, aux comptes de service IAM ou à des Google Groupes.

    Si vous utilisez principalement GKE et que vous avez besoin de contrôler avec précision chaque objet et opération de votre cluster, Kubernetes RBAC constitue le meilleur choix.

  • IAM gère les ressources Google Cloud , y compris les clusters, et les types d'objets dans les clusters. Les autorisations sont attribuées aux comptes principaux IAM.

    Aucun mécanisme ne permet d'accorder des autorisations pour des objets Kubernetes spécifiques dans IAM. Par exemple, vous pouvez autoriser un utilisateur à créer des objets CustomResourceDefinition (CRD). Toutefois, vous ne pouvez pas lui accorder le droit de créer un seul objet CRD spécifique, ni limiter la création à un espace de noms ou à un cluster spécifique du projet. Un rôle IAM octroie des droits sur tous les clusters du projet, ou bien sur tous les clusters de tous les projets enfants s'il est appliqué au niveau du dossier.

    Si vous utilisez plusieurs composants Google Cloud et que vous n'avez pas besoin de gérer de façon précise des autorisations spécifiques à Kubernetes, IAM constitue un bon choix.

Kubernetes RBAC

Kubernetes étant compatible avec RBAC, vous pouvez créer des rôles ultraprécis qui existent dans le cluster Kubernetes. Un rôle peut être limité à un objet Kubernetes spécifique ou à un type d'objet Kubernetes, et il définit les actions (appelées verbes) que le rôle autorise concernant cet objet. Un RoleBinding est également un objet Kubernetes, et il attribue des rôles aux utilisateurs. Un utilisateur GKE peut être n'importe lequel des suivants :

  • Google Cloud user
  • Compte de service IAM
  • Compte de service Kubernetes
  • Utilisateur Google Workspace
  • Groupe Google Workspace
  • Utilisateurs authentifiés à l'aide de certificats clients X509

Pour en savoir plus, consultez la page Contrôle des accès basé sur les rôles.

IAM

Cloud IAM vous permet d'attribuer des rôles aux comptes principaux. Un rôle est un ensemble d'autorisations qui, lorsqu'il est attribué à un compte principal, permet à ce compte principal d'accéder à une ou plusieurs ressources Google Cloud. Pour en savoir plus sur les principaux, les rôles et d'autres termes IAM, consultez la présentation d'IAM.

Dans GKE, un compte principal peut être l'un des éléments suivants :

  • Compte utilisateur
  • Compte de service
  • Groupe Google Workspace
  • Domaine Google Workspace
  • Domaine Cloud Identity

Pour en savoir plus sur l'utilisation d'IAM pour contrôler les accès dans GKE, consultez Créer des stratégies d'autorisation IAM.

Types de stratégies IAM

IAM est compatible avec les types de stratégies suivants :

  • Stratégies d'autorisation : attribuez des rôles aux comptes principaux. Pour en savoir plus, consultez la section Stratégies d'autorisation.
  • Stratégies de refus : empêchez les comptes principaux d'utiliser des autorisations IAM spécifiques, quels que soient les rôles qui leur sont attribués. Pour en savoir plus, consultez la section Stratégies de refus.

Utilisez des stratégies de refus pour empêcher des comptes principaux spécifiques d'effectuer des actions spécifiques dans votre projet, dossier ou organisation, même si une stratégie d'autorisation IAM accorde à ces comptes principaux un rôle contenant les autorisations appropriées.

Recommandations IAM

Envisagez d'utiliser les rôles IAM prédéfinis suivants pour faciliter les scénarios courants :

Pour obtenir la liste des rôles IAM prédéfinis disponibles, consultez la section Rôles GKE prédéfinis.

GKE utilise des comptes de service IAM associés à vos nœuds pour exécuter des tâches système telles que la journalisation et la surveillance. Au minimum, ces comptes de service de nœud doivent disposer du rôle Compte de service de nœud par défaut Kubernetes Engine (roles/container.defaultNodeServiceAccount) sur votre projet. Par défaut, GKE utilise le compte de service Compute Engine par défaut, qui est créé automatiquement dans votre projet, en tant que compte de service de nœud.

Interaction d'IAM avec Kubernetes RBAC

IAM et Kubernetes RBAC fonctionnent conjointement pour vous aider à gérer les accès à votre cluster. RBAC contrôle l'accès au niveau du cluster et de l'espace de noms, tandis que IAM fonctionne au niveau du projet. Une entité doit disposer d'autorisations suffisantes, à ces deux niveaux, pour travailler sur les ressources du cluster.

Étape suivante