Comprendre les stratégies d'autorisation

Vous pouvez accorder l'accès aux ressources Google Cloud à l'aide de stratégies d'autorisation, également appelées stratégies IAM (Identity and Access Management), qui sont associées aux ressources. Vous ne pouvez associer qu'une seule stratégie d'autorisation à chaque ressource. La stratégie d'autorisation contrôle l'accès à la ressource elle-même, ainsi qu'à tous ses descendants qui héritent de la stratégie d'autorisation.

Cette page présente les stratégies d'autorisation au format JSON. Vous pouvez également utiliser la CLI Google Cloud pour récupérer des stratégies d'autorisation au format YAML.

Structure d'une stratégie

Une stratégie d'autorisation 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 comptes principaux à 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 d'autorisation, par exemple un ETag et une version permettant de faciliter la gestion des stratégies.

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

  • Un ou plusieurs comptes principaux, également appelés membres ou identités. Il existe plusieurs types de comptes principaux, y compris les comptes utilisateur, les comptes de service, les groupes Google et les domaines. Pour obtenir la liste complète des types de comptes principaux acceptés, consultez la section Identifiants principaux.
  • 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 ou la ressource cible. 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 dans les stratégies d'autorisation. 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 modifications apportées à l'accès d'un compte principal sont cohérentes à terme. La propagation des modifications d'accès dans le système prend donc un certain temps. Pour connaître le temps moyen nécessaire pour que les modifications d'accès se propagent, consultez la section Propagation des modifications d'accès.

Limites sur les comptes principaux

Chaque stratégie d'autorisation peut contenir jusqu'à 1500 comptes principaux. Pour respecter cette limite, Cloud IAM comptabilise toutes les apparitions de chaque compte principal dans les liaisons de rôle de la stratégie d'autorisation, ainsi que les comptes principaux que la stratégie d'autorisation exclut de l'accès aux journaux d'audit des accès aux données. Les comptes principaux qui apparaissent dans plusieurs liaisons ne sont pas supprimés. Par exemple, si une stratégie d'autorisation ne contient que des liaisons de rôles pour le compte principal group:my-group@example.com et que ce compte principal apparaît dans 50 liaisons de rôles, vous pouvez ajouter 1 450 comptes principaux aux liaisons de rôles dans la stratégie d'autorisation.

Le nombre de comptes principaux associés à des domaines et des groupes Google dans une stratégie d'autorisation est limité à 250. Dans le cadre de cette limite, les domaines et les groupes Google sont comptabilisés comme suit :

  • Pour les domaines, IAM comptabilise toutes les apparitions de chaque domaine dans les liaisons de rôle de la stratégie d'autorisation. Les comptes principaux qui apparaissent dans plusieurs liaisons de rôles ne sont pas supprimés. Par exemple, si une règle d'autorisation ne contient qu'un seul domaine, domain:example.com, et que le domaine apparaît 10 fois dans la règle d'autorisation, vous pouvez ajouter 240 domaines supplémentaires avant d'atteindre la limite.
  • Pour les groupes Google, chaque groupe unique n'est comptabilisé qu'une seule fois, quel que soit le nombre de fois où il apparaît dans la stratégie d'autorisation. Par exemple, si une stratégie d'autorisation ne contient qu'un seul groupe, group:my-group@example.com, et que le groupe apparaît dans la règle d'autorisation 10 fois, vous pouvez ajouter 249 groupes uniques avant d'atteindre la limite.

Si vous utilisez des conditions IAM ou si vous attribuez des rôles à de nombreux comptes principaux avec des identifiants particulièrement longs, il se peut qu'IAM autorise moins de comptes principaux dans la stratégie d'autorisation.

Métadonnées de stratégie

Les métadonnées d'une stratégie d'autorisation 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 d'autorisation. 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 d'autorisation 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 d'autorisation 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 d'autorisation, consultez la page Configurer les journaux pour l'accès aux données.

Utiliser des ETags dans une stratégie

Lorsque plusieurs systèmes tentent d'écrire dans la même stratégie d'autorisation en même temps, il est possible que ces systèmes écrasent leurs modifications respectives. Ce risque est lié au fait que les stratégies d'autorisation sont mises à jour à l'aide du modèle lecture-modification-écriture, qui implique plusieurs opérations :

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

Si le système A lit une stratégie d'autorisation et que le système B écrit immédiatement une version mise à jour de cette stratégie d'autorisation, 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 d'autorisation, 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 d'autorisation. Chaque stratégie d'autorisation contient un champ etag, et la valeur de ce champ change chaque fois qu'une stratégie d'autorisation est mise à jour. Si une stratégie d'autorisation contient un champ etag, mais aucune liaison de rôle, la stratégie d'autorisation n'accorde aucun rôle IAM.

