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
App Engine Users could deploy App Engine applications, which use the identity of the App Engine default service account, even if they didn't have permission to impersonate the App Engine default service account.
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 the default service account.
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 App Engine applications, but do not have permission to impersonate the App 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.
  • 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.

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 the IAM recommender 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 do not 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 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 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:

    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
    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 the IAM recommender 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 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 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.