Configurer le contrôle des accès

Le contrôle des accès détermine qui est autorisé à accéder aux services et aux ressources dans un projet Google Cloud. Dans App Engine, il existe différents cas d'utilisation pour la configuration du contrôle des accès :

Accorder aux membres de votre équipe l'accès à votre projet Google Cloud afin qu'ils puissent configurer des services et déployer des applications.
Accorder à votre application l'accès aux services Google Cloud tels que Cloud Storage. Tous les services cloud nécessitent une authentification et une autorisation pour chaque appel d'API, y compris pour les appels provenant de votre application App Engine.
Accorder à vos utilisateurs l'accès aux ressources d'un projet Google Cloud. Bien que ce cas d'utilisation ne soit pas courant, il peut arriver que votre application doive demander l'accès à une ressource cloud pour le compte d'un utilisateur. Par exemple, votre application pourrait avoir besoin d'accéder aux données appartenant à vos utilisateurs.

Cette page présente la configuration du contrôle des accès pour chacun de ces cas d'utilisation.

Pour obtenir des informations générales sur la manière dont Google Cloud Platform gère le contrôle des accès, consultez la présentation d'Identity and Access Management (IAM).

Accorder l'accès aux membres de l'équipe

Pour permettre à un développeur d'accéder à votre projet Google Cloud, créez au moins l'un des deux éléments suivants :

Un compte utilisateur associé à un compte Google et destiné à représenter une personne spécifique de votre projet.

Vous pouvez vous servir d'un compte utilisateur pour vous authentifier à partir des outils suivants :
- Console Google Cloud
- Google Cloud CLI
- Des IDE et outils de développement qui se servent de gcloud CLI pour tester et déployer des applications App Engine
Un compte de service destiné à représenter une application ou un processus au lieu d'une personne. Utilisez les comptes de service dans vos processus automatisés de compilation, de test et de déploiement, surtout si plusieurs développeurs peuvent exécuter ces processus.

Vous pouvez vous servir d'un compte de service pour vous authentifier à partir des outils suivants :
- CLI gcloud
- Des IDE et outils de développement qui se servent des outils de gcloud CLI pour tester et déployer des applications App Engine

Créer un compte utilisateur

Ouvrez la page "IAM" dans Google Cloud Console.
Ouvrir la page IAM
Cliquez sur Sélectionner un projet, choisissez un projet et cliquez sur Ouvrir.
Cliquez sur Ajouter.
Saisissez une adresse e-mail.
Sélectionnez des rôles qui accordent l'accès aux fonctionnalités App Engine.

Si l'utilisateur a également besoin d'accéder à d'autres services cloud, sélectionnez des rôles permettant d'accéder à d'autres services cloud.
Cliquez sur Enregistrer.

L'utilisateur peut désormais se connecter à la console Google Cloud et autoriser la gcloud CLI.

Vous pouvez également créer des comptes utilisateur à partir de gcloud, de l'API REST ou des bibliothèques clientes.

Créer un compte de service

Ouvrez la page Comptes de service dans la console Google Cloud.
Accéder à la page "Comptes de service"
Sélectionnez votre projet et cliquez sur Ouvrir.
Cliquez sur Créer un compte de service.
Saisissez un nom de compte de service. Il doit s'agir d'un nom d'affichage facile à lire.
Cliquez sur Créer.
Sélectionnez des rôles qui accordent l'accès aux fonctionnalités App Engine.

Si le compte de service a également besoin d'accéder à d'autres services cloud, sélectionnez des rôles permettant d'accéder à d'autres services cloud.
Cliquez sur Continuer.
Vous pouvez éventuellement spécifier des comptes utilisateur pouvant gérer le compte de service, ainsi que des comptes utilisateur pouvant se servir du compte de service pour accéder indirectement à toutes les ressources auxquelles le compte de service a accès.
Cliquez sur Enregistrer.

La liste des comptes de service existants s'affiche.
Si vous devez utiliser votre compte de service en dehors de Google Cloud, suivez les instructions permettant de créer une clé de compte de service.

Étapes suivantes

Si vous utilisez le compte de service dans vos processus automatisés de compilation et de déploiement, autorisez gcloud CLI à l'aide d'un compte de service.
Si vous utilisez le compte de service avec un IDE, suivez les instructions fournies par l'IDE.
Si vous devez utiliser une identité unique pour une version de votre application App Engine lorsque vous accédez à d'autres services Google Cloud ou que vous exécutez des tâches, vous pouvez spécifier un compte de service géré par l'utilisateur dans App Engine.

Accorder à votre application l'accès aux services cloud

