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

Question

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

该Default compute service account有Editor作用。这是Cloud Run 运行时服务帐号。它的目的很明确，我知道我有责任将它配置为最低特权访问。

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

的Google Container Registry Service Agent（Editor角色）和Google Cloud Run Service Agent（Cloud Run Service Agent角色）都是谷歌管理服务帐户“用于访问的谷歌云平台服务API的”：

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

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

Answer 1

云跑PM：

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

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