Autorisation et contrôle des accès

Identity and Access Management (IAM) dans Google Distributed Cloud (GDC) sous air gap vous permet de contrôler qui a accès à quelles ressources et quelles actions peuvent être effectuées sur ces ressources.

Comprendre le fonctionnement d'IAM dans GDC vous aide à gérer efficacement les accès, en veillant à ce que les membres disposent des autorisations dont ils ont besoin pour exercer leurs fonctions tout en maintenant la sécurité de votre environnement sous air gap.

Ce document est destiné aux audiences des groupes d'administrateurs de plate-forme et d'opérateurs d'applications (tels que les administrateurs informatiques, les ingénieurs en sécurité ou les développeurs d'applications) qui souhaitent comprendre l'autorisation et le contrôle des accès dans GDC sous air gap. Ce document aide également les opérateurs d'infrastructure à acquérir une compréhension de base des concepts de contrôle des accès. Pour en savoir plus, consultez la documentation sur les audiences pour GDC sous air gap.

Modèle de contrôle des accès

GDC structure l'accès autour de trois composants principaux : les membres (qui), les rôles (quoi) et le champ d'application de la ressource (où).

Modèle de contrôle des accès

Le contrôle des accès comporte deux étapes distinctes : prouver votre identité (authentification) et déterminer ce que vous pouvez faire (autorisation) :

  • Authentification : GDC ne stocke pas les comptes ni les mots de passe des utilisateurs. GDC se connecte au fournisseur d'identité (IdP) de votre organisation pour que vous puissiez vous connecter avec vos identifiants d'entreprise.
  • Autorisation : une fois que vous vous êtes authentifié, GDC IAM vérifie les rôles qui vous sont attribués pour déterminer les ressources auxquelles vous pouvez accéder et les actions que vous pouvez effectuer.

Membres

Un membre est une identité à laquelle vous pouvez accorder l'accès à une ressource. GDC regroupe les membres en deux catégories principales en fonction de l'endroit où vous les gérez : les identités humaines et les identités non humaines.

Identités humaines

Les identités humaines sont les utilisateurs et les groupes qui se connectent à GDC. Au lieu de stocker les comptes ou les mots de passe des utilisateurs, GDC se connecte aux systèmes de connexion existants de votre organisation, ou aux fournisseurs d'identité (tels qu'Active Directory, LDAP ou Okta), à l'aide de protocoles de fédération d'identité standards tels qu'OpenID Connect (OIDC) ou SAML 2.0.

Il existe deux types d'identités humaines :

  • Utilisateurs : utilisateurs humains individuels qui se connectent au système à l'aide de leurs identifiants d'entreprise.
  • Groupes : ensembles d'utilisateurs humains gérés dans le fournisseur d'identité de votre organisation. L'attribution d'un rôle à un groupe l'accorde automatiquement à tous les membres de ce groupe.

GDC utilise des fournisseurs d'identité pour identifier de manière unique les identités humaines. Étant donné que votre environnement peut se connecter à plusieurs fournisseurs d'identité (par exemple, si différents services utilisent des systèmes de connexion différents), GDC fait la distinction entre les fournisseurs d'identité pour s'assurer que vous accordez l'accès à la bonne personne.

Lors de la gestion des accès, GDC ajoute automatiquement un préfixe de fournisseur d'identité unique à tous les noms d'utilisateur et groupes externes :

  • Format : idpprefix-username@domain.com (ou idpprefix-group-name pour les groupes).
  • Exemple : Si le fournisseur d'identité de votre organisation est configuré avec le préfixe agency-a et que vous vous connectez en tant que alice@example.com, GDC IAM vous reconnaît comme agency-a-alice@example.com.

Identités non humaines

Les identités non humaines sont appelées identités de service (ou comptes de service). Vous les créez et les gérez directement dans GDC (en tant que ressources ProjectServiceAccount) pour permettre aux applications, aux scripts ou aux charges de travail automatisées d'interagir avec les API de manière sécurisée.

Étant donné que les comptes de service sont gérés en interne par GDC, ils n'utilisent pas de préfixes de fournisseur d'identité. Ils sont plutôt identifiés par leur projet et leur nom (par exemple, serviceAccount:projectName:serviceAccountName lorsque vous utilisez la CLI gdcloud).

