Comprendre les stratégies

Le contrôle des accès aux ressources Google Cloud est géré par les stratégies IAM, qui sont associées aux ressources. Vous ne pouvez associer qu'une seule stratégie IAM à chaque ressource. La stratégie IAM contrôle l'accès à la ressource elle-même, ainsi qu'à tous ses descendants qui héritent de la stratégie.

Cet article fournit des exemples de stratégies IAM utilisant le format JSON, bien que le format YAML soit également accepté.

Structure d'une stratégie

Une stratégie IAM est un ensemble de liaisons de rôles et de métadonnées. Une liaison de rôle spécifie l'accès à une ressource. Elle associe (ou lie) un ou plusieurs membres à un seul rôle IAM et à des conditions propres au contexte qui modifient la façon dont le rôle est accordé et à quel moment. Les métadonnées contiennent des informations supplémentaires sur la stratégie, par exemple un ETag et une version pour faciliter la gestion des stratégies.

Chaque liaison de rôle peut inclure les champs suivants :

  • Un membre, également appelé identité ou entité principale, qui peut être un compte utilisateur, un compte de service, un groupe Google ou un domaine.

    Chaque stratégie IAM peut contenir jusqu'à 1 500 membres. Au maximum, 250 de ces membres peuvent être des groupes Google.

    Cloud IAM comptabilise toutes les apparitions de chaque membre dans les liaisons de la stratégie. Les membres qui apparaissent dans plusieurs liaisons ne sont pas supprimés. Par exemple, si le membre user:alice@example.com apparaît dans 50 liaisons, vous pouvez ajouter 1 450 membres pour l'ensemble des liaisons de la stratégie.

  • Un rôle, qui consiste en un ensemble nommé d'autorisations permettant d'effectuer des actions sur les ressources Google Cloud.

  • Une condition, qui est une expression logique qui limite davantage la liaison de rôle en fonction d'attributs concernant la requête, tels que son origine, la ressource cible, etc. Les conditions sont généralement utilisées pour contrôler l'autorisation ou non de l'accès en fonction du contexte d'une requête.

    Si une liaison de rôle contient également une condition, elle est appelée liaison de rôle conditionnelle.

    Certains services Google Cloud n'acceptent pas les conditions des stratégies IAM. Pour obtenir la liste des services et types de ressources qui acceptent les conditions, consultez la section Types de ressources qui acceptent les liaisons de rôles conditionnelles.

Les métadonnées d'une stratégie IAM comprennent les champs suivants :

  • Un champ etag, utilisé pour le contrôle de simultanéité, et qui garantit la mise à jour cohérente des stratégies. Pour en savoir plus, consultez la section Utiliser des Etags dans une stratégie sur cette page.
  • Un champ version, qui spécifie la version de schéma d'une stratégie donnée. Pour en savoir plus, consultez la section Versions de stratégies sur cette page.

Pour les organisations, les dossiers, les projets et les comptes de facturation, la stratégie IAM peut également contenir un champ auditConfig qui spécifie les types d'activités qui génèrent des journaux d'audit pour chaque service. Pour apprendre à configurer cette partie d'une stratégie IAM, consultez la page Configurer les journaux pour l'accès aux données.

En général, lorsque vous mettez à jour une stratégie IAM, vos modifications prennent effet dans les 60 secondes. Toutefois, dans certains cas, la propagation complète de la modification sur Google Cloud peut prendre jusqu'à sept minutes.

Utiliser des ETags dans une stratégie

Lorsque plusieurs systèmes tentent d'écrire dans la même stratégie IAM en même temps, il est possible que ces systèmes écrasent leurs modifications respectives. Ce risque est lié au fait que la mise à jour d'une stratégie IAM implique plusieurs opérations indiquées ci-dessous :

  1. Lecture de la stratégie existante
  2. Modification de la stratégie
  3. Écriture de l'intégralité de la stratégie