Chaque appel vers un service cloud doit être authentifié et autorisé, y compris les appels provenant d'une application App Engine et à destination d'autres services cloud tels que Cloud Storage.

Par défaut, les appels de votre application App Engine vers les services d'un même projet sont autorisés. Voici le flux par défaut :

Pour initier des appels vers un service cloud, votre application crée un objet client qui contient les identifiants et autres données dont votre application a besoin pour interagir avec le service. Si vous ne spécifiez pas d'identifiants dans le constructeur du client, le client recherche les identifiants dans l'environnement de l'application.

Voici un exemple de création de client pour Cloud Storage :

Go


// implicit uses Application Default Credentials to authenticate.
func implicit() {
	ctx := context.Background()

	// For API packages whose import path is starting with "cloud.google.com/go",
	// such as cloud.google.com/go/storage in this case, if there are no credentials
	// provided, the client library will look for credentials in the environment.
	storageClient, err := storage.NewClient(ctx)
	if err != nil {
		log.Fatal(err)
	}
	defer storageClient.Close()

	it := storageClient.Buckets(ctx, "project-id")
	for {
		bucketAttrs, err := it.Next()
		if err == iterator.Done {
			break
		}
		if err != nil {
			log.Fatal(err)
		}
		fmt.Println(bucketAttrs.Name)
	}

	// For packages whose import path is starting with "google.golang.org/api",
	// such as google.golang.org/api/cloudkms/v1, use NewService to create the client.
	kmsService, err := cloudkms.NewService(ctx)
	if err != nil {
		log.Fatal(err)
	}

	_ = kmsService
}

Java

static void authImplicit() {
  // If you don't specify credentials when constructing the client, the client library will
  // look for credentials via the environment variable GOOGLE_APPLICATION_CREDENTIALS.
  Storage storage = StorageOptions.getDefaultInstance().getService();

  System.out.println("Buckets:");
  Page<Bucket> buckets = storage.list();
  for (Bucket bucket : buckets.iterateAll()) {
    System.out.println(bucket.toString());
  }
}

Node.js

// Imports the Google Cloud client library.
const {Storage} = require('@google-cloud/storage');

// Instantiates a client. If you don't specify credentials when constructing
// the client, the client library will look for credentials in the
// environment.
const storage = new Storage();
// Makes an authenticated API request.
async function listBuckets() {
  try {
    const results = await storage.getBuckets();

    const [buckets] = results;

    console.log('Buckets:');
    buckets.forEach(bucket => {
      console.log(bucket.name);
    });
  } catch (err) {
    console.error('ERROR:', err);
  }
}
listBuckets();

PHP

// Imports the Cloud Storage client library.
use Google\Cloud\Storage\StorageClient;

/**
 * Authenticate to a cloud client library using a service account implicitly.
 *
 * @param string $projectId The Google project ID.
 */
function auth_cloud_implicit($projectId)
{
    $config = [
        'projectId' => $projectId,
    ];

    # If you don't specify credentials when constructing the client, the
    # client library will look for credentials in the environment.
    $storage = new StorageClient($config);

    # Make an authenticated API request (listing storage buckets)
    foreach ($storage->buckets() as $bucket) {
        printf('Bucket: %s' . PHP_EOL, $bucket->name());
    }
}

Python

def implicit():
    from google.cloud import storage

    # If you don't specify credentials when constructing the client, the
    # client library will look for credentials in the environment.
    storage_client = storage.Client()

    # Make an authenticated API request
    buckets = list(storage_client.list_buckets())
    print(buckets)

Ruby

# project_id = "Your Google Cloud project ID"

require "google/cloud/storage"

# If you don't specify credentials when constructing the client, the client
# library will look for credentials in the environment.
storage = Google::Cloud::Storage.new project: project_id

# Make an authenticated API request
storage.buckets.each do |bucket|
  puts bucket.name
end

C#

public object AuthImplicit(string projectId)
{
    // If you don't specify credentials when constructing the client, the
    // client library will look for credentials in the environment.
    var credential = GoogleCredential.GetApplicationDefault();
    var storage = StorageClient.Create(credential);
    // Make an authenticated API request.
    var buckets = storage.ListBuckets(projectId);
    foreach (var bucket in buckets)
    {
        Console.WriteLine(bucket.Name);
    }
    return null;
}

Par défaut, l'environnement de l'application contient les identifiants du compte de service App Engine par défaut.
Ce compte de service est créé par Google lorsque vous créez une application App Engine. Il dispose de toutes les autorisations nécessaires pour gérer et utiliser tous les services cloud d'un projet Google Cloud.

