Dépannage de "withcond" dans les stratégies et les liaisons de rôles

Lorsque vous consultez une stratégie d'autorisation, vous pouvez voir des noms de rôles incluant la chaîne withcond suivie d'une valeur de hachage. Par exemple, vous pouvez voir un nom de rôle tel que roles/iam.serviceAccountAdmin_withcond_2b17cc25d2cd9e2c54d8.

Cette page explique quand et pourquoi vous pouvez voir la chaîne withcond dans une stratégie d'autorisation. Elle vous recommande également les mesures à prendre si vous voyez cette chaîne.

Versions de stratégies et liaisons de rôle conditionnelles

Une stratégie d'autorisation peut être représentée sous différentes formes, qui sont appelées versions de stratégie d'autorisation.

Dans une stratégie d'autorisation utilisant la version 1, certaines liaisons de rôles peuvent contenir la chaîne withcond dans un nom de rôle, suivie d'une valeur de hachage :

{
  "bindings": [
    {
      "members": [
        "user:[email protected]"
      ],
      "role": "roles/iam.serviceAccountAdmin_withcond_2b17cc25d2cd9e2c54d8"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

Ce format indique que la liaison de rôle est conditionnelle. En d'autres termes, le rôle n'est accordé que si des conditions spécifiques sont remplies.

Les stratégies d'autorisation de version 1 ne présentent pas ces conditions. Si vous voyez la chaîne withcond suivie d'une valeur de hachage, la liaison de rôle inclut une condition qui n'est pas visible.

Solution : spécifier la version de stratégie 3

Pour vous assurer de pouvoir afficher et mettre à jour l'intégralité de la règle d'autorisation, y compris ses conditions, vous devez toujours spécifier la version 3 lorsque vous obtenez ou définissez une stratégie d'autorisation. Pour spécifier la version 3, effectuez les tâches décrites dans les sections suivantes.

Mettre à jour l'outil gcloud

Si vous utilisez Google Cloud CLI, exécutez la commande gcloud version pour vérifier son numéro de version. Le résultat inclut une chaîne semblable à celle-ci : Google Cloud CLI 279.0.0.

Si le numéro de version est inférieur à 263.0.0, exécutez gcloud components update pour mettre à jour la CLI gcloud. Dans les versions 263.0.0 et ultérieures, gcloud CLI spécifie automatiquement une version de stratégie d'autorisation compatible avec les conditions.

Mettre à jour les bibliothèques clientes

Si votre application utilise une bibliothèque cliente, procédez comme suit :

  1. Recherchez le nom et le numéro de version de la bibliothèque cliente, puis consultez la liste des bibliothèques clientes compatibles avec les versions de stratégies d'autorisation.

    • Si vous utilisez déjà une version récente de la bibliothèque cliente et qu'elle est compatible avec les versions de stratégies d'autorisation, vous n'avez pas besoin de mettre à jour votre bibliothèque cliente. Passez à l'étape suivante.

    • Si vous utilisez une ancienne version de la bibliothèque cliente, et qu'une version ultérieure est compatible avec les versions de stratégies d'autorisation, mettez à jour votre bibliothèque cliente vers la version la plus récente.

    • Si vous utilisez une bibliothèque cliente qui n'est pas compatible avec les versions de stratégies d'autorisation, vous pouvez ajouter à votre application une autre bibliothèque cliente qui est compatible avec les versions de stratégies d'autorisation. Utilisez cette bibliothèque cliente pour travailler avec les stratégies d'autorisation. Vous pouvez également utiliser l'API REST IAM directement.

  2. Mettez à jour le code de votre application qui obtient et définit les stratégies d'autorisation :

Mettre à jour les appels d'API REST

Si votre application utilise directement l'API REST IAM, mettez à jour le code qui obtient et définit les stratégies d'autorisation :

Mettre à jour les outils de gestion des stratégies

Si vous conservez des copies locales de vos stratégies d'autorisation (par exemple, si vous les stockez dans un système de contrôle des versions et les traitez comme du code), assurez-vous que tous les outils que vous utilisez répondent aux critères suivants :

  • Toutes les requêtes pour obtenir ou définir une stratégie d'autorisation spécifient la version 3.
  • Toutes les requêtes de définition d'une stratégie d'autorisation incluent le champ etag.

Si un outil ne répond pas à ces critères, recherchez une version à jour de celui-ci.

Assurez-vous également que vos outils de gestion conservent les attributions de rôles conditionnelles, plutôt que d'ajouter une attribution de rôle en double qui n'inclut pas de condition. Prenons les exemples suivants :

  1. Vous accordez le rôle "Créer des comptes de service" (roles/iam.serviceAccountCreator) à l'utilisateur [email protected] sur le dossier my-folder. La stratégie d'autorisation du dossier est semblable à l'exemple suivant :

    {
  "bindings": [
    {
      "members": [
        "user:[email protected]"
      ],
      "role": "roles/iam.serviceAccountCreator"
    }
  ],
  "etag": "BuFmmMhCsNY=",
  "version": 1
}

  2. Vous utilisez un outil pour récupérer la stratégie d'autorisation et la stocker dans un système de contrôle des versions.

  3. Vous ajoutez une condition de sorte que [email protected] ne puisse créer des comptes de service que pendant la semaine de travail normale, en fonction de la date et de l'heure de Berlin, en Allemagne. La stratégie d'autorisation mise à jour est semblable à l'exemple suivant :

    {
  "bindings": [
    {
      "members": [
        "user:[email protected]"
      ],
      "role": "roles/iam.serviceAccountCreator",
      "condition": {
        "title": "work_week_only",
        "expression": "request.time.getDayOfWeek('Europe/Berlin') >= 1 && request.time.getDayOfWeek('Europe/Berlin') <= 5"
      }
    }
  ],
  "etag": "BwWcR/B3tNk=",
  "version": 3
}

  4. Vous utilisez un outil pour récupérer la stratégie d'autorisation mise à jour. L'outil ne spécifie pas de version de stratégie d'autorisation lorsqu'il demande la stratégie d'autorisation. Vous recevez donc une stratégie d'autorisation de version 1 avec un nom de rôle modifié :

    {
  "bindings": [
    {
      "members": [
        "user:[email protected]"
      ],
      "role": "roles/iam.serviceAccountCreator_withcond_a75dc089e6fa084bd379"
    }
  ],
  "etag": "BwWcR/B3tNk=",
  "version": 1
}

À ce stade, l'outil de gestion peut décider que la liaison entre [email protected] et le rôle roles/iam.serviceAccountCreator a disparu, et qu'il doit restaurer la liaison de rôle originale de la stratégie d'autorisation :

À éviter : Toute liaison de rôle supplémentaire sans condition

{
  "bindings": [
    {
      "members": [
        "user:[email protected]"
      ],
      "role": "roles/iam.serviceAccountCreator_withcond_a75dc089e6fa084bd379"
    },
    {
      "members": [
        "user:[email protected]"
      ],
      "role": "roles/iam.serviceAccountCreator"
    }
  ],
  "etag": "BwWd3HjhKxE=",
  "version": 1
}

Cette modification n'est pas correcte : elle attribue le rôle roles/iam.serviceAccountCreator à [email protected] quel que soit le jour de la semaine. Par conséquent, la condition incluse dans la première liaison de rôle n'a aucun effet.

Si vos outils de gestion tentent d'effectuer ce type de modification, n'approuvez pas la modification. Vous devez plutôt mettre à jour vos outils de gestion pour spécifier la version de stratégie d'autorisation 3 dans les requêtes.

Étape suivante