Si le système A lit une stratégie et que le système B écrit immédiatement une version mise à jour de cette stratégie, le système A n'est pas informé des modifications apportées par le système B. Lorsque le système A écrit ses propres modifications de stratégie, les modifications du système B peuvent être perdues.

Pour éviter ce problème, la gestion de l'authentification et des accès (IAM) permet le contrôle de simultanéité grâce à l'utilisation d'un champ etag dans la stratégie. La valeur de ce champ change chaque fois qu'une stratégie est mise à jour.

Lorsque vous affichez une stratégie, celle-ci comprend un champ etag avec la valeur etag actuelle, telle que BwUjMhCsNvY=. Lorsque vous écrivez la mise à jour de la stratégie, assurez-vous d'inclure cette valeur dans le champ etag de la stratégie. Si la stratégie a été modifiée depuis que vous l'avez récupérée, la valeur etag ne correspondra pas et la mise à jour échouera. Pour l'API REST, vous recevez le code d'état HTTP 409 Conflict et le corps de la réponse est semblable à celui-ci :

{
  "error": {
    "code": 409,
    "message": "There were concurrent policy changes. Please retry the whole read-modify-write with exponential backoff.",
    "status": "ABORTED"
  }
}

Si vous recevez cette erreur, réessayez toute la série d'opérations : relisez la stratégie, modifiez-la si nécessaire et écrivez la stratégie mise à jour. Vous devez effectuer des tentatives automatiques avec un intervalle exponentiel entre les tentatives dans tous les outils que vous utilisez pour gérer les stratégies IAM.

Pour savoir comment mettre à jour des stratégies à l'aide du modèle lecture-modification-écriture, consultez la page Attribuer, modifier et révoquer les accès.

Exemple : Stratégie simple

Prenons l'exemple suivant de stratégie, qui lie un membre à un rôle :

