Accorder l'accès aux ressources Compute Engine

Les stratégies IAM Cloud pour les ressources Compute Engine vous permettent d'accorder l'accès à des ressources spécifiques, telles que des instances de VM, des disques et des images, en gérant des rôles Cloud IAM sur ces ressources. Vous disposez ainsi de la flexibilité nécessaire pour appliquer le principe du moindre privilège, par exemple, pour accorder des autorisations aux collaborateurs uniquement sur les ressources spécifiques dont ils ont besoin pour travailler.

Les ressources héritent également des stratégies de leurs ressources parentes. La stratégie applicable à une ressource combine la stratégie définie pour celle-ci et la stratégie héritée des niveaux supérieurs de la hiérarchie des ressources.

Lorsque vous liez un membre à une ressource ou que vous définissez la stratégie pour une ressource, les membres ne reçoivent pas de notification par e-mail. Au lieu de cela, l'accès pour chaque membre est mis à jour directement.

Pour en savoir plus sur les types de membres (utilisateurs ou groupes, par exemple) pouvant être inclus dans une stratégie IAM Cloud, consultez la documentation Cloud IAM.

Avant de commencer

Ressources compatibles

Vous pouvez actuellement accorder l'accès aux ressources Compute Engine suivantes :

Vous pouvez également accorder l'accès aux ressources suivantes, mais comme cet accès est actuellement en version bêta, vous devez exécuter les commandes gcloud beta ou celles de l'API en version bêta associées :

Ajouter et supprimer des liaisons de membres à une ressource

Une liaison Cloud IAM sur une ressource attribue un rôle spécifique à un membre sur cette ressource. Vous pouvez ajouter et supprimer des liaisons Cloud IAM sur des instances, des disques, des images et des instantanés à l'aide de la console Google Cloud Platform et de l'outil de ligne de commande gcloud.

Pour mettre à jour la stratégie IAM Cloud pour tous les membres d'une ressource, consultez la section Obtenir et définir la stratégie d'une ressource.

Console

  1. Accédez à la page correspondant à la ressource pour laquelle vous souhaitez ajouter des autorisations.
  2. Cochez les cases à côté des ressources que vous souhaitez mettre à jour.
  3. Cliquez sur Afficher le panneau d'informations pour développer la colonne des autorisations.
  4. Pour ajouter des membres :
    1. Dans le champ Ajouter des membres, ajoutez un ou plusieurs membres.
    2. Dans le menu déroulant Sélectionner un rôle, sélectionnez un ou plusieurs rôles.
    3. Cliquez sur Ajouter pour enregistrer vos modifications.
  5. Pour retirer des membres :
    1. Si la ressource possède des liaisons de stratégies pour un ou plusieurs rôles, ceux-ci apparaissent sous la forme de cartes extensibles. Cliquez sur la carte du rôle auquel vous voulez retirer un ou plusieurs membres.
    2. Cliquez sur l'icône de suppression (supprimer l'icône ressemblant à une corbeille) pour supprimer chaque rôle.

gcloud

Pour accorder un rôle à un membre sur une ressource, exécutez la sous-commande add-iam-policy-binding de la ressource avec les indicateurs --member et --role.

gcloud compute [RESOURCE_TYPE] add-iam-policy-binding [RESOURCE_NAME] \
    --member='[MEMBER]' \
    --role='[ROLE]'

Ou, pour supprimer une liaison de stratégie, utilisez la sous-commande remove-iam-policy-binding de la ressource avec les indicateurs --member et --role.

gcloud compute [RESOURCE_TYPE] remove-iam-policy-binding [RESOURCE_NAME] \
    --member='[MEMBER]' \
    --role='[ROLE]'

où :

  • [RESOURCE_TYPE] est le type de ressource : disks, images, instances, instance-templates, sole-tenancy node-groups, sole-tenancy node-templates ou snapshots.
  • [RESOURCE_NAME] est le nom de la ressource. Par exemple, my_instance ;
  • [MEMBER] est le membre pour lequel on ajoute la liaison ;
    • Il doit être au format user|group|serviceAccount:email ou domain:domain. Par exemple, user:test-user@gmail.com, group:admins@example.com, serviceAccount:test123@example.domain.com ou domain:example.domain.com.
    • Il peut également s'agir de l'une des valeurs spéciales suivantes :
      • allUsers : toute personne ayant accès à Internet, avec ou sans compte Google.
      • allAuthenticatedUsers : toute personne authentifiée avec un compte Google ou un compte de service.
  • [ROLE] est le rôle à ajouter pour ce membre.

Si vous accordez l'accès à une ressource qui est actuellement en version bêta, exécutez plutôt une commande gcloud beta compute.

