Access control determines who has permission to access services and resourcesin a Google Cloud project. In App Engine, there are a few separate use cases forsetting up access control:

• Granting team members access to your Google Cloud project sothey can set up services and deploy apps.

• Granting your app access to Google Cloud services, such as CloudStorage. All Cloud services require authentication and authorization for everyAPI call, including calls from your App Engine app.

• Granting your users access to resources in a Google Cloud project.While this use case isn't common, there may be cases in which your app needsto request access to a Cloud resource on behalf of a user. For example, yourapp may need to access data that belongs to your users.

This page provides an overview of setting up access control in each use case.

For background information on how Google Cloud Platform handles access control,see theoverview of Identity and Access Management (IAM).

Granting access to team members

To give a developer access to your Google Cloud project, create oneor both of the following:

• A user account, which is associated with a Google account andis intended to represent a specific individual on your project.

  A user account can be used to authenticate from the following tools:

  • Google Cloud console
  • Google Cloud CLI
  • IDEs and build tools that use the gcloud CLI to test and deployApp Engine apps

• A service account, which is intended to represent anapplication or a process instead of a person. Use service accounts in yourautomated build, test, and deployment processes, especially if multipledevelopers can run these processes.

  A service account can be used to authenticate from the following tools:

  • gcloud CLI
  • IDEs and build tools that use gcloud CLI tools to test and deployApp Engine apps

Creating a user account

1. Open the IAM page in the Google Cloud console.

   Openthe IAM page

2. ClickSelect a project, choose a project, and clickOpen.

3. ClickAdd.

4. Enter an email address.

5. Select roles thatgrant access to App Enginefeatures.

   If the user also needs access to other Cloud services, selectroles thatgrant access to other Cloud services.

6. ClickSave.

The user can now sign into Google Cloud console as well asauthorize the gcloud CLI.

You can also create user accountsfrom gcloud, the REST API, or clientlibraries.

Creating a service account

1. Open theService Accounts page in the Google Cloud console.

   Open theService Accounts page

2. Select your project and clickOpen.

3. ClickCreate Service Account.

4. Enter a service account name. This should be a user-friendly name for display.

5. ClickCreate.

6. Select roles thatgrant access to App Enginefeatures.

   If the service account also needs access to other Cloud services, selectroles that grant access to other Cloud services.

7. ClickContinue.

8. Optionally, specify user accounts who can manage the service account.You can also specify user accounts who can use the service account toindirectly access all the resources to which the service account has access.

9. ClickSave.

   A list of existing service accounts appears.

10. Optionally, if you need to use your service account outside ofGoogle Cloud, follow the instructions tocreate a service account key.

Next steps

• If you're using the service account in your automated build and deploymentprocesses,authorize the gcloud CLI with a serviceaccount.
• If you're using the service account with an IDE, follow the instructionsprovided by the IDE.
• If you need to use a unique identity for a version of your App Engine app when accessing other Google Cloud services or executing tasks, you can specify auser-managed service account in App Engine.

Granting your app access to Cloud services

Every call to a Cloud service needs to be authenticated and authorized, includingcalls from an App Engine app to other Cloud services such as CloudStorage.

By default, calls from your App Engine app to services in the sameproject are authorized. Here's how the default flow works:

1. To initiate calls to a Cloud service, your app creates a client object, which contains the credentials and other data your app needs to interact with the service. If you don't specify credentials in the client's constructor, the client looks for credentials in the app's environment.

   Here's an example of creating a client for Cloud Storage:

   Go

   // implicit uses Application Default Credentials to authenticate.funcimplicit(){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)iferr!=nil{log.Fatal(err)}deferstorageClient.Close()it:=storageClient.Buckets(ctx,"project-id")for{bucketAttrs,err:=it.Next()iferr==iterator.Done{break}iferr!=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)iferr!=nil{log.Fatal(err)}_=kmsService}

   Java

   staticvoidauthImplicit(){// If you don't specify credentials when constructing the client, the client library will// look for credentials via the environment variable GOOGLE_APPLICATION_CREDENTIALS.Storagestorage=StorageOptions.getDefaultInstance().getService();System.out.println("Buckets:");Page<Bucket>buckets=storage.list();for(Bucketbucket: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.conststorage=newStorage();// Makes an authenticated API request.asyncfunctionlistBuckets(){try{constresults=awaitstorage.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

   defimplicit():fromgoogle.cloudimportstorage# 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 requestbuckets=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.newproject:project_id# Make an authenticated API requeststorage.buckets.eachdo|bucket|putsbucket.nameend

2. By default, the app's environment contains credentials from thedefault App Engine service account.

   This service account is created by Google when you create an App Engine app and is given full permissions to manage and use all Cloud services in a Google Cloud project.

You can override this default flow by doing any of the following:

• Set theGOOGLE_APPLICATION_CREDENTIALS environment variable. If thisvariable is set, Cloud services use the credentials specified by the variableinstead of the default service account.

• Specify credentials when you instantiate theClient object for a Cloud service.For example, if your app is calling a Cloud service in a different project,you may need topass credentialsmanually.

If you set theGOOGLE_APPLICATION_CREDENTIALS environment variable or passcredentials in your code, we recommend that you store your credentials in oneof the following ways:

• Store your credentials in a secure location such asFirestore in Datastore mode (Datastore) and retrieve them at runtime.
• Keep the credentials in your code but encrypt them with a keystore, such asCloud KMS.

To learn about the advantages of each approach, seeChoosing a secret management solution.

Granting users access to Cloud resources

If you want your app to read user data from another Google service, you'll needto set upOAuth 2.0 for Web ServerApplications. For example, if you want to pull a user'sdata from Google Drive and bring it into your app, use OAuth 2.0 for Web ServerApplications to share specific data while keeping other data, such as usernamesand passwords, private.

Google Workspace domain-wide delegation of authority

If you have a Google Workspace (formerly G Suite) domain, an administrator ofthe domain can authorize an application to access user data on behalf of usersin the Google Workspace domain. For example, an application that uses theGoogle Calendar API to add events to the calendars of all users in aGoogle Workspace domain would use a service account to access the GoogleCalendar API on behalf of users.

Authorizing a service account to access data on behalf of users in a domain issometimes referred to as "delegating domain-wide authority" to a serviceaccount. This still uses OAuth 2.0, and requires a Google Workspace domainadministrator toauthorize domain-wide authority to the serviceaccount.

Specifying a service account

App Engine lets you use two types of service accounts:

• TheApp Engine default service accountis the default identity for all versions of your App Engine app if auser-managed service account isn't specified.

  Depending on your organization policy configuration, the default service account might automatically be granted theEditor role on your project. We strongly recommend that you disable the automatic role grant by enforcing theiam.automaticIamGrantsForDefaultServiceAccounts organization policy constraint. If you created your organization after May 3, 2024, this constraint is enforced by default.

  If you disable the automatic role grant, you must decide which roles to grant to the default service accounts, and thengrant these roles yourself.

  If the default service account already has the Editor role, we recommend that you replace the Editor role with less permissive roles.To safely modify the service account's roles, usePolicy Simulator to see the impact of the change, and thengrant and revoke the appropriate roles.

• Theuser-managed service accountis a service account you create in Identity and Access Management (IAM). Youcan specify a user-managed service account for a version, and it will be usedwhen accessing other App Engine services and executing tasks for thatversion.