启用 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 …
我想将 Google Cloud Run 与 Google App Engine 和 Google Cloud Functions 进行比较。Cloud Run快速入门：构建和部署似乎是一个很好的起点。
我的应用程序默认凭据太广泛，无法在开发过程中使用。我想使用一个服务帐户，但我很难配置一个可以毫无错误地完成快速入门的帐户。
我可以分配给必须执行这些命令而不会出错的服务帐户的最低权限的预定义角色集是什么：
gcloud builds submit --tag gcr.io/{PROJECT-ID}/helloworld
gcloud beta run deploy --image gcr.io/{PROJECT-ID}/helloworld
当通过具有两个角色的服务帐户运行时，第一个命令失败并出现（看似虚假的）错误：Cloud Build Service Account和Cloud Run Admin。我还没有运行第二个命令。
编辑：错误不是虚假的。该命令构建映像并将其复制到项目的容器注册表，然后无法将构建日志打印到控制台（权限不足）。
编辑：我运行了第二个命令。它失败了Permission 'iam.serviceaccounts.actAs' denied on {service-account}。我可以通过分配Service Account User角色来解决这个问题。但这允许 deploy 命令充当项目的运行时服务帐户，默认情况下该帐户具有该Editor角色。使用（有效地）和ViewerEditor角色并不比使用我的应用程序默认凭据好多少。
所以我应该更改运行时服务帐户权限。该Cloud Run 服务标识的文档都这样说最少特权的访问配置：
这会更改项目中所有服务以及 Compute Engine 和 Google Kubernetes Engine 实例的权限。因此，最小权限集必须包含项目中 Cloud Run、Compute Engine 和 Google Kubernetes …