Comprendre les stratégies

Le contrôle des accès aux ressources Google Cloud est géré par des stratégies IAM. Une stratégie IAM est associée à une ressource. Elle gère l'accès à la ressource proprement dite ainsi qu'aux ressources enfants via l'héritage des stratégies.

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 est un ensemble constitué de liaisons, d'une configuration d'audit et de métadonnées. Une liaison spécifie la manière dont l'accès aux ressources doit être accordé. Elle associe (ou lie) un ou plusieurs membres à un seul rôle et à des conditions propres au contexte qui modifient la façon dont le rôle est accordé et à quel moment. Le champ AuditConfig spécifie les données de configuration concernant la façon dont les tentatives d'accès doivent être auditées. 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 partie est décrite ci-dessous :

  • Liste de liaisons. Chaque liaison inclut les champs suivants :
    • Un membre, également appelé identité ou entité principale, peut être un compte utilisateur, un compte de service, un groupe Google ou un domaine.
    • Un rôle est un ensemble nommé d'autorisations permettant d'effectuer des actions sur les ressources Google Cloud.
    • Une condition 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.
  • Un champ AuditConfig, permettant de configurer la journalisation d'audit pour la stratégie.
  • Des métadonnées, qui incluent 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.
    • Un champ version, qui spécifie la version de schéma d'une stratégie donnée. L'utilisation du champ version est expliquée plus en détail dans la section Versions de stratégies.

Une liaison de rôle dans une stratégie IAM est la combinaison du rôle et d'une liste de membres. Si une liaison de rôle contient également une condition, elle est appelée liaison de rôle conditionnelle.

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 devez mettre à jour une stratégie, veillez à inclure le champ etag au moment de l'écriture. 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 et 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 primitif "Propriétaire" est accordé à jie@example.com sans aucune condition. La liaison à un rôle primitif est souvent trop permissive. Dans le cas présent, le rôle "Propriétaire" contient plus de 1 000 autorisations. Nous vous recommandons d'accorder un rôle prédéfini ou un rôle personnalisé au lieu d'un rôle primitif, car leur champ d'application et le nombre d'autorisations qu'ils comportent sont limités.

Exemple : Stratégie comportant plusieurs liaisons

Prenons l'exemple suivant de stratégie, qui contient plusieurs liaisons. 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 seconde liaison de rôle, Jie et Divya (divya@example.com) peuvent créer des projets via le rôle "Créateur de projet" (roles/resourcemanager.projectCreator). Ensemble, ces liaisons offrent un accès ultraprécis à Jie et Divya, l'accès accordé à Divya étant le sous-ensemble de l'accès accordé à 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_2020",
          "description": "Expires on July 1, 2020",
          "expression":
            "request.time < timestamp('2020-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 dans la stratégie est une liaison de rôle conditionnelle. Elle accorde le rôle au groupe Google prod-dev@example.com et au compte de service prod-dev-example@appspot.gserviceaccount.com, mais seulement jusqu'au 1er juillet 2020.

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_2020",
        "description": "Expires on July 1, 2020",
        "expression":
          "request.time < timestamp('2020-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 n'a pas de condition. La seconde liaison comporte une condition qui n'accorde le rôle que jusqu'au 1er juillet 2020.

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 2020.

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 la stratégie à 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.

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.

Dans cet exemple, vous ne pouvez pas ajouter le nouvel utilisateur donald@example.com à une liaison de la stratégie, car la stratégie est déjà liée à un utilisateur supprimé portant le même nom. Pour savoir comment résoudre ce problème, consultez les instructions sur les stratégies qui incluent des membres supprimés.

Limites des stratégies