{
  "bindings": [
    {
      "members": [
        "user:jie@example.com"
      ],
      "role": "roles/owner"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

Dans l'exemple ci-dessus, le rôle de base Propriétaire est accordé à jie@example.com sans aucune condition. Ce rôle accorde un accès quasi illimité à jie@example.com.

Exemple : Stratégie comportant plusieurs liaisons de rôles

Prenons l'exemple suivant d'une stratégie qui contient plusieurs liaisons de rôles. Chaque liaison a un rôle différent :

{
  "bindings": [
    {
      "members": [
        "user:jie@example.com"
      ],
      "role": "roles/resourcemanager.organizationAdmin"
    },
    {
      "members": [
        "user:divya@example.com",
        "user:jie@example.com"
      ],
      "role": "roles/resourcemanager.projectCreator"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

Dans l'exemple ci-dessus, Jie (jie@example.com) se voit attribuer le rôle prédéfini Administrateur de l'organisation (roles/resourcemanager.organizationAdmin) dans la première liaison de rôle. Ce rôle contient des autorisations pour les organisations, les dossiers et des opérations limitées de projets. Dans la deuxième liaison de rôle, Jie et Divya (divya@example.com) sont autorisés à créer des projets via le rôle Créateur de projet (roles/resourcemanager.projectCreator). Ensemble, ces liaisons de rôle accordent un accès précis à Jie et Divya, avec une autorisation d'accès plus importante pour Jie.

Exemple : Stratégie avec liaison de rôle conditionnelle

Prenons l'exemple suivant de stratégie IAM, qui lie les membres à un rôle prédéfini et utilise une expression de condition pour limiter la liaison de rôle :

{
  "bindings": [
    {
      "members": [
        "group:prod-dev@example.com",
        "serviceAccount:prod-dev-example@appspot.gserviceaccount.com"
      ],
      "role": "roles/appengine.deployer",
      "condition": {
          "title": "Expires_July_1_2022",
          "description": "Expires on July 1, 2022",
          "expression":
            "request.time < timestamp('2022-07-01T00:00:00.000Z')"
      }
    }
  ],
  "etag": "BwWKmjvelug=",
  "version": 3
}

Dans cet exemple, le champ version est défini sur 3, car la stratégie contient une expression de condition. La liaison de rôle dans la stratégie est conditionnelle. Elle attribue le rôle au groupe Google prod-dev@example.com et au compte de service prod-dev-example@appspot.gserviceaccount.com, mais uniquement jusqu'au 1er juillet 2022.

Pour en savoir plus sur les fonctionnalités compatibles avec chaque version de stratégie, consultez la section Versions de stratégies sur cette page.

Exemple : Stratégie avec des liaisons de rôle conditionnelles et inconditionnelles

Prenons l'exemple suivant de stratégie IAM, qui contient des liaisons de rôle conditionnelles et inconditionnelles pour le même rôle :

{
  "bindings": [
    {
      "members": [
        "serviceAccount:prod-dev-example@appspot.gserviceaccount.com"
       ],
       "role": "roles/appengine.deployer"
    },
    {
      "members": [
        "group:prod-dev@example.com",
        "serviceAccount:prod-dev-example@appspot.gserviceaccount.com"
      ],
      "role": "roles/appengine.deployer",
      "condition": {
        "title": "Expires_July_1_2022",
        "description": "Expires on July 1, 2022",
        "expression":
          "request.time < timestamp('2022-07-01T00:00:00.000Z')"
      }
    }
  ],
  "etag": "BwWKmjvelug=",
  "version": 3
}

Dans cet exemple, le compte de service serviceAccount:prod-dev-example@appspot.gserviceaccount.com est inclus dans deux liaisons de rôle pour le même rôle. La première liaison de rôle n'a pas de condition. La deuxième liaison de rôle contient une condition qui n'accorde le rôle que jusqu'au 1er juillet 2022.

En réalité, cette stratégie attribue toujours le rôle au compte de service. Dans Cloud IAM, les liaisons de rôle conditionnelles ne remplacent pas les liaisons de rôle sans condition. Si un membre est associé à un rôle et que la liaison de rôle n'a pas de condition, il dispose toujours de ce rôle. L'ajout du membre à une liaison conditionnelle pour le même rôle n'a aucun effet.

En revanche, le groupe Google group:prod-dev@example.com n'est inclus que dans la liaison de rôle conditionnelle. Par conséquent, il ne dispose du rôle que jusqu'au 1er juillet 2022.

Exemple : Stratégie qui associe un rôle à un membre supprimé

Prenons l'exemple de stratégie suivant. Cette stratégie associe un rôle à un utilisateur, donald@example.com, dont le compte a été supprimé :

{
  "bindings": [
    {
      "members": [
        "deleted:user:donald@example.com?uid=123456789012345678901"
      ],
      "role": "roles/owner"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

Si vous créez un utilisateur nommé donald@example.com, les liaisons de rôles de la stratégie pour l'utilisateur supprimé ne s'appliquent pas au nouvel utilisateur. Ce comportement empêche les nouveaux utilisateurs d'hériter des rôles accordés aux utilisateurs supprimés. Si vous souhaitez attribuer des rôles au nouvel utilisateur, ajoutez-le aux liaisons de rôles de la stratégie, comme indiqué dans la section Stratégies avec des membres supprimés sur cette page.

De plus, le nom de l'utilisateur inclut désormais le préfixe deleted: et le suffixe ?uid=numeric-id, où numeric-id est l'ID numérique unique de l'utilisateur supprimé. Dans cet exemple, la stratégie affiche l'identifiant deleted:user:donald@example.com?uid=123456789012345678901 au lieu de user:donald@example.com.

Les comptes et les groupes de service ont le même comportement que les utilisateurs. Si vous supprimez un compte ou un groupe de service, puis affichez une stratégie qui inclut ce membre, le nom du membre supprimé porte le préfixe deleted: et le suffixe ?uid=numeric-id.

Stratégies par défaut

Toutes les ressources qui acceptent les stratégies IAM sont créées avec des stratégies IAM par défaut. Les stratégies par défaut de la plupart des ressources sont vides. Toutefois, les stratégies par défaut de certaines ressources contiennent automatiquement certaines liaisons de rôles. Par exemple, lorsque vous créez un projet, la stratégie IAM associée au projet dispose automatiquement d'une liaison de rôle qui vous accorde le rôle de propriétaire (roles/owner) sur le projet.

Ces liaisons de rôles sont créées par le système. Par conséquent, l'utilisateur n'a pas besoin des autorisations getIamPolicy ou setIamPolicy sur la ressource pour les créer.

Pour savoir si une ressource est créée avec une stratégie IAM, reportez-vous à la documentation de cette ressource.

Héritage des stratégies et hiérarchie des ressources

Les ressources Google Cloud sont organisées de manière hiérarchique. Le nœud de l'organisation constitue le nœud racine de la hiérarchie, sous lequel figurent éventuellement des dossiers, puis des projets. La plupart des autres ressources sont créées et gérées dans le cadre d'un projet. Chaque ressource possède exactement un parent, à l'exception du nœud racine de la hiérarchie. Pour en savoir plus, consultez l'article Hiérarchie des ressources.

La hiérarchie des ressources est importante à prendre en compte lors de la définition d'une stratégie IAM. Lorsque vous définissez une stratégie à un niveau supérieur de la hiérarchie, par exemple au niveau de l'organisation, d'un dossier ou d'un projet, le niveau d'accès accordé inclut le niveau de ressource auquel cette stratégie est associée et toutes les ressources sous ce niveau. Par exemple, une stratégie définie au niveau de l'organisation s'applique à l'organisation et à toutes les ressources sous celle-ci. De même, une stratégie définie au niveau d'un projet s'applique au projet et à toutes ses ressources.

L'héritage des stratégies est un terme qui décrit la façon dont les stratégies s'appliquent aux ressources situées sous leur niveau dans la hiérarchie des ressources. La stratégie en vigueur décrit la manière dont toutes les stratégies parentes de la hiérarchie des ressources sont héritées pour une ressource. Il s'agit de l'union des éléments suivants :

  • La stratégie définie sur la ressource
  • Les stratégies définies sur tous les niveaux de ressources ancêtres de la ressource dans la hiérarchie

Chaque nouvelle liaison de rôle (héritée des ressources parentes) qui affecte la stratégie en vigueur de la ressource est évaluée indépendamment. Une demande spécifique d'accès à la ressource est accordée si l'une des liaisons de rôles de niveau supérieur octroie l'accès à la requête.

Si une nouvelle liaison de rôle est introduite dans n'importe quel niveau de la stratégie héritée de la ressource, le niveau d'accès accordé augmente.

Exemple : Héritage des stratégies

Pour comprendre l'héritage des stratégies, prenons l'exemple suivant de stratégie, qui est défini au niveau de l'organisation :

Stratégie au niveau de l'organisation

{
  "bindings": [
    {
      "members": [
        "user:divya@example.com"
      ],
      "role": "roles/storage.objectViewer"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

Le rôle "Lecteur des objets de l'espace de stockage" (roles/storage.objectViewer) contient les autorisations get et list pour les projets et les objets Cloud Storage. Lorsque cette liaison de rôle est définie au niveau de l'organisation, elle est appliquée aux niveaux sous celle-ci, y compris à tous les projets et à tous les objets Cloud Storage qu'ils contiennent.

Pour illustrer plus avant l'héritage des stratégies, réfléchissez à ce qu'il se passe lorsqu'une stratégie est également définie sur myproject-123 :

Stratégie au niveau d'un projet

{
  "bindings": [
    {
      "members": [
        "user:divya@example.com"
      ],
      "role": "roles/storage.objectCreator"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

Dans l'exemple ci-dessus, le rôle "Créateur des objets de l'espace de stockage" (roles/storage.objectCreator) permet à Divya de créer des objets Cloud Storage, sous myproject-123. Maintenant que deux liaisons de rôle accordent à Divya l'accès aux objets Cloud Storage cibles sous myproject-123, les stratégies suivantes s'appliquent :

  • Une stratégie au niveau de l'organisation permet de répertorier et d'obtenir tous les objets Cloud Storage de cette organisation.
  • Une stratégie au niveau du projet, pour le projet myproject-123, permet de créer des objets dans celui-ci.

Le tableau ci-dessous récapitule la stratégie en vigueur de Divya :

Autorisations accordées via le rôle "storage.objectViewer" au niveau de l'organisation Autorisations accordées via le rôle "storage.objectCreator" au niveau de "myproject-123" Niveau d'accès octroyé à Divya sous "myproject-123"
resourcemanager.projects.get
resourcemanager.projects.list
storage.objects.get
storage.objects.list
resourcemanager.projects.get
resourcemanager.projects.list
storage.objects.create
resourcemanager.projects.get
resourcemanager.projects.list
storage.objects.get
storage.objects.list
storage.objects.create

Versions de stratégies

Au fil du temps, Cloud IAM peut ajouter de nouvelles fonctionnalités qui ajoutent ou modifient de manière significative des champs dans le schéma de stratégie. Pour éviter de modifier de façon destructive vos intégrations existantes qui reposent sur la cohérence de la structure de la stratégie, de telles modifications sont introduites dans de nouvelles versions du schéma de stratégie.

Si vous procédez à l'intégration à Cloud IAM pour la première fois, nous vous recommandons d'utiliser la version du schéma de stratégie la plus récente disponible à ce moment-là. Ci-dessous figure une présentation des différentes versions disponibles et de leur utilisation. Nous vous expliquons également comment spécifier la version de votre choix et vous présentons quelques scénarios de dépannage.

Chaque stratégie IAM existante spécifie un champ version dans les métadonnées de la stratégie. Considérez la partie en surbrillance ci-dessous :

{
  "bindings": [
    {
      "members": [
        "user:jie@example.com"
      ],
      "role": "roles/owner"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

Ce champ spécifie la version du schéma de syntaxe de la stratégie. Chaque version de la stratégie contient un schéma de syntaxe spécifique qui peut être utilisé par les liaisons de rôles. La version la plus récente peut contenir des liaisons de rôles avec le schéma de syntaxe le plus récent qui n'est pas accepté par les versions antérieures. Ce champ n'est pas destiné à être utilisé à des fins autres que le contrôle du schéma de syntaxe de la stratégie.

Versions de stratégies valides

Les stratégies IAM peuvent utiliser les versions de stratégies suivantes :

Version Description
1 Première version du schéma de syntaxe IAM pour les stratégies. Accepte la liaison d'un rôle à un ou plusieurs membres. Non compatible avec les liaisons de rôles conditionnelles.
2 Réservé à une utilisation interne.
3 Introduit dans la liaison de rôle le champ condition qui limite celle-ci via des règles basées sur le contexte et des attributs. Pour en savoir plus, consultez la présentation des conditions Cloud IAM.

Spécifier une version lors de l'obtention d'une stratégie

Pour l'API REST et les bibliothèques clientes, lorsque vous obtenez une stratégie IAM, nous vous recommandons de spécifier une version de stratégie dans la requête. Lorsqu'une requête spécifie une version de stratégie, Cloud IAM part du principe que l'appelant connaît les fonctionnalités de cette version de stratégie et peut les gérer correctement.

Si la requête ne spécifie pas de version de stratégie, Cloud IAM suppose que l'appelant souhaite une stratégie de version 1.

Lorsque vous obtenez une stratégie, Cloud IAM vérifie la version de stratégie dans la requête ou la version par défaut si la requête ne spécifie pas de version. Cloud IAM vérifie également les champs de la stratégie qui ne sont pas compatibles avec une stratégie de version 1. Ces informations sont utilisées pour déterminer le type de réponse à envoyer :

  • Si la stratégie ne contient aucune condition, Cloud IAM renvoie toujours une stratégie de version 1, quel que soit le numéro de version dans la requête.
  • Si la stratégie contient des conditions et que l'appelant a demandé une stratégie de version 3, Cloud IAM renvoie une stratégie de version 3 qui inclut les conditions. Pour obtenir un exemple, consultez le scénario 1 sur cette page.
  • Si la stratégie contient des conditions et que l'appelant a demandé une stratégie de version 1 ou n'a pas spécifié de version, Cloud IAM renvoie une stratégie de version 1.

    Pour les liaisons de rôle qui incluent une condition, Cloud IAM ajoute la chaîne _withcond_ au nom du rôle, suivie d'une valeur de hachage, par exemple, roles/iam.serviceAccountAdmin_withcond_2b17cc25d2cd9e2c54d8. La condition elle-même n'est pas présente. Pour obtenir un exemple, consultez le scénario 1 sur cette page.

Ce comportement permet d'éviter les problèmes liés aux bibliothèques clientes plus anciennes qui ne savent pas traiter les liaisons de rôles conditionnelles. Pour en savoir plus, consultez la section Compatibilité des versions de stratégies avec les bibliothèques clientes sur cette page.

Scénario 1 : Version de stratégie entièrement compatible avec les conditions IAM

Supposons que vous appelez la méthode API REST suivante pour obtenir la stratégie IAM associée à un projet :

POST https://cloudresourcemanager.googleapis.com/v1/projects/project-id:getIamPolicy

Le corps de la requête contient le texte suivant :

{
  "options": {
    "requestedPolicyVersion": 3
  }
}

La réponse contient la stratégie IAM du projet. Si la stratégie contient au moins une liaison de rôle conditionnelle, son champ version est défini sur 3 :

{
  "bindings": [
    {
      "members": [
        "user:user@example.com"
      ],
      "role": "roles/iam.securityReviewer",
      "condition": {
          "title": "Expires_July_1_2022",
          "description": "Expires on July 1, 2022",
          "expression": "request.time < timestamp('2022-07-01T00:00:00.000Z')"
      }
    }
  ],
  "etag": "BwWKmjvelug=",
  "version": 3
}

Si la stratégie ne contient pas de liaisons de rôle conditionnelles, son champ version est défini sur 1, même si la requête spécifie la version 3 :

{
  "bindings": [
    {
      "members": [
        "user:user@example.com"
      ],
      "role": "roles/iam.securityReviewer",
    }
  ],
  "etag": "BwWKmjvelug=",
  "version": 1
}

Scénario 2 : Version de stratégie avec compatibilité limitée avec les conditions IAM

Supposons que vous appelez la méthode API REST suivante pour obtenir la stratégie IAM associée à un projet :

POST https://cloudresourcemanager.googleapis.com/v1/projects/project-id:getIamPolicy

Le corps de la requête est vide. Il ne spécifie pas de numéro de version. Par conséquent, Cloud IAM utilise la version de stratégie par défaut, 1.

La stratégie contient une liaison de rôle conditionnelle. La version de la stratégie étant 1, la condition n'apparaît pas dans la réponse. Pour indiquer que la liaison de rôle utilise une condition, Cloud IAM ajoute la chaîne _withcond_ au nom du rôle, suivi d'une valeur de hachage :

{
  "bindings": [
    {
      "members": [
        "user:user@example.com"
      ],
      "role": "roles/iam.securityReviewer_withcond_58e135cabb940ad9346c"
    }
  ],
  "etag": "BwWKmjvelug=",
  "version": 1
}

Spécifier une version lors de la définition d'une stratégie

Lorsque vous définissez une stratégie IAM, nous vous recommandons de spécifier une version de stratégie dans la requête. Lorsqu'une requête spécifie une version de stratégie, Cloud IAM suppose que l'appelant connaît les fonctionnalités de cette version et peut les gérer correctement.

Si la requête ne spécifie pas de version de stratégie, Cloud IAM n'autorise que les champs qui peuvent apparaître dans une stratégie de version 1. Il est recommandé de ne pas modifier les liaisons de rôle conditionnelles dans une stratégie de version 1. En effet, la stratégie n'indique pas la condition de chaque liaison de rôle ; vous ne savez donc pas quand ni où la liaison de rôle est effectivement accordée. Obtenez plutôt la représentation de la version 3 de la stratégie, qui indique la condition de chaque liaison, et utilisez cette représentation pour mettre à jour les liaisons.

Scénario : Versions de stratégies dans les requêtes et les réponses

Supposons que vous utilisiez l'API REST pour obtenir une stratégie IAM et que vous spécifiiez la version 3 dans la requête. La réponse contient la stratégie suivante qui utilise la version 3 :

{
  "bindings": [
    {
      "members": [
        "user:divya@example.com"
      ],
      "role": "roles/storage.admin",
      "condition": {
          "title": "Weekday_access",
          "description": "Monday thru Friday access only in America/Chicago",
          "expression": "request.time.getDayOfWeek('America/Chicago') >= 1 && request.time.getDayOfWeek('America/Chicago') <= 5"
      }
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 3
}

Vous décidez que divya@example.com doit avoir le rôle "Administrateur de l'espace de stockage" (roles/storage.admin) tout au long de la semaine, et pas seulement pendant les jours ouvrés. Vous supprimez la condition de la liaison de rôle et envoyez une requête API REST pour définir la stratégie ; une fois de plus, vous spécifiez la version 3 dans la requête :

{
  "bindings": [
    {
      "members": [
        "user:divya@example.com"
      ],
      "role": "roles/storage.admin"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 3
}

La réponse contient la stratégie mise à jour :

{
  "bindings": [
    {
      "members": [
        "user:divya@example.com"
      ],
      "role": "roles/storage.admin"
    }
  ],
  "etag": "BwWd8I+ZUAQ=",
  "version": 1
}

La stratégie de la réponse utilise la version 1, même si la requête spécifie la version 3, car elle n'utilise que des champs compatibles avec une stratégie de version 1.

Compatibilité des versions de stratégies avec les bibliothèques clientes

Certaines bibliothèques clientes de Google Cloud ne sont compatibles qu'avec les stratégies de version 1. Si votre bibliothèque cliente n'est pas compatible avec les versions ultérieures des stratégies, vous ne pouvez pas utiliser les fonctionnalités qui ne sont disponibles que dans les versions ultérieures. Par exemple, les conditions IAM nécessitent la compatibilité avec la version de stratégie 3.

Si vous utilisez des fonctionnalités IAM qui ne sont pas disponibles dans les stratégies de version 1, telles que les conditions IAM, utilisez une bibliothèque cliente compatible avec cette version de stratégie et définissez-la correctement dans la requête.

Les bibliothèques clientes des API Google pour Cloud IAM ci-dessous sont compatibles avec la version de stratégie 3 :

Langage Versions compatibles avec la version de stratégie 3
C# Google.Apis >=v1.41.1
Go google-api-go-client >=v0.10.0
Java
Node.js googleapis >=v43.0.0
PHP google/apiclient >=v2.4.0
Python google-api-python-client >=v1.7.11
Ruby google-api-client >=v0.31.0

Vous pouvez utiliser ces bibliothèques clientes pour gérer les stratégies IAM de la version 3 sur les ressources des services suivants :

  • IAM
  • Cloud KMS
  • Cloud Storage
  • Compute Engine
  • Resource Manager

Les autres bibliothèques clientes, y compris les bibliothèques clientes Google Cloud, ne sont compatibles qu'avec les stratégies de version 1.

Compatibilité des versions de stratégies avec gcloud

Vous pouvez gérer les stratégies IAM de la version 3 à l'aide de l'outil gcloud. Pour effectuer la mise à jour vers la dernière version, exécutez gcloud components update.

Stratégies avec des membres supprimés

Si une liaison d'une stratégie inclut un membre supprimé et que vous ajoutez une liaison pour un nouveau membre portant le même nom, la liaison est toujours appliquée au nouveau membre.

Prenons l'exemple de cette stratégie qui inclut une liaison à un utilisateur supprimé, donald@example.com, ainsi qu'un compte de service supprimé, my-service-account@project-id.iam.gserviceaccount.com :

{
  "bindings": [
    {
      "members": [
        "deleted:serviceAccount:my-service-account@project-id.iam.gserviceaccount.com?uid=123456789012345678901",
        "deleted:user:donald@example.com?uid=234567890123456789012"
      ],
      "role": "roles/owner"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

Supposons que vous avez créé un utilisateur également nommé donald@example.com et que vous souhaitez le lier au rôle "Créateur de projets" (roles/resourcemanager.projectCreator), qui permet de créer des projets Google Cloud. Pour lier le nouvel utilisateur, mettez à jour la stratégie comme indiqué dans cet exemple :

{
  "bindings": [
    {
      "members": [
        "deleted:serviceAccount:my-service-account@project-id.iam.gserviceaccount.com?uid=123456789012345678901",
        "deleted:user:donald@example.com?uid=234567890123456789012"
      ],
      "role": "roles/owner"
    },
    {
      "members": [
        "user:donald@example.com"
      ],
      "role": "roles/resourcemanager.projectCreator"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

Pour faciliter l'audit de vos stratégies IAM, vous pouvez également retirer du rôle Propriétaire l'utilisateur supprimé de la liaison de rôle :

{
  "bindings": [
    {
      "members": [
        "deleted:serviceAccount:my-service-account@project-id.iam.gserviceaccount.com?uid=123456789012345678901"
      ],
      "role": "roles/owner"
    },
    {
      "members": [
        "user:donald@example.com"
      ],
      "role": "roles/resourcemanager.projectCreator"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

Bonnes pratiques relatives aux règles

Les bonnes pratiques suivantes s'appliquent aux organisations comptant de nombreux utilisateurs Google Cloud :

  • Lorsque vous gérez plusieurs comptes utilisateur ayant les mêmes configurations d'accès, utilisez plutôt des groupes Google. Placez chaque compte utilisateur individuel dans le groupe, puis attribuez les rôles souhaités au groupe plutôt qu'aux comptes utilisateur.

  • Autorisations accordées au niveau de l'organisation : réfléchissez bien à quels membres accorder des autorisations d'accès au niveau de l'organisation. Pour la plupart des organisations, seules quelques équipes spécifiques (telles que les équipes réseau et de sécurité) doivent disposer d'un accès à ce niveau de la hiérarchie des ressources.

  • Autorisations accordées au niveau des dossiers : envisagez de refléter la structure opérationnelle de votre organisation en utilisant des niveaux de dossiers, où chaque dossier parent/enfant peut être configuré avec différents ensembles d'autorisations d'accès conformes aux besoins opérationnels et métier. Par exemple, un dossier parent peut refléter un service, l'un de ses dossiers enfants peut refléter l'accès aux ressources dont dispose un groupe et l'opération que celui-ci peut effectuer, et un autre dossier enfant peut refléter une petite équipe. Ces deux dossiers peuvent contenir des projets correspondant aux besoins opérationnels de leur équipe. L'utilisation de dossiers de cette manière permet de garantir une séparation appropriée des accès, tout en respectant les stratégies héritées des dossiers parents et de l'organisation. Cette pratique nécessite moins de maintenance des stratégies lors de la création et de la gestion des ressources Google Cloud.

  • Autorisations accordées au niveau d'un projet : accordez des liaisons de rôles au niveau d'un projet uniquement si cela est nécessaire pour des groupes spécifiques ou des autorisations individuelles précises. Pour faciliter la gestion, en particulier si vous avez de nombreux projets, nous vous recommandons vivement de définir des stratégies au niveau d'un dossier, lorsque cela est possible.

Étapes suivantes