Identity and Access Management

Utilisation

Cette page présente Identity and Access Management (IAM) et explique comment vous pouvez l'utiliser pour contrôler l'accès aux ressources telles que les buckets, les dossiers gérés et les objets dans Cloud Storage.

Présentation

IAM vous permet de contrôler qui a accès aux ressources de votre projet Google Cloud. Les ressources incluent les buckets Cloud Storage, les dossiers gérés et les objets stockés dans les buckets, ainsi que d'autres entités Google Cloud telles que les instances Compute Engine.

Les comptes principaux sont les "acteurs" d'IAM. Il peut s'agir d'utilisateurs individuels, de groupes, de domaines ou même du public dans son ensemble. Les comptes principaux se voient attribuer des rôles qui leur permettent d'effectuer des actions dans Cloud Storage ainsi que dans Google Cloud plus généralement. Chaque rôle est un ensemble constitué d'une ou plusieurs autorisations. Les autorisations sont les unités de base d'IAM : chaque autorisation vous permet d'effectuer une action donnée.

Par exemple, l'autorisation storage.objects.create vous permet de créer des objets. Cette autorisation est présente dans des rôles tels que Créateur des objets de l'espace de stockage (roles/storage.objectCreator) qui accorde les autorisations utiles pour créer des objets dans un bucket, et Administrateur des objets de l'espace de stockage (roles/storage.objectAdmin) qui accorde un large éventail d'autorisations pour travailler avec des objets.

L'ensemble des rôles IAM que vous définissez sur une ressource est appelé stratégie IAM. L'accès accordé par ces rôles s'applique à la ressource sur laquelle la stratégie est définie et à toutes les ressources que cette ressource contient. Par exemple, vous pouvez définir une stratégie IAM sur un bucket qui permet à un utilisateur d'exercer un contrôle administratif sur ce bucket et ses objets. Vous pouvez également définir une stratégie IAM sur le projet global, qui permet à un autre utilisateur d'afficher des objets dans n'importe quel bucket de ce projet.

Si vous disposez d'une ressource d'organisation Google Cloud, vous pouvez également utiliser des stratégies de refus IAM pour refuser l'accès aux ressources. Lorsqu'une stratégie de refus est associée à une ressource, le compte principal ne peut pas utiliser l'autorisation spécifiée pour accéder à la ressource ni à aucune sous-ressource, quels que soient les rôles qui lui sont attribués. Les stratégies de refus ont la priorité sur les stratégies d'autorisation IAM.

Autorisations

Les autorisations permettent aux comptes principaux de réaliser des opérations spécifiques sur des buckets, des dossiers gérés ou des objets dans Cloud Storage. Par exemple, l'autorisation storage.buckets.list permet à un compte principal de lister les buckets dans votre projet. Vous n'accordez pas directement d'autorisations aux comptes principaux. Vous accordez plutôt des rôles auxquels sont associées une ou plusieurs autorisations.

Pour obtenir la liste de référence des autorisations IAM qui s'appliquent à Cloud Storage, consultez la page Autorisations IAM pour Cloud Storage.

Rôles

Les rôles sont des ensembles constitués d'une ou plusieurs autorisations. Par exemple, le rôle Lecteur des objets de l'espace de stockage (roles/storage.objectViewer) contient les autorisations storage.objects.get et storage.objects.list. Vous attribuez des rôles aux comptes principaux, ce qui leur permet d'effectuer des actions sur les buckets, les dossiers gérés et les objets de votre projet.

Pour obtenir la liste de référence des rôles IAM qui s'appliquent à Cloud Storage, consultez la page Rôles IAM pour Cloud Storage.

Attribuer des rôles au niveau du projet, du bucket ou du dossier géré

Vous pouvez attribuer des rôles aux comptes principaux au niveau du projet, du bucket ou du dossier géré. Les autorisations attribuées par ces rôles s'ajoutent les unes aux autres dans la hiérarchie des ressources. Vous pouvez attribuer des rôles à différents niveaux de la hiérarchie des ressources pour plus de précision dans votre modèle d'autorisations.

Par exemple, imaginons que vous souhaitiez autoriser un utilisateur à lire des objets dans n'importe quel bucket d'un projet, mais en ne l'autorisant à créer des objets que dans le bucket A. Pour ce faire, vous pouvez lui attribuer le rôle Lecteur des objets Storage (roles/storage.objectViewer) sur le projet, ce qui l'autorise à lire n'importe quel objet stocké dans n'importe quel bucket au sein de votre projet, et le rôle Créateur d'objets Storage (roles/storage.objectCreator) sur le bucket A, ce qui l'autorise à créer des objets uniquement dans ce bucket.