Pour en savoir plus, consultez la section Sécuriser les clés de compte de service.

Autorisations et rôles

Une autorisation est le droit d'effectuer une action spécifique sur une ressource (par exemple, créer une VM ou supprimer une base de données). Vous n'accordez pas directement d'autorisations aux membres. Au lieu de cela, GDC regroupe les autorisations dans des rôles.

GDC propose deux types de rôles :

  • Rôles prédéfinis : ensembles d'autorisations intégrés créés et gérés par GDC. GDC fournit une bibliothèque complète de rôles prédéfinis adaptés à des fonctions et services spécifiques (allant des rôles généraux tels que Lecteur de projet aux rôles de service précis tels qu'Administrateur de projet de bucket ou Lecteur KMS).
  • Rôles personnalisés : ensembles d'autorisations définis par l'utilisateur que vous pouvez créer lorsque les rôles prédéfinis existants ne répondent pas aux besoins de votre organisation.

Les autorisations accordées via les rôles IAM sont purement additives. Elles accordent l'accès, mais n'incluent pas de règles de refus. Lorsque vous accordez plusieurs rôles à un membre, celui-ci reçoit la combinaison de toutes les autorisations de ces rôles. Pour limiter ou refuser l'accès à des services spécifiques dans votre organisation, vous pouvez configurer des règles d'administration.

Champ d'application de la ressource

Vous accordez toujours l'accès à un niveau spécifique de la hiérarchie des ressources GDC. Le champ d'application détermine les ressources auxquelles le membre peut accéder. Dans les environnements multizones, les rôles attribués à l'un ou l'autre champ d'application s'appliquent automatiquement à toutes les zones par défaut.

Vous pouvez accorder des rôles aux champs d'application de ressources suivants :

  • Organisation : conteneur de premier niveau pour votre environnement. Les rôles accordés au niveau de l'organisation s'appliquent à l'ensemble de l'organisation, en héritant automatiquement de tous les projets et ressources qu'elle contient.
  • Projet : conteneur au sein de l'organisation utilisé pour regrouper des ressources pour des équipes ou des applications spécifiques. Les projets servent de limites de sécurité strictes : les rôles accordés au niveau du projet ne s'appliquent qu'à ce projet spécifique et à ses ressources (telles que les machines virtuelles, les bases de données et les clusters Kubernetes).

Pour en savoir plus, consultez la section Hiérarchie des ressources et Contrôle des autorisations pour un univers multizone.

Autorisation de l'accès

GDC gère et autorise l'accès principalement à l'aide d'un modèle de contrôle des accès basé sur les rôles (RBAC). Dans un modèle RBAC, vous n'attribuez pas directement d'autorisations à des utilisateurs ou des charges de travail individuels. Au lieu de cela, vous attribuez des rôles aux membres dans un champ d'application de ressource spécifique pour déterminer l'accès.

GDC implémente le RBAC à l'aide des ressources personnalisées Kubernetes suivantes :

  • IAMRole : définit un ensemble spécifique d'autorisations.
  • IAMRoleBinding : associe un membre (utilisateur humain, groupe ou compte de service) à un IAMRole au niveau d'une organisation ou d'un projet.

Pour accorder l'accès à des ressources d'organisation ou de projet, vous pouvez créer un IAMRoleBinding à l'aide de la console GDC, de la CLI gdcloud ou en appliquant des manifestes de ressources personnalisés (fichiers YAML) à l'aide de la CLI kubectl.

Par exemple, pour autoriser un membre de l'équipe à afficher les machines virtuelles d'un projet, vous pouvez créer un IAMRoleBinding au niveau de ce projet en associant l'identité du membre à un rôle de lecteur. Lorsque le membre tente d'afficher une machine virtuelle, GDC vérifie ses liaisons de rôle actives, confirme que le rôle attribué contient l'autorisation requise et autorise la requête.

Bien que la console GDC et la CLI gdcloud se connectent automatiquement à vos ressources, l'accès direct à l'API à l'aide de la CLI kubectl nécessite une authentification auprès du cluster Kubernetes ou du serveur d'API spécifique hébergeant cette ressource en générant un fichier kubeconfig. Pour en savoir plus, consultez la section Se connecter et générer un fichier kubeconfig.