Obtenir et définir la stratégie d'une ressource

La stratégie IAM Cloud pour une ressource est un ensemble d'instructions définissant qui a accès à la ressource.

Vous pouvez mettre à jour la stratégie pour une ressource en utilisant le modèle Lire-Modifier-Écrire, avec lequel la stratégie IAM Cloud actuelle pour une ressource est d'abord extraite, puis mise à jour et enfin définie. Consultez la documentation Cloud IAM pour plus d'informations sur ce modèle.

gcloud

Vous pouvez utiliser des fichiers JSON ou YAML lors de l'exécution de commandes gcloud pour obtenir ou définir une stratégie de ressource. Les exemples de cette section utilisent JSON.

  1. Récupérez la stratégie que vous souhaitez modifier en exécutant la sous-commande get-iam-policy de la ressource.

    gcloud compute [RESOURCE_TYPE] get-iam-policy [RESOURCE_NAME] --format json > policy.json
    

    où :

    • [RESOURCE_TYPE] est le type de ressource : disks, images, instances, instance-templates ou snapshots.
    • [RESOURCE_NAME] est le nom de la ressource.

    Par exemple, pour récupérer la stratégie IAM Cloud pour un disque nommé example-disk, exécutez :

    gcloud compute disks get-iam-policy example-disk --format json > policy.json
    
  2. Un fichier de stratégie JSON vide ressemblera à ce qui suit. La propriété etag permet de vérifier si la stratégie a été modifiée depuis la dernière requête.

    {
      "etag": "ACAB"
    }
    
  3. À l'aide d'un éditeur de texte, mettez à jour le fichier JSON. Construisez un objet bindings contenant un tableau. Chaque objet du tableau comporte un tableau de members et un rôle associé à ces membres. Par exemple, pour accorder aux groupes all-devs@example.com et some-devs@other-place.com le rôle roles/compute.imageUser, et à bob@example.com le rôle roles/compute.storageAdmin, utilisez :

    {
      "bindings": [
        {
          "members": [
            "group:all-devs@example.com",
            "group:other-devs@other-place.com"
          ],
          "role": "roles/compute.imageUser"
        },
        {
          "members": [
            "user:bob@example.com"
          ],
          "role": "roles/compute.storageAdmin"
        }
      ],
      "etag": "ACAB"
    }
    
  4. Mettez à jour la stratégie en exécutant la sous-commande set-iam-policy de la ressource et en fournissant le chemin d'accès au fichier JSON contenant la nouvelle stratégie. La commande ne peut aboutir que si la valeur etag du fichier JSON correspond à la valeur etag actuelle de la ressource.

    gcloud compute [RESOURCE_TYPE] set-iam-policy [RESOURCE_NAME] policy.json
    

    Par exemple, pour définir la stratégie IAM Cloud pour un disque nommé example-disk, exécutez :

    gcloud compute disks set-iam-policy example-disk policy.json
    
  5. La commande génère la stratégie mise à jour, qui inclut une valeur etag mise à jour.

    bindings:
    - members:
      - user:bob@example.com
        role: roles/compute.storageAdmin
    - members:
      - group:all-devs@example.com
      - group:other-devs@other-place.com
        role: roles/compute.imageUser
    etag: BwUjMhXbSPU=
    

API

Pour modifier une stratégie existante :

  1. Récupérez la stratégie existante en appelant la méthode getIamPolicy() de la ressource.

    Par exemple, sur un disque :

    GET https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/disks/[DISK_NAME]/getIamPolicy
    
  2. La requête renvoie la stratégie, qui inclut un tableau de bindings (si des liaisons existent) et une valeur etag. La propriété etag permet de vérifier si la stratégie a été modifiée depuis la dernière requête.

    {
      "etag": "BwVvzaUs8EY=",
      "bindings":[
        {
          "role":"roles/compute.storageAdmin",
          "members":[
            "user:bob@example.com",
            "serviceAccount:service-account@my-project.iam.gserviceaccount.com"
          ]
        },
        {
          "role":"roles/compute.imageUser",
          "members":[
            "user:email1@gmail.com",
            "user:email2@gmail.com",
            "user:email3@gmail.com"
          ]
        }
      ]
    }
    
  3. Modifiez la stratégie si nécessaire, puis définissez la stratégie mise à jour en appelant la méthode setIamPolicy().

    Par exemple, si vous souhaitez révoquer le rôle compute.imageUser pour email2@gmail.com, la requête ressemblera à ce qui suit.

    POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/disks/[DISK_NAME]/setIamPolicy

    {
      "etag": "BwVvzaUs8EY=",
      "bindings":[
        {
          "role":"roles/compute.storageAdmin",
          "members":[
            "user:bob@example.com",
            "serviceAccount:service-account@my-project.iam.gserviceaccount.com"
          ]
        },
        {
          "role":"roles/compute.imageUser",
          "members":[
            "user:email1@gmail.com",
            "user:email3@gmail.com"
          ]
        }
      ]
    }
    
  4. La réponse affiche la stratégie mise à jour, qui inclut une valeur etag mise à jour.

    {
      "etag": "BwVwGgz7Arg=",
      "bindings":[
        {
          "role":"roles/compute.storageAdmin",
          "members":[
            "user:bob@example.com",
            "serviceAccount:service-account@my-project.iam.gserviceaccount.com"
          ]
        },
        {
          "role":"roles/compute.imageUser",
          "members":[
            "user:email1@gmail.com",
            "user:email3@gmail.com"
          ]
        }
      ]
    }
    