Certains rôles peuvent être utilisés à tous les niveaux de la hiérarchie des ressources. Lorsque les rôles sont utilisés au niveau du projet, les autorisations qu'ils contiennent s'appliquent à tous les buckets, dossiers et objets du projet. Lorsqu'ils sont utilisés au niveau du bucket, les autorisations associées ne s'appliquent qu'à un bucket spécifique et aux dossiers et objets qu'il contient. Exemples de rôles de ce type : Administrateur Storage (roles/storage.admin), Lecteur d'objets Storage (roles/storage.objectViewer) et Créateur d'objets Storage (roles/storage.objectCreator).

Certains rôles ne peuvent être appliqués qu'à un seul niveau. Par exemple, vous ne pouvez appliquer le rôle Propriétaire des anciens objets Storage (roles/storage.legacyObjectOwner) qu'au niveau du bucket ou du dossier géré. Les rôles IAM qui vous permettent de contrôler les stratégies de refus IAM ne peuvent être appliqués qu'au niveau de l'organisation.

Lien avec les LCA

Dans IAM, les rôles liés aux anciens buckets fonctionnent en tandem avec les LCA de bucket : lorsque vous ajoutez ou supprimez un rôle de ce type, les LCA associées au bucket reflètent vos modifications. De même, la modification d'une LCA spécifique à un bucket met à jour le rôle IAM associé aux anciens buckets correspondant au bucket.

Rôle "Legacy Bucket" LCA équivalente
Lecteur des anciens buckets de l'espace de stockage (roles/storage.legacyBucketReader) Lecteur de bucket
Rédacteur des anciens buckets de l'espace de stockage (roles/storage.legacyBucketWriter) Rédacteur de bucket
Propriétaire des anciens buckets Cloud Storage (roles/storage.legacyBucketOwner) Propriétaire de bucket

Tous les autres rôles IAM au niveau du bucket, y compris les anciens rôles IAM, fonctionnent indépendamment des LCA. De même, tous les rôles IAM au niveau du projet fonctionnent indépendamment des LCA. Par exemple, si vous attribuez à un utilisateur le rôle Lecteur des objets de l'espace de stockage (roles/storage.objectViewer), les LCA demeurent inchangées. Cela signifie que vous pouvez utiliser des rôles IAM au niveau du bucket pour accorder un accès étendu à tous les objets d'un bucket, et utiliser les LCA d'objet qui permettent un contrôle ultraprécis pour personnaliser l'accès à des objets spécifiques dans le bucket.

Stratégies de refus IAM et LCA

Les stratégies de refus IAM s'appliquent à l'accès accordé par les LCA. Par exemple, si vous créez une règle de refus qui refuse un compte principal, l'autorisation storage.objects.get sur un projet, le compte principal ne peut pas afficher les objets de ce projet, même s'ils disposent de l'autorisation READER sur des objets individuels.

Autorisation IAM permettant de modifier les LCA

Vous pouvez utiliser IAM pour accorder aux comptes principaux l'autorisation nécessaire pour modifier les LCA d'objets. Les autorisations storage.buckets suivantes permettent aux utilisateurs de travailler avec des LCA de bucket et les LCA d'objet par défaut : .get, .getIamPolicy, .setIamPolicy et .update.

De même, les autorisations storage.objects suivantes permettent aux utilisateurs de travailler avec des LCA d'objet : .get, .getIamPolicy, .setIamPolicy et .update.

Rôles personnalisés

Bien qu'IAM dispose de nombreux rôles prédéfinis qui couvrent les cas d'utilisation courants, vous pouvez définir vos propres rôles qui regroupent les autorisations que vous spécifiez. Pour ce faire, IAM propose des rôles personnalisés.

Types de comptes principaux

Il existe plusieurs types de comptes principaux. Par exemple, les comptes Google et les groupes Google représentent deux types généraux, tandis que les types allAuthenticatedUsers et allUsers sont deux types spécialisés. Pour obtenir la liste des types d'entités principales dans IAM, consultez la section Identifiants principaux. Pour en savoir plus sur les comptes principaux en général, consultez la page Concepts liés à l'identité.

