Grant a workflow permission to access Google Cloud resources

Workflows uses service accounts to give workflows access to Google Cloud resources. Service accounts are special accounts that serve as the identity of a non-person, like a function, an application, or a VM. They give you a way to authenticate these non-persons. A service account can be thought of as both an identity and a resource.

  • When thinking of a service account as an identity, you can grant a role to a service account, allowing it to access a resource (such as a workflow).

  • When thinking of a service account as a resource, you can grant roles to other users to access or manage that service account.

A service account is identified by its email address, which is unique to the account.

For more information about setting up authentication with a production application, see Authenticate as a service account.

Default service account

Every workflow is associated with an Identity and Access Management (IAM) service account at the time the workflow is created. If you don't specify a service account during the workflow's creation, the workflow uses the default Compute Engine service account for its identity. You can verify a workflow's associated service account. In this document, see Verify a workflow's associated service account.

  • We recommend using the default service account for testing and development only. For production environments, we strongly recommend creating a new service account and granting it one or more IAM roles that contain the minimum permissions required for managing workflows.

  • The only roles required by your service account are those required to access the resources orchestrated by your workflows. For more information, in this document, see Service account permissions.

Service account permissions

Because service accounts are identities, you can let a service account access resources in your project by granting it a role, just like you would for any other principal. For example, if you want to let your workflow send logs to Cloud Logging, make sure the service account executing the workflow has been granted a role that includes the logging.logEntries.create permission (for example, the Logs Writer role). In general, the roles required by your service account depend on the resources you are orchestrating with your workflows. To determine which roles are required, review the product documentation for the resource you're orchestrating, or choose predefined roles.

Note that the workflow service account does not require the workflows.invoker role, unless the workflow invokes itself or other workflows (that is, creates new workflow executions). For more information, see Invoke Workflows.

For more information on granting roles to principals, including service accounts, see Manage access to projects, folders, and organizations.

Attaching service accounts to resources

To create a resource and attach a service account, you need permissions to create that resource and to attach the service account to the resource. Permission to attach the service account to a resource is provided by any role that includes the iam.serviceAccounts.actAs permission.

For more information, see Roles for service account authentication.

Invoke Cloud Run functions

In Cloud Run functions, invocation permissions are available by managing the underlying Cloud Run service. If your workflow is invoking a Cloud Run functions service, you don't need to grant the caller's service account the Cloud Functions Invoker (roles/cloudfunctions.invoker) role. Instead, you must grant the Cloud Run Invoker (roles/run.invoker) role.

For more information, see Compare Cloud Run functions.

Deploy a workflow with a custom service account

You can create your own user-managed service account to give you greater flexibility in controlling access to your workflow.

  1. Create your service account and note its name.

  2. Grant the service account the appropriate roles, based on what resources the workflow must access to do its work.

  3. Ensure that all principals who deploy workflows have the ability to attach the service account to resources. If you created the service account, you are automatically granted this permission. For more information, see Roles for service account authentication.

    To get the permission that you need to attach a service account to a resource, ask your administrator to grant you the Service Account User (roles/iam.serviceAccountUser) IAM role on your project or the service account. For more information about granting roles, see Manage access to projects, folders, and organizations.

    This predefined role contains the iam.serviceAccounts.actAs permission, which is required to attach a service account to a resource.

    You might also be able to get this permission with custom roles or other predefined roles.

    Grant the role on the project:

    gcloud projects add-iam-policy-binding WORKFLOWS_PROJECT_ID \
    --member=PRINCIPAL \
    --role='roles/iam.serviceAccountUser'

    Or, grant the role on the service account:

    gcloud iam service-accounts add-iam-policy-binding SERVICE_ACCOUNT_RESOURCE_NAME \
    --member=PRINCIPAL \
    --role='roles/iam.serviceAccountUser'

    Replace the following:

    • WORKFLOWS_PROJECT_ID: your Google Cloud project ID that contains the workflow resources