本页面介绍了什么是服务账号，以及在服务账号生命周期的每个阶段管理服务账号时的重要注意事项。
什么是服务账号？
服务账号是一种通常由应用或计算工作负载（例如 Compute Engine 实例）而非真人使用的特殊账号。服务账号由其电子邮件地址（对该账号是唯一的）标识。
应用使用服务账号来执行已获授权的 API 调用（以服务账号本身的身份进行身份验证或者以 Google Workspace 或 Cloud Identity 用户的身份通过全网域授权功能进行身份验证）。 当应用是使用服务账号证明其身份时，它可以访问该服务账号有权访问的所有资源。
若要让应用使用服务账号证明其身份，最常见的方法是将服务账号关联到运行该应用的资源。例如，您可以将服务账号关联到某个 Compute Engine 实例，以便在该实例上运行的应用可以使用该服务账号证明其身份。然后，您可以向服务账号授予 IAM 角色，让该服务账号（以及实例上的应用）可以访问相应的 Google Cloud 资源。
除了关联服务账号之外，您还可以通过其他方式让应用使用服务账号证明其身份。例如，您可以设置工作负载身份联合以允许外部工作负载使用服务账号证明其身份；也可以创建服务账号密钥，这样便可在任何环境中使用该密钥来获取 OAuth 2.0 访问令牌。
如需详细了解应用服务账号身份验证，请参阅工作负载身份概览。
主账号（例如用户和其他服务账号）也可以使用服务账号证明其身份。如需了解详情，请参阅本页面上的服务账号模拟。
服务账号的类型
在 Google Cloud 中，有几种不同类型的服务账号：
用户管理的服务账号：您创建和管理的服务账号。这些服务账号通常用作工作负载身份。
默认服务账号：在您启用某些 Google Cloud 服务时自动创建的用户管理的服务账号。您负责管理这些服务账号。
服务代理：由 Google Cloud 创建和管理的服务账号，可允许服务代表您访问资源。
如需详细了解不同类型的服务账号，请参阅服务账号类型。
服务账号凭据
应用和主账号可通过以下方式之一使用服务账号证明其身份：
- 获取短期有效凭据。在许多情况下（例如使用 gcloud CLI
--impersonate-service-account标志关联的服务账号和命令），系统会自动获取这些凭据，您无需自行创建或管理。 - 使用服务账号密钥对 JSON Web 令牌 (JWT) 签名并用其来换取访问令牌。 由于服务账号密钥管理不当会造成安全风险，因此您应该尽可能选择选择更安全的服务账号密钥替代方案。
如需详细了解服务账号身份验证，请参阅服务账号凭据。
服务账号模拟
经过身份验证的主账号（例如用户或其他服务账号）以服务账号的身份进行身份验证以获取该服务账号的权限时，这就称为模拟服务账号。通过模拟服务账号，经过身份验证的主账号可以访问服务账号可以访问的任何内容。只有具有适当权限的经过身份验证的主账号才能模拟服务账号。
如果您想在不更改 Identity and Access Management (IAM) 政策的情况下更改用户权限，则模拟非常有用。例如，您可以使用模拟向用户临时授予提升的访问权限，或测试一组特定权限是否足以执行任务。您还可以使用模拟在本地开发只能以服务账号身份运行的应用，或者验证在 Google Cloud 外部运行的应用的身份。
如需详细了解服务账号模拟，请参阅服务账号模拟。
服务账号和 Google Workspace 网域
不同于用户账号，服务账号不属于您的 Google Workspace 网域。如果您与整个 Google Workspace 网域共享 Google Workspace 资源（例如文档或事件），系统并不会与服务账号共享这些资源。同样，服务账号创建的 Google Workspace 资源不会在您的 Google Workspace 网域中创建。因此，您的 Google Workspace 和 Cloud Identity 管理员无法拥有或管理这些资源。
服务账号权限
服务账号是主账号。这意味着您可以向服务账号授予对 Google Cloud 资源的访问权限。例如，您可以向服务账号授予项目的 Compute Admin 角色 (roles/compute.admin)。之后，该服务账号便能够管理该项目中的 Compute Engine 资源。
但是，服务账号同样也是资源。这意味着您可以授予其他主账号访问服务账号的权限。例如，您可以为用户授予服务账号的 Service Account User 角色 (roles/iam.serviceAccountUser)，以允许用户将该服务账号关联到资源。或者，您可以向用户授予 Service Account Admin 角色 (roles/iam.serviceAccountAdmin)，以允许用户执行查看、修改、停用和删除服务账号等操作。
以下部分介绍如何管理作为主账号和资源的服务账号。
作为主账号的服务账号
由于服务账号是主账号，因此您可以为服务账号授予角色（就像为任何其他主账号授予角色一样），以便服务账号能够访问您项目中的资源。例如，如果您希望允许该服务账号访问 Cloud Storage 存储桶中的对象，则可以向服务账号授予存储桶的 Storage Object Viewer 角色 (roles/storage.objectViewer)。
与所有类型的主账号一样，您应该只授予服务账号实现其目标所需的最低权限集。
与其他主账号一样，您可以将服务账号添加到 Google 群组，然后向该群组授予角色。但是，将服务账号添加到群组不是最佳做法。服务账户由应用使用，每个应用可能都有自己的访问权限要求。
如需了解如何向主账号（包括服务账号）授予角色，请参阅管理对项目、文件夹和组织的访问权限。
作为资源的服务账号
服务账号也是资源，可以具有自己的允许政策。因此，您可以为其他主账号授予服务账号或某个服务账号父资源上的角色，从而允许他们访问服务账号。例如，如需允许用户模拟服务账号，您可以向该用户授予服务账号的 Service Account Token Creator 角色 (roles/iam.serviceAccountTokenCreator)。
请注意，授予允许用户模拟服务账号的角色后，用户将可以访问该服务账号可以访问的所有资源。在允许用户模拟具有高度特权的服务账号（例如 Compute Engine 和 App Engine 默认服务账号）时，需谨慎操作。
如需详细了解您可以向主账号授予哪些服务账号角色，请参阅服务账号权限。
如需了解如何为主账号授予服务账号的角色，请参阅管理对服务账号的访问权限。
服务账号生命周期
管理项目时，您可能会创建、管理和删除许多不同的服务账号。本部分介绍在服务账号各个生命周期阶段管理服务账号时的关键注意事项。
创建服务账号的位置
每个服务账号都位于一个项目中。服务账号创建后，便无法再移动到其他项目中。
您可以通过以下几种方式将服务账号整理到项目中：
在同一项目中创建服务账号和资源。
这种方法让您可以更轻松地开始使用服务账号。但是，当服务账户分布在多个项目中时，可能很难跟踪它们。
集中不同项目中的服务账号。
此方法会将您的组织的所有服务账号都放置在少量项目中，从而简化服务账号的管理。但是，如果将服务账号连接到其他项目中的资源，则此方法需要额外的设置，这使这些资源可以将服务账号用作其身份。
如果一个服务账号位于一个项目中，并且其访问另一个项目中的资源，您通常必须在这两个项目中为此资源启用 API。例如，如果您在项目
my-service-accounts中拥有一个服务账号并在项目my-application中拥有一个 Cloud SQL 实例，您必须同时在my-service-accounts和my-application中启用 Cloud SQL API。默认情况下，您最多可以在一个项目中创建 100 个服务账号。如果您需要创建其他服务账号，请申请增加配额。
如需了解如何创建服务账号，请参阅创建服务账号。
阻止创建服务账号
为了更好地控制服务账号的创建位置，您可能需要阻止在组织的某些项目中创建服务账号。
您可以通过在组织、项目或文件夹中强制执行 constraints/iam.disableServiceAccountCreation 组织政策限制条件来防止创建服务账号。
在强制执行此限制条件之前，请考虑以下限制：
如果您在项目或组织的所有项目中强制实施此限制条件，则某些 Google Cloud 服务将无法创建默认服务账号。因此，可能会导致项目运行的工作负载需要使用服务账号来证明其身份，而该项目却不包含工作负载可以使用的服务账号。
如需解决此问题，您可以启用跨项目服务账号模拟。启用此功能后，您可以在一个集中的项目中创建服务账号，然后将服务账号关联到其他项目中的资源。在这些资源上运行的工作负载可以使用关联的服务账号进行身份验证，因此无需默认服务账号。
某些功能（例如工作负载身份联合）要求您创建服务账号。
如果您不使用工作负载身份联合，请考虑使用组织政策限制条件来阻止来自所有身份提供方的联合。
跟踪服务账号
一段时间后，随着您创建越来越多的服务账号，您可能无法跟踪哪个服务账号用于何种用途。
服务账号的显示名称是一种不错的方法，可以捕获有关该服务账号的其他信息，例如服务账号的用途或该账号的联系人。对于新的服务账号，您可以在创建服务账号时填充显示名称。对于现有服务账号，请使用 serviceAccounts.update() 方法修改显示名称。
在 Compute Engine 中使用服务账号
Compute Engine 实例需要以服务账号的身份运行来访问其他 Cloud Platform 资源。为了帮助保护您的 Compute Engine 实例，请考虑以下事项：
您可以使用不同的服务账号在同一个项目中创建实例。若要在创建实例后更改其服务账号，可以使用
instances.setServiceAccount方法。如需为关联的服务账号设置授权，除了配置 IAM 角色之外，您还需要配置访问权限范围。
由于实例依赖其服务账号才有权访问 Google Cloud 资源，因此请避免在运行中的实例仍在使用服务账号时将其删除。
如需详细了解如何在 Compute Engine 中使用服务账号，请参阅 Compute Engine 文档中的服务账号部分。
识别未使用的服务账号
一段时间后，您的项目中可能会有不再需要使用的服务账号。
未使用的服务账号会带来不必要的安全风险，因此我们建议您停用未使用的服务账号，并在确定不再需要时删除这些服务账号。您可以使用以下方法来识别未使用的服务账号：
通常，您还可以使用服务账号使用情况指标来跟踪服务账号和密钥的使用情况。
如果您是 Security Command Center 高级方案客户，则可以使用 Event Threat Detection 在有休眠服务账号触发操作时获取通知。休眠服务账号是处于非活跃状态超过 180 天的服务账号。再次使用休眠服务账号后，它便不再处于休眠状态。
删除服务账号
在删除服务账号之前，请先停用该服务账号，以确保不再需要该服务账号。如果已停用的服务账号仍在使用，便可将其重新启用。
确认不再需要某个服务账号后，便可删除该服务账号。
重新创建已删除的服务账号
删除服务账号后创建名称相同的新服务账号，这一操作是可以实现的。
删除服务账号时，不会立即删除其角色绑定。相反，角色绑定会列出前缀为 deleted: 的服务账号。如需查看示例，请参阅包含已删除主账号的政策。
如果您创建一个与最近删除的服务账号具有相同名称的新服务账号，则旧绑定可能仍然存在；但是，它们不会应用于新的服务账号，即使两个账号具有相同的电子邮件地址也是如此。出现这种行为的原因是服务账号在创建时获得了在 Identity and Access Management (IAM) 中的唯一 ID。系统在内部使用这些 ID 授予所有角色绑定，而不是使用服务账号的电子邮件地址。因此，为已删除的服务账号存在的任何角色绑定都不会应用于使用相同电子邮件地址的新服务账号。
同样，如果您将服务账号附加到资源，然后删除该服务账号并创建一个具有相同名称的新服务账号，则新服务账号不会附加到该资源。
为防止出现这种意外行为，请考虑为每个服务账号使用新的唯一名称。此外，如果您不小心删除了服务账号，可以尝试恢复删除的服务账号，而不是创建新的服务账号。
如果您无法恢复删除的原始服务账号，并且需要创建具有相同名称和相同角色的新服务账号，则必须向新服务账号授予这些角色。如需了解详情，请参阅包含已删除主账号的政策。
如果您还需要将新服务账号关联到原始服务账号所关联到的相同资源，请执行以下操作之一：
- 对于 Compute Engine 实例，您可以更改附加到实例的服务账号，以将原始服务账号替换为新服务账号。
- 对于其他所有资源，您必须删除现有资源，然后创建相同类型的新资源并附加新服务账号。
后续步骤
- 了解如何创建服务账号。
- 获取使用服务账号的最佳实践。
- 查看管理服务账号密钥的最佳实践。