Vous pouvez remplacer ce flux par défaut en effectuant l'une des opérations suivantes :

Définissez la variable d'environnement GOOGLE_APPLICATION_CREDENTIALS. Si cette variable est définie, les services cloud utilisent les identifiants spécifiés par la variable au lieu du compte de service par défaut.
Spécifiez les identifiants lorsque vous instanciez l'objet Client pour un service cloud. Par exemple, si votre application appelle un service cloud dans un autre projet, vous devrez peut-être transmettre manuellement les identifiants.

Si vous définissez la variable d'environnement GOOGLE_APPLICATION_CREDENTIALS ou transmettez les identifiants dans votre code, nous vous recommandons de stocker vos identifiants de l'une des manières suivantes :

Stockez vos identifiants dans un emplacement sécurisé tel que Firestore en mode Datastore (Datastore) et récupérez-les au moment de l'exécution.
Conservez les identifiants dans votre code, mais chiffrez-les à l'aide d'un keystore, tel que Cloud KMS.

Pour en savoir plus sur les avantages offerts par chacune de ces deux options, consultez la section concernant le choix d'une solution de gestion des codes secrets.

Accorder aux utilisateurs l'accès aux ressources cloud

Si vous souhaitez que votre application lise les données utilisateur d'un autre service Google, vous devez configurer OAuth 2.0 pour les applications de serveur Web. Par exemple, si vous voulez extraire les données d'un utilisateur de Google Drive et les importer dans votre application, utilisez OAuth 2.0 pour les applications de serveur Web. De cette manière, vous partagerez des données spécifiques tout en préservant la confidentialité d'autres données, telles que les noms d'utilisateur et les mots de passe.

Délégation d'autorité au niveau du domaine Google Workspace

Si vous possédez un domaine Google Workspace (anciennement G Suite), un administrateur du domaine peut autoriser une application à accéder aux données utilisateur pour le compte des utilisateurs du domaine Google Workspace. Par exemple, une application qui se sert de l'API Google Agenda pour ajouter des événements aux agendas de tous les utilisateurs d'un domaine Google Workspace peut accéder à l'API Google Agenda pour le compte des utilisateurs via un compte de service.

Le fait d'autoriser un compte de service à accéder aux données pour le compte d'utilisateurs d'un domaine est parfois appelé "délégation de l'autorité au niveau du domaine" à ce compte de service. Cette approche utilise toujours OAuth 2.0 et nécessite qu'un administrateur de domaine Google Workspace délègue l'autorité au compte de service au niveau du domaine.

Spécifier un compte de service

App Engine vous permet d'utiliser deux types de comptes de service :

Compte de service spécifique à une version : compte de service configuré en tant qu'identité pour une version spécifique de votre service déployé. Lorsque vous déployez une version existante ou nouvelle, vous pouvez spécifier un compte de service qui agit en tant qu'identité de cette version. Par exemple, si une version nécessite des autorisations différentes de celles du compte de service par défaut au niveau de l'application, vous pouvez attribuer un compte de service spécifique à cette version. Pour en savoir plus, consultez la page Configurer les comptes de service App Engine.

Compte de service par défaut au niveau de l'application : si vous ne configurez pas de compte de service spécifique à une version, Google Cloud utilise le compte de service par défaut au niveau de l'application pour tous vos services déployés. Vous attribuez le compte de service par défaut au niveau de l'application lors de sa création. Pour en savoir plus, consultez la section Définir un compte de service par défaut au niveau de l'application.

Si vous n'attribuez pas de compte de service par défaut au niveau de l'application, Google Cloud utilise le compte de service App Engine par défaut créé automatiquement (PROJECT_ID@appspot.gserviceaccount.com).

Selon la configuration de vos règles d'administration, le compte de service par défaut peut se voir attribuer automatiquement le rôle Éditeur sur votre projet. Nous vous recommandons vivement de désactiver l'attribution automatique des rôles en appliquant la contrainte de règle d'administration iam.automaticIamGrantsForDefaultServiceAccounts. Si vous avez créé votre organisation après le 3 mai 2024, cette contrainte est appliquée par défaut.

Si vous désactivez l'attribution automatique de rôles, vous devez choisir les rôles à attribuer aux comptes de service par défaut, puis attribuer ces rôles vous-même.

Si le compte de service par défaut dispose déjà du rôle Éditeur, nous vous recommandons de le remplacer par des rôles moins permissifs. Pour modifier les rôles du compte de service en toute sécurité, utilisez Policy Simulator pour voir l'impact de la modification, puis attribuez et révoquez les rôles appropriés.