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

Question

启用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-managed service accounts“ Google Container Registry Service Agent（Editor角色）和Google Cloud Run Service Agent（Cloud Run Service Agent角色）“用于访问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 PM：

1. 是的，完全正确。
2. 如果您仅使用运行（并且可能不启用创建此功能的App Engine API），则可能不应该创建此功能。在Alpha期间，这是运行时服务帐户，很可能没有清理。
3. 我有种感觉{@ 1}被卡住了，因为它访问了Cloud Storage，这对于“非Editor访问”来说是很奇怪的（我仍在尝试找出确切的问题，但是似乎与需要它的旧版Editor角色存在联系。
4. 从它的角度来看，它已经是“最低特权”，因为它仅具有执行Run所需的权限以代表您设置资源的权限。
5. 这是等效于Cloud Build的运行时服务帐户，并且属于1,2。如果您需要将构建部署到Cloud Run，则必须授予该帐户类似Editor的权限（另外还有一个步骤，即允许构建服务帐户充当您的运行时服务帐户，以防止[或至少确认]特权升级。

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