Requiring permission to attach service accounts to resources

When you create certain Google Cloud resources, you have the option to attach a service account . The attached service account acts as the identity of any jobs running on the resource, allowing the jobs to authenticate to Google Cloud APIs.

For most Google Cloud services, users need permission to impersonate a service account in order to attach that service account to a resource. This means that the user needs the iam.serviceAccounts.actAs permission on the service account.

However, in the past, certain services allowed users to attach service accounts to resources even if the users didn't have permission to impersonate the service accounts. This configuration might have made it possible for users of these services to gain elevated, non-obvious permissions.

The following table lists services that had this configuration, along with each service's legacy behavior:

We now require that these services check that users have permission to impersonate service accounts when attaching the service accounts to resources. However, the legacy behavior still exists for the following types of organizations:

• Organizations with users who have permission to deploy App Engine applications, but don't have permission to impersonate the App Engine default service account.
• Organizations with users who have permission to deploy Cloud Composer environments, but don't have permission to impersonate any service accounts.
• Organizations with users who have permission to deploy Cloud Data Fusion, Dataflow, or Dataproc resources, but don't have permission to impersonate the Compute Engine default service account.
• Organizations with users who have permission to attach a service account to a Dataform resource and create a workflow invocation, but don't have permission to impersonate the service account.

If your organization is still affected by the legacy behavior, you will have received communication explaining how to manually disable it. You can also refer to the sections below for detailed instructions.

Securing App Engine

To manually disable the legacy behavior for App Engine, ensure that users have permission to impersonate the App Engine service account. Then, enable an organization policy constraint to enforce service account permission checks when deploying applications that use the identity of the App Engine default service account.

1. Optional: Use role recommendations to safely downscope permissions for the App Engine default service account.

   The App Engine default service account is automatically granted the highly permissive Editor role ( roles/editor ). However, we don't recommend using such a highly permissive role in production configurations.

2. Ensure that all users who deploy applications have the ability to impersonate the App Engine default service account.

   To provide this ability, grant the users a role that includes the iam.serviceAccounts.actAs permission, like the Service Account User role ( roles/iam.serviceAccountUser ). You can grant this role on the project or on the App Engine default service account. For instructions, see Managing service account impersonation .

3. Enable the organization policy constraint constraints/appengine.enforceServiceAccountActAsCheck to enforce service account permission checks when deploying applications.

4. Optional: Use the boolean organization policy enforcer to confirm that the organization policy constraint is enforced in all of your projects.

Securing Cloud Composer

To manually disable the legacy behavior for Cloud Composer, ensure that users have permission to impersonate the service accounts that they attach to new environments. Then, enable an organization policy constraint to enforce service account permission checks when attaching service accounts to environments.

1. Identify all service accounts that are bound to Cloud Composer environments:

   1. In the Google Cloud console, go to the Composer environmentspage.

      Go to the Composer environments page

   2. Click the name of an environment.

   3. In the Environment configurationtab, find the Service accountfield and record the name of the service account.

   4. Repeat the preceding steps for all Cloud Composer environments in your project.

2. Confirm that these service accounts follow the principle of least privilege :

   • In the Google Cloud console, go to the IAMpage, find the service accounts, and review their roles.

     Go to the IAM page

   • If necessary, grant a less permissive role to the service account. You can select a role from the list of IAM predefined roles , use a role suggested by a role recommendation , or create a custom role .

3. Ensure that all users who deploy or manage Cloud Composer environments have the ability to impersonate the service accounts that the environments use.

   To provide this ability, grant the users a role that includes the iam.serviceAccounts.actAs permission, like the Service Account User role ( roles/iam.serviceAccountUser ). You can grant this role on the project or on an individual service account. For instructions, see Managing service account impersonation .

4. Enable the organization policy constraint constraints/composer.enforceServiceAccountActAsCheck to enforce service account permission checks when attaching service accounts to environments.

5. Optional: Use the boolean organization policy enforcer to confirm that the organization policy constraint is enforced in all of your projects.

Securing Dataproc, Dataflow, and Cloud Data Fusion

To manually disable the legacy behavior for Dataproc, Dataflow, and Cloud Data Fusion, ensure that users have permission to impersonate the service accounts that they attach to new resources. Then, enable organization policy constraints to enforce service account permission checks when attaching service accounts to resources.

Follow the instructions for the type of service account that you want to attach to new resources:

• If you want to stop attaching the Compute Engine default service account to new resources, follow these steps:

  1. Create a new service account and grant the service account the roles it needs to run jobs on the resource. Make sure to follow the principle of least privilege .

     To learn which roles a service account needs to run jobs on Dataproc, Dataflow, and Cloud Data Fusion resources, see the following:

     • Dataproc service account requirements
     • Dataflow service account requirements
     • Cloud Data Fusion service accounts have the same requirements as Dataproc service accounts.

  2. Allow all users who deploy these resources to impersonate the new service account.

     To provide this ability, grant users a role that includes the iam.serviceAccounts.actAs permission, like the Service Account User role ( roles/iam.serviceAccountUser ). You can grant this role on the project or on the service account. For instructions, see Managing service account impersonation .

  3. Enable the following organization policy constraints to enforce service account permission checks when attaching service accounts to resources:

     • constraints/dataflow.enforceComputeDefaultServiceAccountCheck
     • constraints/dataproc.enforceComputeDefaultServiceAccountCheck

     The organization policy constraint constraints/dataproc.enforceComputeDefaultServiceAccountCheck also enforces permission checks for Cloud Data Fusion.

  4. Optional: Use the boolean organization policy enforcer to confirm that the organization policy constraints are enforced in all of your projects.

  5. When you deploy new resources, use the new service account instead of the Compute Engine default service account.

• If you want to continue to attach the Compute Engine default service account to new resources, follow these steps:

  1. Optional: Use role recommendations to safely downscope permissions for the Compute Engine default service account.

     The Compute Engine default service account is automatically granted the highly permissive Editor role ( roles/editor ). However, we don't recommend using such a highly permissive role in production configurations.

  2. Ensure that all users who deploy these resources have the ability to impersonate the Compute Engine default service account.

     To provide this ability, grant the users a role that includes the iam.serviceAccounts.actAs permission, like the Service Account User role ( roles/iam.serviceAccountUser ). You can grant this role on the project or on the Compute Engine default service account. For instructions, see Managing service account impersonation .

  3. Enable the following organization policy constraints to enforce service account permission checks when attaching service accounts to resources:

     • constraints/dataflow.enforceComputeDefaultServiceAccountCheck
     • constraints/dataproc.enforceComputeDefaultServiceAccountCheck

  4. Optional: Use the boolean organization policy enforcer to confirm that the organization policy constraints are enforced in all of your projects.

Securing Dataform

To manually disable the legacy behavior for Dataform, ensure that users have permission to impersonate the service accounts that they attach to Dataform resources. Then, enable strict act-as mode to enforce service account permission checks when creating workflow invocations.

1. Check for permission issues to avoid interrupting your workflows. You can do this by querying Cloud Logging for Dataform-specific entries that indicate a principal (user or service account) is missing the required iam.serviceAccounts.actAs permission. This lets you proactively identify and resolve any access discrepancies. For more information, see Check for permission issues in Cloud Logging .

2. For users or service accounts that need to create workflow invocations, grant them the permission to impersonate the service account associated with the Dataform repository. You can provide this permission by granting the Service Account User role ( roles/iam.serviceAccountUser ) on the specific service account. For more information, see Resolve permission issues .

3. If you're using a custom service account, grant the following roles to the default Dataform service agent on the custom service account:

   • Service Account Token Creator ( roles/iam.serviceAccountTokenCreator ): required for all repository operations using a custom service account.
   • Service Account User ( roles/iam.serviceAccountUser ): required only if you're using workflow configurations to schedule or automate executions. This role allows the default Dataform service agent to run tasks as the custom service account.

4. To enforce the act-as permission check, enable strict act-as mode. This feature enhances security by verifying that any user creating a workflow invocation has the iam.serviceAccounts.actAs permission on the effective service account.

   • For a new repository, strict act-as mode is enabled by default.
   • For an existing repository, update the repository by setting the strict_act_as_checks flag to true .

   For more information, see Use strict act-as mode .

5. Periodically audit your Dataform resources to ensure proper service account usage and permission grants. Use Cloud Asset Inventory to list all resources of the dataform.Repository and dataform.WorkflowConfig types, and then inspect the resource.data.serviceAccount field to check which service account is being used. If a custom service account is used, verify that the default Dataform service agent has both the Service Account User ( roles/iam.serviceAccountUser ) and Service Account Token Creator ( roles/iam.serviceAccountTokenCreator ) roles on that custom service account. For more information, see Audit service account configurations .