Le champ etag contient une valeur telle que BwUjMhCsNvY=. Lorsque vous mettez à jour la stratégie d'autorisation, veillez à inclure le champ etag dans la stratégie d'autorisation mise à jour. Si la stratégie d'autorisation 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 d'autorisation, modifiez-la si nécessaire et écrivez la stratégie d'autorisation 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 d'autorisation.

Exemple : Stratégie simple

Prenons l'exemple suivant de stratégie d'autorisation, qui lie un compte principal à 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 d'autorisation 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:raha@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 Raha (raha@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 Raha, 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 d'autorisation, qui lie les comptes principaux à 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 d'autorisation contient une expression de condition. La liaison de rôle dans la stratégie d'autorisation 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 d'autorisation, 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 d'autorisation, 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 d'autorisation 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 compte principal est lié à un rôle et que la liaison de rôle n'a pas de condition, le compte principal dispose toujours de ce rôle. L'ajout du compte principal à 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 compte principal supprimé

Examinez la stratégie d'autorisation ci-dessous. Cette stratégie d'autorisation associe un rôle à un utilisateur, donald@example.com, dont le compte a été supprimé. Par conséquent, l'identifiant de l'utilisateur possède désormais un préfixe deleted: :

{
  "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 d'autorisation 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 nouvel utilisateur aux liaisons de la stratégie d'autorisation, comme indiqué dans la section Stratégies avec des comptes principaux 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 d'autorisation 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 d'autorisation qui inclut ce compte principal, le nom du compte principal 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 d'autorisation sont créées avec des stratégies d'autorisation par défaut. Les stratégies d'autorisation par défaut de la plupart des ressources sont vides. Toutefois, les stratégies d'autorisation par défaut de certaines ressources contiennent automatiquement certaines liaisons de rôles. Par exemple, lorsque vous créez un projet, la stratégie d'autorisation 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 d'autorisation, 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 de l'organisation. L'organisation, en tant que nœud racine de la hiérarchie, n'a pas de parent. 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 d'autorisation. Lorsque vous définissez une stratégie d'autorisation à 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 d'autorisation est associée et toutes les ressources sous ce niveau. Par exemple, une stratégie d'autorisation 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'autorisation 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 d'autorisation 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 d'autorisation 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'autorisation définie sur la ressource
  • Les stratégies d'autorisation 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 d'autorisation 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 d'autorisation 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 d'autorisation, prenons l'exemple d'un scénario dans lequel vous accordez à un utilisateur, Raha, deux rôles IAM différents à deux niveaux différents de la hiérarchie des ressources.

Pour attribuer un rôle à Raha au niveau de l'organisation, définissez la stratégie d'autorisation suivante sur votre organisation :

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

Cette stratégie d'autorisation accorde à Raha le rôle "Lecteur des objets Storage" (roles/storage.objectViewer), qui contient les autorisations get et list pour les projets et les objets Cloud Storage. Comme vous définissez la stratégie d'autorisation au niveau de votre organisation, Raha peut utiliser ces autorisations pour tous les projets et tous les objets Cloud Storage de votre organisation.

Pour accorder à Raha un rôle au niveau du projet, définissez la stratégie d'autorisation suivante sur le projet myproject-123 :

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

Cette stratégie d'autorisation accorde à Raha le rôle "Créateur d'objets Storage" (roles/storage.objectCreator), qui lui permet de créer des objets Cloud Storage. Comme vous définissez la stratégie d'autorisation sur myproject-123, Raha ne peut créer des objets Cloud Storage que dans myproject-123.

Maintenant que deux liaisons de rôle accordent à Raha l'accès aux objets Cloud Storage cibles sous myproject-123, les stratégies d'autorisation suivantes s'appliquent :

  • Une stratégie d'autorisation au niveau de l'organisation permet de répertorier et d'obtenir tous les objets Cloud Storage de cette organisation.
  • Une stratégie d'autorisation 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 Raha :

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é à Raha 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, IAM peut ajouter de nouvelles fonctionnalités qui ajoutent ou modifient de manière significative des champs dans le schéma de stratégie d'autorisation. 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 d'autorisation, de telles modifications sont introduites dans de nouvelles versions du schéma de stratégie d'autorisation.

Si vous procédez à l'intégration IAM pour la première fois, nous vous recommandons d'utiliser la version du schéma de stratégie d'autorisation 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 d'autorisation existante spécifie un champ version dans les métadonnées de la stratégie d'autorisation. 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 d'autorisation. Chaque version de la stratégie d'autorisation 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 pour la stratégie d'autorisation.

Versions de stratégies valides

Les stratégies d'autorisation peuvent utiliser les versions de stratégies d'autorisation 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 comptes principaux. 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 d'autorisation, nous vous recommandons de spécifier une version de stratégie d'autorisation dans la requête. Lorsqu'une requête spécifie une version de stratégie d'autorisation, 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 d'autorisation, Cloud IAM suppose que l'appelant souhaite une stratégie d'autorisation de version 1.

Lorsque vous obtenez une stratégie d'autorisation, Cloud IAM vérifie la version de la stratégie d'autorisation dans la requête, ou la version par défaut si la requête ne spécifie pas de version. IAM vérifie également les stratégies d'autorisation pour les champs non compatibles avec une stratégie d'autorisation 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, IAM renvoie toujours une stratégie d'autorisation de version 1, quel que soit le numéro de version dans la requête.
  • Si la stratégie d'autorisation contient des conditions et que l'appelant a demandé une stratégie d'autorisation de version 3, IAM renvoie une stratégie d'autorisation de version 3 qui inclut les conditions. Pour obtenir un exemple, consultez le scénario 1 sur cette page.

  • Si la stratégie d'autorisation contient des conditions et que l'appelant a demandé une stratégie d'autorisation de version 1 ou n'a pas spécifié de version, IAM renvoie une stratégie d'autorisation 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 2 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 d'autorisation 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 d'autorisation du projet. Si la stratégie d'autorisation 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 d'autorisation 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 d'autorisation 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 d'autorisation par défaut, 1.

La stratégie d'autorisation contient une liaison de rôle conditionnelle. La version de la stratégie d'autorisation é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 d'autorisation, nous vous recommandons de spécifier une version de stratégie d'autorisation dans la requête. Lorsqu'une requête spécifie une version de stratégie d'autorisation, IAM suppose que l'appelant connaît les fonctionnalités de cette version de stratégie d'autorisation et peut les gérer correctement.

Si la requête ne spécifie pas de version de stratégie d'autorisation, IAM n'accepte que les champs qui peuvent apparaître dans une stratégie d'autorisation de version 1. Il est recommandé de ne pas modifier les liaisons de rôle conditionnelles dans une stratégie d'autorisation de version 1. En effet, la stratégie d'autorisation 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 d'autorisation, 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 d'autorisation et que vous spécifiiez la version 3 dans la requête. La réponse contient la stratégie d'autorisation suivante qui utilise la version 3 :

{
  "bindings": [
    {
      "members": [
        "user:raha@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 raha@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 d'autorisation ; une fois de plus, vous spécifiez la version 3 dans la requête :

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

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

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

La stratégie d'autorisation figurant dans 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 d'autorisation de version 1.

Stratégies avec des comptes principaux supprimés

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

Prenons l'exemple de cette stratégie d'autorisation qui inclut une liaison de rôle à un utilisateur supprimé, donald@example.com, ainsi qu'un compte de service supprimé, my-service-account@project-id.iam.gserviceaccount.com. Par conséquent, l'identifiant de chaque compte principal possède le préfixe deleted: :

{
  "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 lui accorder le rôle de créateur de projet (roles/resourcemanager.projectCreator), qui permet aux comptes principaux de créer des projets Google Cloud. Pour attribuer le rôle au nouvel utilisateur, mettez à jour la stratégie d'autorisation 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 d'autorisation, vous pouvez également retirer l'utilisateur supprimé de la liaison au rôle "Propriétaire" :

{
  "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 comptes principaux 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 d'autorisation héritées des dossiers parents et de l'organisation. Cette pratique nécessite moins de maintenance pour les stratégies d'autorisation lors de la création et de la gestion de ressources Google Cloud.

  • Autorisations accordées au niveau du projet : accordez des liaisons de rôles au niveau du projet lorsque cela s'avère nécessaire pour suivre le principe du moindre privilège. Par exemple, si un compte principal a besoin d'accéder à trois projets sur 10 dans un dossier, vous devez accorder l'accès à chacun des trois projets individuellement. En revanche, si vous avez attribué un rôle sur le dossier, le compte principal peut accéder aux sept autres projets dont il n'a pas besoin.

    Vous pouvez également utiliser les conditions IAM pour attribuer des rôles au niveau de l'organisation ou du dossier, mais uniquement pour un sous-ensemble de dossiers ou de projets.

Étape suivante