Pour en savoir plus sur la gestion des liaisons de rôles, consultez la section Accorder et révoquer l'accès.

Différences entre GDC sous air gap et IAM Google Cloud

Si vous avez de l'expérience dans la gestion des accès dans Google Cloud, GDC utilise des concepts similaires, mais les implémente différemment pour fonctionner dans une infrastructure sous air gap basée sur Kubernetes.

Le tableau suivant compare IAM dans GDC et Google Cloud:

Fonctionnalité Description GDC sous air gap Google Cloud
Identité de l'utilisateur (authentification) Système d'identité utilisé pour authentifier les utilisateurs humains. Fédéré avec votre fournisseur d'identité externe à l'aide des préfixes de fournisseur d'identité requis (par exemple, idpprefix-user@domain.com). Comptes Google (tels que Gmail) ou identités d'entreprise fédérées via Cloud Identity ou Google Workspace.
Moteur d'autorisation Système sous-jacent qui évalue et applique les autorisations. Principalement le contrôle des accès basé sur les rôles (RBAC) de Kubernetes, où les requêtes d'accès sont évaluées localement par le serveur d'API par rapport aux liaisons de rôles. Vous pouvez utiliser des règles d'administration pour définir des restrictions de ressources. Service Cloud IAM mondial de Google. Évalue les requêtes d'API de manière centralisée par rapport aux stratégies d'accès associées à n'importe quel niveau de la hiérarchie des ressources.
Liaisons de rôles Comment les membres sont mappés aux rôles sur des ressources spécifiques. Ressources personnalisées IAMRoleBinding individuelles. Chaque liaison est un objet qui associe des membres à un rôle. Les autorisations de rôle IAM sont purement additives (les règles de refus peuvent être configurées séparément via des règles d'administration). Une seule stratégie d'accès IAM associée à chaque ressource, dossier ou organisation. Contient plusieurs liaisons qui mappent les membres aux rôles et prend en charge les règles conditionnelles ou les règles de refus.
Comptes de service Identités non humaines utilisées par les applications et les charges de travail automatisées. Comptes de service locaux créés dans un projet spécifique (ProjectServiceAccount). Les clés publiques sont stockées dans le cluster, tandis que les clés privées sont gérées et sécurisées localement par le client. Identités mondiales gérées de manière centralisée par Google. Les identifiants peuvent être gérés automatiquement par Google ou téléchargés en tant que fichiers de clés pour s'authentifier depuis n'importe où.
Hiérarchie des ressources Structure de conteneur utilisée pour organiser les ressources et hériter des autorisations. Hiérarchie à deux niveaux : organisation > projets Hiérarchie à plusieurs niveaux : organisation > dossiers > projets
Champ d'application des autorisations multizones Comment les autorisations sont évaluées et propagées dans les zones de disponibilité ou régions. Utilise le RBAC Kubernetes géré par un serveur d'API mondial, qui coordonne et réplique les liaisons de rôles sur les serveurs d'API zonaux afin que l'accès s'applique à toutes les zones par défaut. Utilise un service IAM mondial entièrement géré. Les autorisations attribuées à n'importe quel niveau de ressource sont intrinsèquement mondiales et s'appliquent à toutes les régions et zones automatiquement.
Outils clients Interfaces principales, outils CLI et API utilisés pour gérer l'accès. Console GDC, CLI gdcloud et API KRM. Google Cloud Console, gcloud CLI et API REST ou gRPC.
Accès direct à l'API Comment les outils et les scripts s'authentifient pour gérer directement les ressources à l'aide des API. L'accès direct à l'API à l'aide de la CLI kubectl nécessite une authentification auprès du cluster Kubernetes ou du serveur d'API spécifique hébergeant cette ressource en générant un fichier kubeconfig. (La console GDC et la CLI gdcloud se connectent automatiquement aux ressources.) L'accès direct à l'API à l'aide de gcloud ou de points de terminaison REST/gRPC utilise des identifiants centralisés (gcloud auth login) qui s'appliquent globalement à tous les services sans nécessiter de connexion spécifique au cluster.

Étape suivante