Les stratégies IAM sont soumises aux limites suivantes :

  • Chaque ressource Google Cloud acceptant une stratégie IAM à son niveau dans la hiérarchie des ressources ne peut comporter qu'une stratégie au maximum. Il s'agit par exemple des organisations, des dossiers, des projets ou des ressources individuelles (telles que des disques Compute Engine, des images, etc.).
  • Chaque stratégie IAM peut contenir jusqu'à 1 500 members. 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.

  • En général, les modifications apportées aux stratégies prennent effet dans un délai de 60 secondes après l'appel de setIamPolicy() ou la mise à jour d'une liaison de rôle dans Cloud Console. Toutefois, dans certains cas, la propagation complète des modifications des stratégies dans le système peut prendre jusqu'à sept minutes.

  • Certains services Google Cloud ne sont actuellement pas compatibles avec les liaisons de rôle conditionnelles pour les stratégies au niveau des ressources, même si Google Cloud, le nom ou le type de la ressource peut être utilisé dans une liaison de rôle conditionnelle. Par exemple, dans certains cas, une stratégie avec une liaison de rôle conditionnelle qui limite l'accès à la ressource d'un service peut être définie au niveau du projet, mais pas au niveau de la ressource elle-même. Pour en savoir plus, consultez la documentation de référence sur les attributs pour les conditions Cloud IAM.

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. 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_2020",
          "description": "Expires on July 1, 2020",
          "expression": "request.time < timestamp('2020-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 ; vous ne savez donc pas quand ni où la liaison 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 :

Langue 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

Si vous utilisez l'outil gcloud pour gérer les stratégies IAM, assurez-vous d'utiliser la version 263.0.0 ou ultérieure. Les versions antérieures ne sont compatibles qu'avec les stratégies de version 1.

Pour vérifier le numéro de version de l'outil gcloud, exécutez gcloud version. 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 dans une stratégie inclut un membre supprimé et que vous essayez d'ajouter une liaison pour un nouveau membre du même nom, Cloud IAM ajoute le membre supprimé à la liaison au lieu du nouveau membre.

Prenons l'exemple de cette stratégie qui inclut une liaison à un utilisateur supprimé, donald@example.com, et 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
}

Si vous créez un utilisateur également nommé donald@example.com, vous ne pouvez pas l'ajouter à une liaison de la stratégie. Par exemple, supposons que vous souhaitiez lier le nouvel utilisateur au rôle de créateur de projet (roles/resourcemanager.projectCreator), ce qui lui permet de créer des projets Google Cloud. Pour mettre à jour la stratégie, procédez comme suit :

{
  "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
}

Si vous obtenez la stratégie mise à jour, la liaison fait référence à l'utilisateur supprimé, et non au nouvel utilisateur :

{
  "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": [
        "deleted:user:donald@example.com?uid=234567890123456789012"
      ],
      "role": "roles/resourcemanager.projectCreator"
    }
  ],
  "etag": "BwWWK2TI-5A=",
  "version": 1
}

De même, si vous créez un compte de service également nommé my-service-account@project-id.iam.gserviceaccount.com, vous ne pouvez pas ajouter ce nouveau compte de service à une liaison de la stratégie. La même limitation s'applique également aux autres types de membres.

Pour résoudre ce problème, effectuez l'une des modifications suivantes :

  • Annulez la suppression du membre dans la mesure du possible. Si un membre supprimé apparaît dans une liaison et que vous pouvez annuler sa suppression, il récupère automatiquement les rôles dans la liaison. Vous n'avez pas besoin de restaurer les rôles du membre manuellement.

    Pour annuler la suppression d'un compte utilisateur G Suite, consultez l'article Restaurer un compte utilisateur récemment supprimé.

    Pour annuler la suppression d'un compte de service, consultez la section Annuler la suppression d'un compte de service.

  • Modifiez la stratégie comme suit :

    1. Révoquez tous les rôles que la stratégie lie au membre supprimé. Si le membre supprimé apparaît dans plusieurs liaisons de la stratégie, vous devez retirer le membre supprimé de chaque liaison.

      Vous n'avez pas besoin de retirer le membre supprimé des liaisons d'autres stratégies.

    2. Attribuez les rôles appropriés au nouveau membre.

Bonnes pratiques relatives aux stratégies

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