Autorisation et contrôle des accès

Identity and Access Management (IAM) dans Google Distributed Cloud (GDC) air-gapped vous permet de contrôler qui a accès à quelles ressources et quelles actions ces personnes peuvent effectuer 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 nécessaires pour exercer leurs rôles, tout en maintenant la sécurité de votre environnement 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 des connaissances de base sur les concepts de contrôle des accès. Pour en savoir plus, consultez la documentation sur les audiences pour GDC sous air gap.

Le 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 des ressources (où).

Le modèle de contrôle des accès

Le contrôle des accès se compose de deux étapes distinctes : prouver qui vous êtes (authentification) et déterminer ce que vous pouvez faire (autorisation) :

  • Authentification : GDC ne stocke pas les comptes utilisateur ni les mots de passe. GDC se connecte au fournisseur d'identité (IdP) de votre organisation pour que vous puissiez vous connecter avec vos identifiants d'entreprise.
  • Autorisation : après l'authentification, 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. Plutôt que de stocker des comptes utilisateur ou des mots de passe, GDC se connecte aux systèmes de connexion ou aux IdP existants de votre organisation (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 l'IdP de votre organisation. L'attribution d'un rôle à un groupe l'accorde automatiquement à tous les membres de ce groupe.

GDC utilise des IdP pour identifier de manière unique les identités humaines. Étant donné que votre environnement peut se connecter à plusieurs IdP (par exemple, si différents services utilisent des systèmes de connexion différents), GDC distingue les IdP 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 d'IdP unique à tous les noms d'utilisateur et groupes externes :

  • Format : idpprefix-username@domain.com (ou idpprefix-group-name pour les groupes).
  • Exemple : Si l'IdP 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 en tant que 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.

Comme les comptes de service sont gérés en interne par GDC, ils n'utilisent pas de préfixes IdP. 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 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 d'autorisations directement aux membres. À la place, 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 de rôles généraux comme "Lecteur de projet" à des rôles de service précis comme "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 des rôles IAM sont purement additives : elles accordent l'accès, mais n'incluent pas de règles de refus. Lorsque vous attribuez plusieurs rôles à un membre, celui-ci reçoit l'ensemble des 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 niveau s'appliquent automatiquement à toutes les zones par défaut.

Vous pouvez attribuer des rôles aux niveaux de ressources suivants :

  • Organisation : conteneur de niveau supérieur de votre environnement. Les rôles attribués au niveau de l'organisation s'appliquent à l'ensemble de l'organisation et sont automatiquement hérités par tous les projets et ressources qu'elle contient.
  • Projet : conteneur au sein de l'organisation utilisé pour regrouper les ressources d'équipes ou d'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 Hiérarchie des ressources et Contrôle des autorisations pour un univers multizone.

Comment l'accès est-il autorisé ?

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 d'autorisations directement à des utilisateurs ou à des charges de travail individuels. À la place, vous attribuez des rôles aux membres au niveau d'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 (un utilisateur humain, un groupe ou un compte de service) à un IAMRole au niveau d'une organisation ou d'un projet.

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

Par exemple, pour permettre à un membre de l'équipe d'afficher les machines virtuelles d'un projet, vous pouvez créer un IAMRoleBinding au niveau de ce projet, qui associe 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ôles actives, confirme que le rôle attribué contient l'autorisation requise et autorise la requête.

Alors 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 de s'authentifier 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 Se connecter et générer un fichier kubeconfig.

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

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

Si vous avez l'habitude de gérer les accès dans Google Cloud, GDC utilise des concepts similaires, mais les implémente différemment pour fonctionner dans une infrastructure Kubernetes sous air gap.

Le tableau suivant compare IAM dans GDC et Google Cloud :

Fonctionnalité Description GDC sous air gap Google Cloud
Identité des utilisateurs (authentification) Système d'identité utilisé pour authentifier les utilisateurs humains. Fédéré avec votre IdP externe à l'aide des préfixes IdP 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. Le service Cloud IAM mondial de Google. Évalue les requêtes API de manière centralisée par rapport aux règles 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 des rôles 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 mappant des membres à des rôles, et accepte 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 globales 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 sous forme de 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 ou régions de disponibilité. Utilise le RBAC Kubernetes géré par un serveur d'API global, qui coordonne et réplique les liaisons de rôles sur les serveurs d'API zonaux afin que l'accès s'applique par défaut à toutes les zones. Utilise un service IAM mondial entièrement géré. Les autorisations attribuées à n'importe quel niveau de ressource sont intrinsèquement globales et s'appliquent automatiquement à l'ensemble des régions et des zones.
Outils clients Interfaces principales, outils de CLI et API utilisés pour gérer les accès. Console GDC, gdcloud CLI et API KRM. Google Cloud console, gcloud CLI et les API REST ou gRPC.
Accès direct à l'API Comment les outils et les scripts s'authentifient pour gérer les ressources directement à l'aide des API. Pour accéder directement à l'API à l'aide de la CLI kubectl, vous devez vous authentifier 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 de manière globale à tous les services, sans nécessiter de connexions spécifiques au cluster.

Étapes suivantes