需要具备将服务账号关联到资源的权限

创建某些 Google Cloud 资源时,您可以选择关联一个服务账号。关联的服务账号充当该资源上运行的任何作业的身份,从而允许作业向 Google Cloud API 进行身份验证。

对于大多数 Google Cloud 服务,用户需要具备模拟服务账号的权限才能将该服务账号关联到资源。这意味着用户需要具备该服务账号的 iam.serviceAccounts.actAs 权限。

但是,在过去,即使用户不具备模拟服务账号的权限,某些服务也允许用户将服务账号关联到资源。此配置可能会使这些服务的用户获得不易发现的权限提升。

下表列出了具有此配置的服务以及每个服务的旧版行为:

服务 旧版行为
App Engine 用户可以部署 App Engine 应用,这些应用使用 App Engine 默认服务账号的身份,即使他们无权模拟 App Engine 默认服务账号也是如此。
Cloud Composer 即使用户不具备模拟项目的任何服务账号的权限,也可以将项目中的任何服务账号关联到 Cloud Composer 环境。
  • Cloud Data Fusion
  • Dataflow
  • Dataproc
用户可以将 Compute Engine 默认服务账号关联到资源,即使用户无权模拟默认服务账号也是如此。

现在,我们要求这些服务在将服务账号关联到资源时检查用户是否具备模拟服务账号的权限。但是,以下类型的组织仍然存在旧版行为

  • 组织中的用户有权部署 App Engine 应用,但无权模拟 App Engine 默认服务账号。
  • 组织中的用户有权部署 Cloud Composer 环境,但无权模拟任何服务账号。
  • 组织中的用户有权部署 Cloud Data Fusion、Dataflow 或 Dataproc 资源但无权模拟 Compute Engine 默认服务账号。

如果您的组织仍然受旧版行为的影响,则您将收到说明如何手动禁止旧版行为的通知。您也可以参考以下各个部分来了解详细的说明。

保护 App Engine

如需手动停用 App Engine 的旧版行为,请确保用户有权模拟 App Engine 服务账号。然后,在部署使用 App Engine 默认服务账号的身份的应用时,启用组织政策限制条件以强制执行服务账号权限检查。

  1. 可选:使用角色建议安全地缩小 App Engine 默认服务账号的权限范围。

    系统会自动向 App Engine 默认服务账号授予高度宽容模式的 Editor 角色 (roles/editor)。但是,我们不建议在生产配置中使用这类高度宽容模式的角色。

  2. 确保部署应用的所有用户都可以模拟 App Engine 默认服务账号。

    如需提供此功能,请向用户授予包含 iam.serviceAccounts.actAs 权限的角色,例如 Service Account User 角色 (roles/iam.serviceAccountUser)。您可以对项目或 App Engine 默认服务账号授予此角色。如需查看相关说明,请参阅管理服务账号模拟

  3. 启用组织政策限制条件 constraints/appengine.enforceServiceAccountActAsCheck,以在部署应用时强制执行服务账号权限检查。

  4. 可选:使用布尔值组织政策实施程序来确认所有项目都强制执行了组织政策限制条件。

保护 Cloud Composer

如需手动禁止 Cloud Composer 的旧版行为,请确保用户有权模拟他们关联到新环境的服务账号。然后,启用组织政策限制条件,以便在将服务账号关联到环境时实施服务账号权限检查。

  1. 标识绑定到 Cloud Composer 环境的所有服务账号:

    1. 在 Google Cloud 控制台中,前往 Composer 环境页面。

      转到“Composer 环境”(Composer environments) 页面

    2. 点击环境的名称。

    3. 环境配置 (Environment configuration) 标签页中,找到服务账号字段,然后记录服务账号的名称。

    4. 对项目中的所有 Cloud Composer 环境重复上述步骤。

  2. 确认这些服务账号遵循最小权限原则:

  3. 确保所有部署或管理 Cloud Composer 环境的用户都可以模拟这些环境使用的服务账号。

    如需提供此功能,请向用户授予包含 iam.serviceAccounts.actAs 权限的角色,例如 Service Account User 角色 (roles/iam.serviceAccountUser)。您可以对项目或单个服务账号授予此角色。如需查看相关说明,请参阅管理服务账号模拟

  4. 启用组织政策限制条件 constraints/composer.enforceServiceAccountActAsCheck,以便在将服务账号关联到环境时实施服务账号权限检查。

  5. 可选:使用布尔值组织政策实施程序来确认所有项目都强制执行了组织政策限制条件。

保护 Dataproc、Dataflow、Cloud Data Fusion

如需手动禁止 Dataproc、Dataflow、Cloud Data Fusion 的旧版行为,请确保用户有权模拟他们关联到新资源的服务账号。然后,启用组织政策限制条件,以便在将服务账号关联到资源时实施服务账号权限检查。

对于您要关联到新资源的服务账号类型,请按照相应的说明执行操作:

  • 如果您想停止将 Compute Engine 默认服务账号关联到新资源,请按照以下步骤操作:

    1. 创建一个新的服务账号,然后向该服务账号授予在资源上运行作业所需的角色。请务必遵循最小权限原则

      如需了解服务账号在 Dataproc、Dataflow、Cloud Data Fusion 资源上运行作业时需要哪些角色,请参阅以下内容:

    2. 允许部署这些资源的所有用户模拟新的服务账号。

      如需提供此功能,请向用户授予包含 iam.serviceAccounts.actAs 权限的角色,例如 Service Account User 角色 (roles/iam.serviceAccountUser)。您可以对项目或服务账号授予此角色。如需查看相关说明,请参阅管理服务账号模拟

    3. 启用以下组织政策限制条件,以在将服务账号关联到资源时强制执行服务账号权限检查:

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

      组织政策限制条件 constraints/dataproc.enforceComputeDefaultServiceAccountCheck 还会对 Cloud Data Fusion 实施权限检查。

    4. 可选:使用布尔值组织政策实施程序来确认所有项目都强制执行了组织政策限制条件。

    5. 部署新资源时,请使用新服务账号(而不是 Compute Engine 默认服务账号)。

  • 如果您想继续将 Compute Engine 默认服务账号关联到新资源,请按照以下步骤操作:

    1. 可选:使用角色建议安全地缩小 Compute Engine 默认服务账号的权限范围。

      系统会自动向 Compute Engine 默认服务账号授予高度宽容模式的 Editor 角色 (roles/editor)。但是,我们不建议在生产配置中使用这类高度宽容模式的角色。

    2. 确保部署这些资源的所有用户都可以模拟 Compute Engine 默认服务账号。

      如需提供此功能,请向用户授予包含 iam.serviceAccounts.actAs 权限的角色,例如 Service Account User 角色 (roles/iam.serviceAccountUser)。您可以对项目或 Compute Engine 默认服务账号授予此角色。如需查看相关说明,请参阅管理服务账号模拟

    3. 启用以下组织政策限制条件,以在将服务账号关联到资源时强制执行服务账号权限检查:

      • constraints/dataflow.enforceComputeDefaultServiceAccountCheck
      • constraints/dataproc.enforceComputeDefaultServiceAccountCheck
    4. 可选:使用布尔值组织政策实施程序来确认所有项目都强制执行了组织政策限制条件。