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:

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 Dataflow Dataproc	Users could attach the Compute Engine default service account to resources, even if they didn't have permission to impersonate the default service account.

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 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 do not recommend using such a highly permissive role in production configurations.

   Note: To further secure your organization, you can disable automatic role grants to service accounts

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.

   Note: If you have a large number of projects, you can use the permission discrepancy finder to find users who have permission to deploy applications, but not to impersonate the App Engine default service account.

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

   Note: This organization policy constraint is only visible in environments with the legacy behavior. If you do not see the constraint, then the constraint is already enforced in your environment.

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

   • In the Google Cloud console, go to the IAM page, 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.

   Note: If you have a large number of projects, you can use the permission discrepancy finder to find users who have permission to deploy Cloud Composer environments, but not to impersonate service accounts.

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

   Note: This organization policy constraint is only visible in environments with the legacy behavior. If you do not see the constraint, then the constraint is already enforced in your environment.

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:

  Note: In Cloud Data Fusion, using service accounts other than the Compute Engine default service account is only available for Cloud Data Fusion Enterprise customers. For more information, see Cloud Data Fusion service accounts.

  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.

     Note: These organization policy constraints are only visible in environments with the legacy behavior. If you do not see the constraints, then the constraints are already enforced in your environment.

  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 do not recommend using such a highly permissive role in production configurations.

     Note: To further secure your organization, you can disable automatic role grants to service accounts.

  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.

     Note: If you have a large number of projects, you can use the permission discrepancy finder to find users who have permission to deploy resources, but not to impersonate the Compute Engine default service account.

  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.