google-cloud-platform - 为什么启用 Cloud Run API 会创建如此多的服务帐号？为什么他们有这么多特权？

Question

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

默认计算服务帐户具有Editor角色。这是Cloud Run runtime service account 。它的目的很明确，而且我知道我有责任将其配置为最低权限访问。

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

Answer 1

Cloud Run 下午:

1. 是的，完全正确。
2. 如果您仅使用“运行”(并且可能未启用 App Engine API，这就是创建此内容的原因)，我们可能不应该创建此内容。在 Alpha 期间，这是运行时服务帐户，很可能没有清理。
3. 我有一种感觉，它被困在 Editor 中，因为它访问云存储，而“非 Editor 访问”则奇怪地损坏了它(我仍在尝试追踪)确切的问题，但看起来与需要它的旧版 Editor 角色存在连接)。
4. 从它的角度来看，它已经是“最低特权”，因为它仅具有执行 Run 代表您设置资源所需执行的操作的权限。
5. 这是 Cloud Build 的运行时服务帐户，与 1,2 属于同一类别。如果您需要将构建部署到 Cloud Run，则必须向此帐户授予类似 Cloud Run Deployer 的权限(加上允许构建服务帐户充当运行时服务帐户的附加步骤，以防止[或至少承认]权限升级)。

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