为啥启用 Cloud Run API 会创建这么多服务帐号？为啥他们有这么多特权？

Posted 2023-02-16

【中文标题】为啥启用 Cloud Run API 会创建这么多服务帐号？为啥他们有这么多特权？

【英文标题】：Why does enabling the Cloud Run API create so many service accounts? Why do they have so many privileges?为什么启用 Cloud Run API 会创建这么多服务帐号？为什么他们有这么多特权？

【发布时间】：2019-09-01 16:01:02

【问题描述】：

启用 Cloud Run API（开发控制台→Cloud Run→启用）会创建五个服务帐户。我想了解他们的目的。我需要知道是否有责任将它们配置为最低权限访问。

Default compute service account 具有Editor 角色。这是Cloud Run runtime service account。它的目的很明确，我知道我有责任将其配置为最低权限访问。

App Engine default service account 具有Editor 角色。这与Cloud Functions runtime service account 的描述相匹配。鉴于 Cloud Run 运行时服务帐户的存在，其目的尚不清楚。我不知道是否有责任将其配置为最低权限访问。

Google Container Registry Service Agent（Editor 角色）和Google Cloud Run Service Agent（Cloud Run Service Agent 角色）都是Google-managed service accounts“用于访问 Google Cloud Platform 服务的 API”：

我希望看到配置为最低权限访问的 Google 管理的服务帐户。我还希望能够在 GCP 控制台的 IAM 部分过滤 Google 管理的服务帐户。也就是说，我知道我应该忽略它们。

未命名的project-numberatcloudbuild.gserviceaccount.com 服务帐户具有Cloud Build Service Account 角色。此服务帐号“可以执行构建”，但未出现在 Cloud Run Building Containers 文档中。它用于Continuous Deployment——但如果没有额外的用户配置就无法做到这一点。它不是 Google 管理的服务帐户，但它不像运行时服务帐户那样出现在 GCP 控制台的“服务帐户”部分中。其目的尚不清楚。我不知道是否有责任将其配置为最低权限访问。

【参考方案1】：

云运行 PM：

是的，完全正确。 如果您只使用 Run，我们可能不应该创建它（并且可能没有启用 App Engine API，这就是创建这个的原因）。在 Alpha 版期间，这是运行时服务帐号，很可能没有清理干净。 我感觉它被卡在了 Editor 上，因为它访问云存储，奇怪的是“非 Editor 访问”（我仍在尝试追查确切的问题，但看起来有一个连接到需要它的旧版 Editor 角色）。 从它的角度来看已经是“最低权限”，因为它只具有执行 Run 需要执行的操作以代表您设置资源的权限。 这是与 Cloud Build 等效的运行时服务帐户，与 1,2 属于同一类别。如果您需要将构建部署到 Cloud Run，您必须授予此帐户 Cloud Run Deployer 之类的权限（加上允许构建服务帐户充当您的运行时服务帐户的附加步骤，以防止 [或至少承认]权限提升）。

我也希望更好地过滤“Google 创建”和“Google 管理”，并且一直在与 Cloud IAM 团队讨论这个问题。