Tester si un appelant dispose d'autorisations

La méthode d'API testIamPermissions prend comme paramètres d'entrée une URL de ressource et un ensemble d'autorisations, et renvoie l'ensemble d'autorisations dont dispose l'appelant. Vous pouvez exécuter cette méthode sur n'importe laquelle des ressources compatibles.

En général, vous n'invoquez pas la méthode testIamPermission si vous utilisez directement GCP pour gérer les autorisations. testIamPermissions est destiné à être intégré à votre logiciel propriétaire, comme une interface utilisateur graphique personnalisée. Par exemple, si vous construisez une interface graphique sur l'API Compute Engine et que votre interface graphique comporte un bouton Démarrer pour démarrer une instance, vous pouvez appeler la méthode compute.instances.testIamPermissions() pour déterminer si le bouton doit être activé ou désactivé.

Pour tester si un appelant dispose d'autorisations spécifiques sur une ressource :

  1. Envoyez une requête à la ressource et incluez dans le corps de la requête la liste des autorisations à vérifier.

    Par exemple, sur une instance, vous pouvez rechercher compute.instances.start, compute.instances.stop et compute.instances.delete.

    POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/instances/[INSTANCE_NAME]/setIamPolicy

    {
      "permissions": [
        "compute.instances.start",
        "compute.instances.stop",
        "compute.instances.delete"
       ]
    }
    
  2. La requête affiche les autorisations actives pour l'appelant.

    {
      "permissions": [
        "compute.instances.start",
        "compute.instances.stop"
      ]
    }
    

Scénarios

Partager des images spécifiques au sein d'une organisation

Imaginons qu'une entreprise dispose d'un ensemble d'images de machines certifiées par le service informatique et souhaite accorder à certaines équipes l'accès à certaines images. Sans les stratégies IAM Cloud pour les ressources Compute Engine, la société devrait soit accorder à tous l'accès à toutes les images, soit stocker les images dans plusieurs projets. Avec les stratégies IAM Cloud pour les ressources Compute Engine, la société peut conserver toutes les images dans un même projet pour en faciliter la gestion et n'accorder aux équipes que l'accès au sous-ensemble d'images dont elles ont besoin pour travailler.

Dans l'exemple ci-dessous, images-project contient plusieurs images. Le groupe all-devs@example.com dispose d'un accès à l'image ubuntu-base-v1-0, mais pas à l'image ubuntu-v1-1-test ni à l'image mysql-v1. De plus, le groupe db-admins@example.com n'a accès qu'à l'image mysql-v1. Vous pouvez mettre en place cette configuration en définissant une stratégie IAM Cloud sur l'image ubuntu-base-v1-0 qui accorde à all-devs@example.com le rôle Utilisateur d'images, et en définissant une stratégie IAM Cloud sur mysql-v1 qui accorde à db-admin@example.com le rôle Utilisateur d'images.

Pour autoriser all-devs@example.com à utiliser l'image shared-image à l'aide de l'outil de ligne de commande gcloud :

  1. Obtenez la stratégie IAM Cloud :

    gcloud compute images get-iam-policy shared-image --format json > policy.json
    
  2. Modifiez policy.json dans un éditeur de texte pour accorder à all-devs@example.com le rôle roles/compute.imageUser :

    {
      "bindings": [
        {
          "members": [
            "group:all-devs@example.com"
          ],
          "role": "roles/compute.imageUser"
        }
      ],
      "etag": "ACAB"
    }
    
  3. Appliquez le fichier policy.json modifié à l'image.

    gcloud compute images set-iam-policy shared-image policy.json
    

Partager des images spécifiques avec le public

