启用云运行 API(dev console→Cloud Run→Enable)会创建五个服务帐户。我想了解他们的目的。我需要知道是否有责任将它们配置为最低特权访问。
Default compute service account具有Editor作用。这是云运行运行时服务帐户。它的目的很明确，我知道我有责任将其配置为最低特权访问。
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角色)都是 Google 托管的服务帐号，"用于访问 Google Cloud Platform 服务的 API"：
我希望看到 Google 托管的服务帐号配置为最低权限访问权限。我还希望能够在 GCP 控制台的 IAM 部分中筛选 Google 托管的服务帐户。也就是说，我知道我应该忽略它们。
未命名的{project-number}{at}cloudbuild.gserviceaccount.com服务帐户具有Cloud Build Service Account角色。此服务帐户"可以执行生成"，但不会出现在 Cloud Run 生成容器文档中。它用于持续部署，但如果没有其他用户配置，则无法做到这一点。它不是 Google 托管的服务帐号，但不会像运行时服务帐号那样显示在 GCP 控制台的"服务帐号"部分中。其目的尚不清楚。我不知道是否有责任将其配置为最低特权访问。
Cloud Run PM：
- 是的，完全正确。
- 如果您只使用"运行"(并且可能未启用 App Engine API，而这正是创建此功能的原因)，则我们可能不应该创建此内容。在 Alpha 期间，这是运行时服务帐户，很可能没有清理。
- 我有一种感觉，它被卡在
Editor，因为它访问了云存储，而云存储因"非Editor访问"而奇怪地损坏了(我仍在尝试追踪确切的问题，但看起来与需要它的旧Editor角色有联系)。 - 从它的角度来看，它已经是"最低特权"，因为它只有权限执行 Run 需要执行的操作，以便代表你设置资源。
- 这是等效于 Cloud Build 的运行时服务帐户，与 1,2 属于同一类别。如果需要将构建部署到 Cloud Run，则必须授予此帐户类似
Cloud Run Deployer的权限(以及允许构建服务帐户充当运行时服务帐户的额外步骤，以防止 [或至少确认] 权限提升)。
我也希望更好地过滤"谷歌创建"和"谷歌管理"，并且一直在与Cloud IAM团队讨论这个问题。