Function Identity
For security most interactions between entities in Google Cloud require that each entity have a verifiable identity, secured by some kind of secret, like a password or a key. Just as other entities need an identity to access Cloud Functions, functions themselves often need access to other resources in Google Cloud to do their work. Every function is associated with a service account that serves as its identity when the function accesses other resources. The service account a function uses as its identity is also known as its runtime service account.
For production use, Google recommends that you give each function a dedicated identity by assigning it a user-managed service account. User-managed service accounts allow you to control access by granting a minimal set of permissions using Identity and Access Management.
Runtime service account
Unless you specify a different runtime service account when deploying a function, Cloud Functions uses a default service account as its identity for function execution:
Cloud Run functions uses the default compute service account,
PROJECT_NUMBER-compute@developer.gserviceaccount.com
.Note that the project number is distinct from the project ID and project name. You can find your project number on the Google Cloud console Dashboard page.
Depending on your organization policy configuration, the default service account might
automatically be granted the Editor role on your
project. We strongly recommend that you disable the automatic role grant by
enforcing the iam.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 then grant 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, use Policy Simulator to see the impact of the change, and then grant and revoke the appropriate roles.
To secure your functions in production:
- Change permissions on the default runtime service account, or
- Create individual service accounts for your functions
Changing permissions on the default runtime service account
Console
Go to the IAM page in the Google Cloud console:
Select the App Engine default service account or Default compute service account from the table.
Click the pencil icon on the right side of the row to show the Edit permissions tab.
Add or remove roles in the Role dropdown to provide least privilege access.
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="SERVICE_ACCOUNT_EMAIL" \ --role="roles/editor" # Add the desired role gcloud projects add-iam-policy-binding PROJECT_ID \ --member="SERVICE_ACCOUNT_EMAIL" \ --role="ROLE"
Where PROJECT_ID
is the project ID of the project
you're using, SERVICE_ACCOUNT_EMAIL
is the email
address of the default runtime service account as shown earlier in
Runtime service account, and
ROLE
is the new role to assign to the default
runtime service account.
Using individual service accounts for your functions
To give you greater flexibility in controlling access for your functions, you can give them each their own user-managed service account.
- Create your service account. Make a note of its name.
- Grant it the appropriate roles, based on what resources the function needs to access to do its work.
If the service account and the function are in different projects, from the project where the service account is located:
- Configure the service account to work across projects.
Grant the Service Account Token Creator role (
roles/iam.serviceAccountTokenCreator
) to Cloud Run Service Agent (service-PROJECT_NUMBER@serverless-robot-prod.iam.gserviceaccount.com
), wherePROJECT
refers to the project in which the function resides. Cloud Run Service Agent manages cross-project access for your service account.Grant the
iam.serviceaccounts.actAs
permission to the Cloud Run functions service agent (service-PROJECT_NUMBER@gcf-admin-robot.iam.gserviceaccount.com
) on the service account from the different project.
Grant the service account access to the resource. The method for doing this depends on the resource type.
Connect the service account with your function. You can do this either at deployment time or by updating a previously deployed function.
Adding a user-managed service account at deployment
Console
Go to the Google Cloud console:
Specify and configure the function however you would like.
Click Runtime, build... to display additional settings.
Select the Runtime tab.
Click the Service account dropdown and select the desired service account.
Click Next and Deploy.
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
email.
Updating the service account of an existing function
You can update the runtime service account of an existing function.
Console
Go to the Google Cloud console:
Click the name of the desired function to go to its detail page.
Click the Edit pencil at the top of the detail page to edit the function.
Click Runtime, build... to display additional settings.
Select the Runtime tab.
Click the Service account dropdown and select the desired service account.
Click Next and 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.
The redeployed function now uses the new runtime service account.
Using the Metadata Server to acquire tokens
While IAM-defined service accounts are the preferred method for managing access in Google Cloud, some services might require other modes, such as an API key, OAuth 2.0 client, or service account key. Access to an external resource might also require alternate methods.
If your target service requires that you present an OpenID Connect ID token or an Oauth 2.0 access token, you might be able to use the Compute Metadata Server to fetch these tokens rather than setting up a full OAuth client.
Identity tokens
You can use the Compute Metadata Server to fetch ID 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 requested target, 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
OAuth 2.0 access tokens use scopes to define access permissions. By default,
within Google Cloud access tokens have the cloud-platform
scope. In
order to access other Google or Google Cloud APIs, you 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 authorize access to your functions or to authenticate developers and other functions so that they can invoke your functions.