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 may 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:

Service Legacy behavior
Cloud Composer Users could attach any service account in the project to a Cloud Composer environment, even if they didn't have permission to impersonate any of the project's service accounts.
Cloud Data Fusion Users could attach the Compute Engine default service account to resources, even if they didn't have permission to impersonate it.
Dataflow
Dataproc

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 Cloud Data Fusion, Dataflow, or Dataproc resources, but do not have permission to impersonate the Compute Engine default service account.
  • Organizations with users who have permission to deploy Cloud Composer environments, but do not have permission to impersonate any service accounts.

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 Cloud Composer

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

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

    1. In the Cloud Console, go to the Composer environments page.

      Go to the Composer environments page

    2. Click the name of an environment.

    3. In the Environment configuration tab, find the Service account field 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:

  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 following organization policy constraint to require the iam.serviceAccounts.actAs permission when binding a resource to a service account:

    • constraints/composer.enforceServiceAccountActAsCheck
  5. (Optional) Use the boolean org policy enforcer to confirm that the preceding 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, first ensure that users have permission to impersonate the service accounts that they attach to new resources. Then, enable organization policy constraints to require permission 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:

    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 require the iam.serviceAccounts.actAs permission when binding a resource to a service account:

      • constraints/dataflow.enforceComputeDefaultServiceAccountCheck
      • constraints/dataproc.enforceComputeDefaultServiceAccountCheck
    4. (Optional) Use the boolean org policy enforcer to confirm that the preceding 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. Use the IAM recommender to safely downscope the Compute Engine default service account's permissions.

      The Compute Engine default service account is automatically granted the highly permissive Editor role. However, we do not 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 require the iam.serviceAccounts.actAs permission when binding a resource to a service account:

      • constraints/dataflow.enforceComputeDefaultServiceAccountCheck
      • constraints/dataproc.enforceComputeDefaultServiceAccountCheck
    4. (Optional) Use the boolean org policy enforcer to confirm that the preceding organization policy constraints are enforced in all of your projects.