Supposons que vous soyez un partenaire Google qui publie des images pour les utilisateurs de Compute Engine. Vous pouvez définir une stratégie IAM Cloud sur une image pour la partager avec tous les utilisateurs authentifiés sur Compute Engine.

Pour rendre l'image shared-image accessible à tous les utilisateurs de Compute Engine à l'aide de l'API Compute Engine :

  1. Obtenez la stratégie IAM Cloud.

    GET https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/images/shared-image/getIamPolicy
    
  2. La requête affiche la stratégie.

    {
     "etag": "ACAB"
    }
    
  3. Appliquez la stratégie modifiée.

    POST https://www.googleapis.com/compute/alpha/projects/[PROJECT_ID]/zones/[ZONE]/images/shared-image/setIamPolicy
    {
      "bindings": [
        {
          "members": [
            "allAuthenticatedUsers"
          ],
          "role": "roles/compute.imageUser"
        }
      ],
      "etag": "ACAB"
    }
    
  4. La requête affiche la stratégie mise à jour.

    {
     "etag": "BwVa45js9SQ=",
     "bindings": [
       {
         "role": "roles/compute.imageUser",
         "members": [
           "allAuthenticatedUsers"
         ]
       }
     ]
    }
    

Accorder à un coéquipier l'accès à une instance pour corriger un problème

Supposons que vous ayez créé une instance et que vous souhaitiez que alice@example.com aide à corriger un problème. Accordez à alice@example.com le rôle Administrateur d'instance Compute (v1) sur l'instance en modifiant la stratégie IAM Cloud de l'instance.

Si celle-ci est configurée pour s'exécuter en tant que compte de service et que vous souhaitez qu'Alice puisse se connecter via SSH, définir des métadonnées ou associer un disque, accordez à alice@example.com le rôle Utilisateur du compte de service sur le compte de service de l'instance. L'octroi de ce rôle sur le compte de service est nécessaire, car ces trois opérations permettent à Alice d'exécuter des commandes en son nom. Consultez la section Autorisations de compte de service pour plus d'informations sur le traitement des comptes de service en tant que ressource.

Si vous souhaitez qu'Alice gère l'instance via la console GCP, accordez-lui un rôle disposant de l'autorisation compute.projects.get. Par exemple, vous pouvez accorder à Alice le rôle Lecteur de Compute, qui contient cette autorisation. Ce rôle permet également de consulter toutes les ressources Compute Engine du projet, mais pas de lire les données des disques, des images ou des instantanés. Vous pouvez également créer un rôle personnalisé avec les autorisations nécessaires.

Voici comment procéder avec gcloud :

  1. Obtenez la stratégie IAM Cloud pour l'instance.

    gcloud compute instances get-iam-policy example-instance --format json > policy.json
    
  2. Modifiez policy.json dans un éditeur de texte.

    {
      "bindings": [
        {
          "members": [
            "user:alice@example.com"
          ],
          "role": "roles/compute.instanceAdmin.v1"
        }
      ],
      "etag": "ACAB"
    }
    
  3. Appliquez le fichier policy.json modifié à l'instance.

    gcloud compute instances set-iam-policy example-instance policy.json
    
  4. Accordez à alice@example.com le rôle Utilisateur du compte de service sur le compte de service de l'instance. Supposons que le compte de service de l'instance soit data-reader-service-account@[PROJECT_ID].iam.gserviceaccount.com.

     gcloud iam service-accounts add-iam-policy-binding \
         data-reader-service-account@[PROJECT_ID].iam.gserviceaccount.com \
         --member="user:alice@example.com" \
         --role="roles/iam.serviceAccountUser"
    

    gcloud renvoie les éléments suivants :

     bindings:
     - members:
       - user:alice@example.com
       role: roles/iam.serviceAccountUser
     etag: BwVa42MC-aY=
    
  5. Accordez à alice@example.com le rôle Lecteur de Compute sur le projet.

    gcloud projects add-iam-policy-binding [PROJECT_ID] \
        --member=user:alice@example.com \
        --role=roles/compute.viewer
    

    gcloud renvoie les éléments suivants :

    bindings:
    - members:
      - user:alice@example.com
      role: roles/iam.serviceAccountUser
    [...]
    etag: BwVa42MC-aY=
    

À présent, Alice peut voir l'instance dans la console GCP et elle est autorisée à appeler n'importe quelle méthode sur l'instance. Si Alice a besoin d'autorisations sur d'autres ressources (par exemple, des sous-réseaux ou des pare-feu), accordez-lui le rôle prédéfini approprié (par exemple, Utilisateur réseau).

Étapes suivantes

Cette page vous a-t-elle été utile ? Évaluez-la :

Envoyer des commentaires concernant…

Documentation Compute Engine