Function Identity

Runtime service account

During function execution, Cloud Functions uses the service account PROJECT_ID@appspot.gserviceaccount.com as its identity. For instance, when making requests to Google Cloud Platform services using the Google Cloud Client Libraries, Cloud Functions can automatically obtain and use tokens to authorize the services this identity has permissions to use.

Changing default permissions

By default, the runtime service account has the Editor role, which lets it access many GCP services. While this is the fastest way to develop functions, it's likely too permissive for what your function needs in production, and you'll want to configure it for least privilege access.

Console

  1. Go to the Google Cloud Console:

    Go to Google Cloud Console

  2. Select the App Engine default Service Account (PROJECT_ID@appspot.gserviceaccount.com) from the table.

  3. Click the pencil on the right side of the row to show the Edit permissions tab.

  4. Add or remove roles in the role dropdown to provide least privilege access.

  5. Click Save.

GCloud

Remove the Editor role, then use the gcloud projects add-iam-policy-binding command to add a new role:

# Remove the Editor role
gcloud projects remove-iam-policy-binding PROJECT_ID \
  --member="PROJECT_ID@appspot.gserviceaccount.com"
  --role="roles/editor"

# Add the desired role
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="PROJECT_ID@appspot.gserviceaccount.com"
  --role="ROLE"

Where PROJECT_ID is the project ID of the project you're using and ROLE is the new role to assign to the runtime service account.

Per-function identity

If you have multiple functions all accessing different resources, you'll likely want to give each function its own identity. This can be done by deploying the function with a named service account that has the correct role. The service account being deployed must have been created in the same project as the function it is attached to.

Permissions required to use non-default identities

In order to deploy a function with a non-default service account, the deployer must have the iam.serviceAccounts.actAs permission on the service account being deployed.

If a user creates a service account, that user is automatically granted this permission; otherwise, a user with the correct permissions must grant the deployer this permission on the service account in order for the user to deploy.

Deploying a new function with a non-default identity

Before you deploy a function with a new identity, make sure that the service account you want to use is already created. If not, learn how to create and manage service accounts.

Console

  1. Go to the Google Cloud Console:

    Go to Google Cloud Console

  2. Configure the function however you would like.

  3. Click Environment variables, networking, timeouts and more to display additional settings.

  4. Click the Service account dropdown and select the desired service account.

  5. Click Create.

GCloud

When deploying a function using gcloud functions deploy, add the --service-account flag. For example:

gcloud functions deploy FUNCTION_NAME --service-account SERVICE_ACCOUNT_EMAIL

where FUNCTION_NAME is your function name, and SERVICE_ACCOUNT_EMAIL is the service account associated with the new identity.

Updating the identity of an existing function

You can also update existing functions to have a new runtime service account.

Console

  1. Go to the Google Cloud Console:

    Go to Google Cloud Console

  2. Click the name of the desired function to go to its detail page.

  3. Click the EDIT pencil at the top of the detail page to edit the function.

  4. Click Environment variables, networking, timeouts and more to display additional settings.

  5. Click the Service account dropdown and select the desired service account.

  6. Click Deploy.

GCloud

When deploying a function using gcloud functions deploy, add the --service-account flag:

gcloud functions deploy FUNCTION_NAME --service-account SERVICE_ACCOUNT_EMAIL

where FUNCTION_NAME is your function name, and SERVICE_ACCOUNT_EMAIL is the service account associated with the new identity.

Fetching identity and access tokens

You can use the Compute Metadata Server to fetch identity tokens and access tokens. You cannot query the metadata server directly from your local computer.

Identity tokens

You use identity tokens when calling other Cloud Functions or any other service that can validate an identity token.

You can use the Compute Metadata Server to fetch identity tokens with a specific audience as follows:

curl "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/identity?audience=AUDIENCE" \
  -H "Metadata-Flavor: Google"

Where AUDIENCE is the JWT Audience requested, for example: the URL of a service you're invoking, such as https://service.domain.com, or the OAuth Client ID of an IAP protected resource, such as 1234567890.apps.googleusercontent.com.

Access tokens

You use access tokens when calling Google APIs.

By default, access tokens have the cloud-platform scope, which allows access to all Google Cloud Platform APIs, assuming IAM also allows access. In order to access other Google or Google Cloud APIs, you will need to fetch an access token with the appropriate scope.

You can use the Compute Metadata Server to fetch access tokens.

If you need an access token with a specific scope, you can generate one as follows:

curl "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token?scopes=SCOPES" \
  -H "Metadata-Flavor: Google"

Where SCOPES is a comma separated list of OAuth scopes requested, for example: https://www.googleapis.com/auth/drive,https://www.googleapis.com/auth/spreadsheets.

Consult the full list of Google OAuth scopes to find which scopes you need.

Next steps

Learn how to manage access to or securely authenticate developers, functions, and end-users to your functions.