Valeurs d'usage

Cloud Storage est compatible avec les valeurs d'usage, c'est-à-dire un ensemble spécial de comptes principaux pouvant être appliqués spécifiquement à vos stratégies de bucket IAM. Vous devez généralement éviter d'utiliser des valeurs d'usage dans les environnements de production, car cela nécessite d'accorder des rôles de base : une pratique déconseillée dans les environnements de production.

Une valeur d'usage est un identifiant à deux parties composé d'un rôle de base et d'un ID de projet :

  • projectOwner:PROJECT_ID
  • projectEditor:PROJECT_ID
  • projectViewer:PROJECT_ID

Une valeur d'usage agit en tant que pont entre les comptes principaux auxquels ont été attribués le rôle de base et un rôle IAM. Le rôle IAM accordé à la valeur d'usage est également appliqué à tous les comptes principaux du rôle de base spécifié pour l'ID de projet spécifié.

Par exemple, supposons que jane@example.com et john@example.com disposent du rôle de base Lecteur (roles/viewer) pour un projet nommé my-example-project, et d'un bucket dans ce projet nommé my-bucket. Si vous attribuez le rôle Créateur des objets de l'espace de stockage (roles/storage.objectCreator) pour my-bucket à la valeur d'usage projectViewer:my-example-project, jane@example.com et john@example.com obtiennent tous deux les autorisations associées au rôle Créateur des objets de l'espace de stockage pour my-bucket.

Vous pouvez accorder et révoquer l'accès à des valeurs d'usage pour vos buckets, mais sachez que Cloud Storage les applique automatiquement dans certaines circonstances. Pour plus d'informations, consultez la section Comportement modifiable pour les rôles de base dans Cloud Storage.

Conditions

Les conditions IAM vous permettent de définir des conditions qui contrôlent la façon dont les autorisations sont accordées ou refusées aux comptes principaux. Cloud Storage accepte les types d'attributs de condition suivants :

  • resource.name : accordez ou refusez l'accès aux buckets et aux objets en fonction du nom de bucket ou d'objet. Vous pouvez également utiliser resource.type pour accorder l'accès à des buckets ou à des objets, mais cela est généralement redondant avec l'utilisation de resource.name. L'exemple de condition suivant applique un paramètre IAM à tous les objets ayant le même préfixe : 

    resource.name.startsWith('projects/_/buckets/BUCKET_NAME/objects/OBJECT_PREFIX')

  • Date et heure : définissez une date d'expiration pour l'autorisation.

    request.time < timestamp('2019-01-01T00:00:00Z')

Ces expressions conditionnelles sont des instructions logiques qui utilisent un sous-ensemble de CEL (Common Expression Language). Vous spécifiez des conditions dans les liaisons de rôle de la stratégie IAM d'un bucket.

Gardez ces restrictions à l'esprit :

  • Vous devez activer l'accès uniforme au niveau du bucket dans un bucket avant d'ajouter des conditions au niveau du bucket. Bien que les conditions soient autorisées au niveau du projet, vous devez transférer tous les buckets du projet vers un accès uniforme au niveau du bucket pour empêcher les LCA Cloud Storage de remplacer les conditions IAM au niveau du projet. Vous pouvez appliquer une contrainte d'accès uniforme au niveau du bucket pour activer un accès uniforme au niveau du bucket pour tous les nouveaux buckets de votre projet.
  • Lorsque vous utilisez l'API JSON pour appeler getIamPolicy et setIamPolicy sur des buckets avec des conditions, vous devez définir la version de la stratégie IAM sur 3.
  • L'autorisation storage.objects.list étant accordée au niveau du bucket, vous ne pouvez pas utiliser l'attribut de condition resource.name pour limiter l'accès à une liste d'objets à un sous-ensemble d'objets du bucket.
  • Les conditions expirées restent dans votre stratégie IAM jusqu'à ce que vous les supprimiez.

Utiliser les autorisations IAM avec les outils Cloud Storage

Bien que les autorisations IAM ne puissent pas être définies via l'API XML, les utilisateurs disposant d'autorisations IAM peuvent tout de même utiliser l'API XML, ainsi que tout autre outil permettant d'accéder à Cloud Storage.

Pour connaître les autorisations IAM permettant aux utilisateurs d'effectuer des actions avec différents outils Cloud Storage, consultez la page Références IAM pour Cloud Storage.

Étapes suivantes