Question

我想将Google Cloud Run与Google App Engine和Google Cloud Functions进行比较。 Cloud Run Quickstart: Build and Deploy似乎是一个很好的起点。

我的应用程序默认证书太宽泛，无法在开发期间使用。我想使用一个服务帐户，但是我很难配置一个可以完成快速入门而不会出错的帐户。

问题：

我可以分配给必须执行这些命令且没有错误的服务帐户的特权最少的一组预定义角色：

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角色by default。创建一个（有效地）同时拥有Viewer和Editor角色的服务帐户并没有比使用我的“应用程序默认凭据”好得多。

因此，我应该更改运行时服务帐户权限。 Cloud Run Service Identity文档的内容是关于最低特权的访问配置：

这也会更改项目中所有服务的权限作为Compute Engine和Google Kubernetes Engine实例。因此，最小权限集必须包含所需的权限适用于云端运行，计算引擎和Google Kubernetes引擎项目。

不幸的是，文档没有说明这些权限是什么，或者没有涵盖哪些预定义角色集。

到目前为止我做了什么：

使用开发者控制台创建新的GCP项目

使用开发者控制台创建具有Cloud Run Admin角色的新服务帐户

使用开发人员控制台为服务帐户创建（并下载）密钥

为项目创建（并激活）gcloud配置

$ gcloud config list [core] account = {service-account-name}@{project-id}.iam.gserviceaccount.com disable_usage_reporting = True project = {project-id} [run] region = us-central1

使用下载的密钥激活服务帐户

使用开发者控制台启用Cloud Run API

使用开发者控制台启用Container Registry→Settings→Container Analysis API

按照快速入门文档的说明创建示例应用程序和Dockerfile

运行gcloud builds submit --tag gcr.io/[PROJECT-ID]/helloworld
...由于缺少云构建权限而失败

将Cloud Build Editor角色添加到服务帐户并重新提交构建
...由于缺少存储权限而失败。我没有仔细注意丢失的内容。

将Storage Object Admin角色添加到服务帐户并重新提交构建
...由于缺少存储存储桶权限
而失败
将服务帐户的Storage Object Admin角色替换为Storage Admin角色，然后重新提交构建
...失败

Error: (gcloud.builds.submit) HTTPError 403: <?xml version='1.0' encoding='UTF-8'?> <Error> <Code>AccessDenied</Code> <Message>Access denied.</Message> <Details> {service-account-name} does not have storage.objects.get access to {number}.cloudbuild-logs.googleusercontent.com/log-{uuid}.txt.</Details> </Error>

检查可用角色集和项目的自动创建的服务帐户。意识到Cloud Build Service Account角色比Cloud Build Editor具有更多的权限。这让我感到惊讶。旧版Editor角色具有“编辑所有资源的访问权限”。

从服务帐户中删除Cloud Build Editor和Storage Admin角色

将Cloud Build Service Account角色添加到服务帐户并重新提交构建
...由于相同的HTTP 403错误而失败（缺少对日志文件的访问权限）

在开发控制台中检查Cloud Build→History；找到成功的版本！

在开发控制台中检查Container Registry→Images；查找图片！

~~在这一点上，我认为我可以完成Google Cloud Run Quickstart: Build and Deploy。但是我不想在构建过程中继续处理（看似虚假的）错误消息。~~

Answer 1

此处的Cloud Run PM：

我们可以将其分为所需的两组权限：

# build a container image
gcloud builds submit --tag gcr.io/{PROJECT_ID}/helloworld

您需要：

Cloud Build Editor和Cloud Build Viewer（根据@wlhee）

# deploy a container image
gcloud beta run deploy --image gcr.io/{PROJECT_ID}/helloworld

您需要做两件事：

授予您的服务帐户Cloud Run Deployer角色（如果您想更改IAM策略，例如要公开部署该服务，则需要Cloud Run Admin）。
按照Additional Deployment Instructions授予该服务帐户部署您的服务帐户的权限

#1
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="serviceAccount:{service-account-name}@{project-id}.iam.gserviceaccount.com" \
  --role="roles/run.developer"

#2
gcloud iam service-accounts add-iam-policy-binding \
  PROJECT_NUMBER-compute@developer.gserviceaccount.com \
  --member="serviceAccount:{service-account-name}@{project-id}.iam.gserviceaccount.com" \
  --role="roles/iam.serviceAccountUser"

编辑：如前所述，后者授予您的服务帐户actAs运行时服务帐户的功能。该服务帐户的角色取决于其需要访问的权限：如果Run / GKE / GCE访问的唯一权限是GCS，则给它类似Storage Object Viewer的名称，而不是Editor。我们还在研究每个服务的身份，因此您可以创建一个服务帐户，并使用具有最小特权的内容“覆盖”默认帐户。

Answer 2

根据https://cloud.google.com/cloud-build/docs/securing-builds/set-service-account-permissions

“ Cloud Build服务帐户”-Cloud Build使用服务帐户执行构建，这是一个特殊的Google帐户，代表您执行构建。

为了打电话 gcloud构建提交--tag gcr.io/path

编辑：请使用“ Cloud Build编辑器”和“ Viewer”来启动构建的服务帐户，这是由于当前的Cloud Build授权模型所致。

给您带来的不便，我们深表歉意。

服务帐户需要哪些预定义的IAM角色才能完成Google Cloud Run快速入门：构建和部署？

问题：

到目前为止我做了什么：

2 个答案: