Présentation d'IAM

Cette page décrit le fonctionnement du système IAM (gestion de l'authentification et des accès) de Trusted Cloud by S3NSet explique comment l'utiliser pour gérer les accès dans Trusted Cloud.

IAM est un outil permettant de gérer les autorisations précises pourTrusted Cloud. En d'autres termes, il vous permet de contrôler qui peut faire quoi sur quelles ressources.

Accès dans Trusted Cloud

Chaque action dans Trusted Cloud nécessite certaines autorisations. Lorsqu'un utilisateur tente d'effectuer une action dans Trusted Cloud(par exemple, créer une instance de VM ou afficher un ensemble de données), IAM vérifie d'abord s'il dispose des autorisations requises. Si ce n'est pas le cas, IAM l'empêche d'effectuer l'action.

Pour accorder des autorisations à un utilisateur dans IAM, vous devez utiliser les trois composants suivants :

  • Compte principal : identité de la personne ou du système auxquels vous souhaitez accorder des autorisations.
  • Rôle : ensemble d'autorisations que vous souhaitez accorder au compte principal
  • Resource (Ressource) : ressource Trusted Cloud à laquelle vous souhaitez autoriser l'accès au compte principal.

Pour autoriser le compte principal à accéder à la ressource, vous lui attribuez le rôle sur la ressource. Vous attribuez ces rôles à l'aide d'une stratégie d'autorisation.

Les sections suivantes décrivent ces concepts plus en détail.

Comptes principaux

Dans Trusted Cloud , vous contrôlez l'accès des comptes principaux. Les comptes principaux représentent une ou plusieurs identités authentifiées auprès de Trusted Cloud.

Par le passé, les comptes principaux étaient appelés membres. Certaines API utilisent toujours ce terme.

Il existe différents types de comptes principaux dans IAM, mais ils peuvent être divisés en deux grandes catégories :

  • Utilisateurs humains : certains types de principaux IAM représentent des utilisateurs humains. Vous utilisez ces types de comptes principaux pour gérer l'accès de vos employés aux ressourcesTrusted Cloud .

    Par exemple, les identités fédérées dans les pools d'identités de personnel représentent des utilisateurs humains.

  • Charges de travail : certains types de comptes principaux IAM représentent des charges de travail. Vous utilisez ces types de comptes principaux lorsque vous gérez l'accès de vos charges de travail aux ressourcesTrusted Cloud .

    Les types d'entités principales qui représentent des charges de travail incluent les comptes de service et les identités fédérées dans un pool d'identités de charge de travail.

Pour en savoir plus sur les comptes principaux, consultez Comptes principaux IAM.

Autorisations et rôles

Les autorisations déterminent les opérations autorisées sur une ressource. Dans IAM, les autorisations sont généralement représentées sous la forme service.resource.verb. Souvent, les autorisations correspondent les unes aux autres avec les méthodes de l'API REST. Par exemple, l'autorisation resourcemanager.projects.list vous permet de lister les projets Resource Manager.

Vous ne pouvez pas accorder directement des autorisations à un compte principal. À la place, vous accordez des autorisations aux comptes principaux en leur attribuant des rôles.

Les rôles sont des ensembles d'autorisations. Lorsque vous attribuez un rôle à un compte principal, vous lui accordez toutes les autorisations de ce rôle.

Il existe trois types de rôles :

  • Rôles prédéfinis : rôles gérés par les services Trusted Cloud . Ces rôles contiennent les autorisations nécessaires pour effectuer des tâches courantes pour chaque service donné. Par exemple, le rôle Diffuseur Pub/Sub (roles/pubsub.publisher) permet de publier des messages dans un sujet Pub/Sub.

  • Rôles personnalisés : rôles que vous créez et qui ne contiennent que les autorisations que vous spécifiez. Vous contrôlez entièrement les autorisations de ces rôles. Toutefois, ils sont plus difficiles à gérer que les rôles prédéfinis. De plus, le nombre de rôles personnalisés que vous pouvez avoir dans votre projet et votre organisation est limité.

  • Rôles de base : rôles très permissifs qui offrent un accès étendu aux servicesTrusted Cloud . Ces rôles peuvent être utiles à des fins de test, mais ne doivent pas être utilisés dans les environnements de production.

Pour en savoir plus sur les rôles et les autorisations, consultez Rôles et autorisations.

Ressources

La plupart des services Trusted Cloud ont leurs propres ressources. Par exemple, Compute Engine dispose de ressources telles que des instances, des disques et des sous-réseaux.

Dans IAM, vous attribuez des rôles sur une ressource. Accorder un rôle à un compte principal sur une ressource signifie que le compte principal peut utiliser les autorisations de ce rôle pour accéder à la ressource.

Vous pouvez attribuer des rôles à un sous-ensemble de ressources Trusted Cloud . Pour obtenir la liste complète des ressources sur lesquelles vous pouvez attribuer des rôles, consultez Types de ressources compatibles avec les stratégies d'autorisation.

Trusted Cloud dispose également de plusieurs ressources de conteneur, y compris des projets, des dossiers et des organisations. Si vous accordez un rôle à un compte principal sur une ressource de conteneur, ce compte principal aura accès à la ressource de conteneur et aux ressources de ce conteneur. Cette fonctionnalité vous permet d'utiliser une seule attribution de rôle pour accorder à un compte principal l'accès à plusieurs ressources, y compris celles pour lesquelles vous ne pouvez pas attribuer de rôles directement. Pour en savoir plus, consultez la section Héritage des stratégies sur cette page.

Règles d'autorisation

Vous attribuez des rôles aux comptes principaux à l'aide de stratégies d'autorisation. Par le passé, ces stratégies étaient appelées stratégies IAM.

Une stratégie d'autorisation est un objet YAML ou JSON associé à une ressource Trusted Cloud.

Chaque stratégie d'autorisation contient une liste de liaisons de rôles qui associent des rôles IAM aux comptes principaux auxquels ces rôles sont attribués.

Lorsqu'un compte principal authentifié tente d'accéder à une ressource, Cloud IAM vérifie la stratégie d'autorisation de la ressource pour déterminer si le compte principal dispose des autorisations requises. Si le compte principal est associé à une liaison de rôle qui inclut un rôle doté des autorisations requises, il est autorisé à accéder à la ressource.

Pour voir des exemples de stratégies d'autorisation et en savoir plus sur leur structure, consultez Comprendre les stratégies d'autorisation.

Héritage des règles

Trusted Cloud dispose de ressources de conteneur, telles que des projets, des dossiers et des organisations, qui vous permettent d'organiser vos ressources dans une hiérarchie parent-enfant. Cette hiérarchie est appelée hiérarchie des ressources.

La hiérarchie des ressources Trusted Cloud présente la structure suivante :

  • L'organisation constitue le nœud racine de la hiérarchie.
  • Les dossiers représentent les enfants de l'organisation ou d'un autre dossier.
  • Les projets représentent les enfants de l'organisation ou d'un dossier.
  • Les ressources pour chaque service sont les enfants des projets.

Le schéma suivant montre un exemple de hiérarchie des ressources Trusted Cloud  :

Hiérarchie des ressources IAM

Si vous définissez une stratégie d'autorisation sur une ressource de conteneur, elle s'applique également à toutes les ressources de ce conteneur. Ce concept est appelé héritage des stratégies, car les ressources descendantes héritent effectivement des stratégies d'autorisation de leurs ressources ascendantes.

L'héritage des règles a les implications suivantes :

  • Vous pouvez utiliser une seule liaison de rôle pour accorder l'accès à plusieurs ressources. Si vous souhaitez donner à un compte principal l'accès à toutes les ressources d'un conteneur, attribuez-lui un rôle sur le conteneur plutôt que sur les ressources qu'il contient.

    Par exemple, si vous souhaitez autoriser votre administrateur de sécurité à gérer les stratégies d'autorisation pour toutes les ressources de votre organisation, vous pouvez lui attribuer le rôle Administrateur de sécurité (roles/iam.securityAdmin) au niveau de l'organisation.

  • Vous pouvez accorder l'accès à des ressources qui ne disposent pas de leur propre stratégie d'autorisation. Toutes les ressources n'acceptent pas les stratégies d'autorisation, mais toutes les ressources héritent des stratégies d'autorisation de leurs ancêtres. Pour accorder à un compte principal l'accès à une ressource qui ne peut pas avoir sa propre stratégie d'autorisation, attribuez-lui un rôle sur l'un des ancêtres de la ressource.

    Par exemple, imaginons que vous souhaitiez autoriser un utilisateur à écrire des journaux dans un bucket de journaux. Les buckets de journaux ne disposent pas de leurs propres stratégies d'autorisation. Pour accorder cette autorisation à un utilisateur, vous pouvez lui attribuer le rôle "Auteur de buckets de journaux" (roles/logging.bucketWriter) sur le projet contenant le bucket de journaux.

  • Pour savoir qui peut accéder à une ressource, vous devez également afficher toutes les stratégies d'autorisation qui affectent la ressource. Pour obtenir la liste complète des principaux ayant accès à la ressource, vous devez afficher la stratégie d'autorisation de la ressource et celles de ses ancêtres. L'union de toutes ces stratégies est appelée stratégie d'autorisation applicable.

Pour en savoir plus sur l'héritage des stratégies d'autorisation, consultez Utiliser la hiérarchie des ressources pour le contrôle des accès.

Contrôle d'accès avancés

En plus des stratégies d'autorisation, IAM fournit les mécanismes de contrôle d'accès suivants pour vous aider à affiner qui a accès à quelles ressources :

  • Stratégies de refus : elles empêchent les comptes principaux d'utiliser certaines autorisations, même si un rôle leur est attribué avec cette autorisation. Pour en savoir plus sur les stratégies de refus, consultez Stratégies de refus.

  • Conditions IAM : les conditions IAM vous permettent de définir et d'appliquer un contrôle des accès conditionnel basé sur des attributs. Vous pouvez utiliser des conditions dans différents types de règles. Par exemple, vous pouvez ajouter une condition à une liaison de rôle dans une stratégie d'autorisation pour vous assurer que le rôle n'est accordé que si la condition est remplie.

    Vous pouvez écrire des conditions basées sur des attributs tels que la ressource dans la requête et l'heure de la requête.

    Pour en savoir plus sur les conditions IAM, consultez la présentation des conditions IAM.

Modèle de cohérence pour l'API IAM

L'API IAM est cohérente à terme. En d'autres termes, si vous écrivez des données avec l'API IAM, puis que vous les lisez immédiatement, l'opération de lecture peut renvoyer une ancienne version des données. En outre, les modifications que vous apportez peuvent prendre un certain temps pour affecter les contrôles d'accès.

Ce modèle de cohérence affecte le fonctionnement de l'API IAM. Par exemple, si vous créez un compte de service, puis que vous faites immédiatement référence à ce compte de service dans une autre requête, l'API IAM peut dire que le compte de service est introuvable. Ce comportement est dû au fait que les opérations sont cohérentes à terme. Il peut s'écouler un certain temps avant que le nouveau compte de service ne devienne visible par les requêtes de lecture.

Étapes suivantes