无法使用服务帐号创建 Dataproc 集群

Unable to create a Dataproc cluster with service account

我是 Google 云的新手,正在评估 Dataproc 集群,核心要求之一是动态创建集群并处理作业。对于各种文档阅读和 ,我尝试创建一个服务帐户并添加以 "Dataproc Editor".

开头的角色

我生成了密钥文件并激活了服务帐户

gcloud auth activate-service-account --key-file=<Key File>

并尝试创建集群

gcloud beta dataproc clusters create jill-cluster \
    --enable-component-gateway \
    --subnet default \
    --zone europe-west3-b \
    --region europe-west3 \
    --master-machine-type n1-standard-4 \
    --master-boot-disk-size 50 \
    --num-workers 2 \
    --worker-machine-type n1-standard-4 \
    --worker-boot-disk-type pd-ssd \
    --worker-boot-disk-size 100 \
    --image https://compute.googleapis.com/compute/v1/projects/poc/global/images/poc-1-5-1-debina10 \
    --scopes 'https://www.googleapis.com/auth/cloud-platform' \
    --project poc \
    --verbosity info \
    --autoscaling-policy=poc-auto-scale-policy \
    --service-account=<Service account>

我遇到了这个错误

{
    "code": 403,
    "message": "Not authorized to requested resource.",
    "status": "PERMISSION_DENIED"
}

我开始向服务帐户添加更多角色,结果如下所示 ,但仍然无法创建集群。我不太确定我错过了什么。我尝试了命令行以及结果相同的编程方法。不幸的是,我也无法从日志记录中获得足够的线索。

------------更新-------------

我想我在最初的问题中遗漏了一些信息。我有一个具有所有者角色的用户帐户,目前正在使用该帐户进行试验并使用它我可以创建集群并提交作业。所以我认为该项目具有必要的角色。

现在想走向自动化,想实现

  1. 使用服务帐户管理集群
  2. 应该能够提交和 运行 作业并管理作业。

我从一个帐户开始承担这两项职责,但按照建议,我可以开始使用不同的服务帐户。

由于这里有各种相关的功能,例如为集群的身份指定自定义服务帐户和使用自定义图像,可以执行一些步骤来缩小主要问题的范围:

  1. 检查 任何 访问控制 API 调用是否适用于具有广泛权限的服务帐户,例如 Project Viewer,并尝试 gcloud compute instances listgcloud compute regions listgcloud dataproc clusters list - 如果是有关 Dataproc 特定角色的内容,或者如果服务帐户本身由于某种原因无法正常工作,这将缩小范围。
  2. 如果它似乎适用于其他 API 但不适用于 Dataproc API,请尝试使用 Policy Troubleshooter tool 工具,直到您可以使用基本的 "viewer" 类型的请求使用 Dataproc API
  3. 如果可以创建 "default" Dataproc 集群,但使用自定义选项的集群失败,您可能需要添加额外的权限,例如 Service Account User 用于指定的集群身份服务帐户,Compute Network User 用于跨项目网络,Compute Image User 用于跨项目自定义图像,或 Storage Object Creator 用于跨项目或自定义 GCS 配置桶。通常,与 #1 中描述的基本 "front-door" 访问错误相比,这些类型的权限错误预计会提供来自 Dataproc API 的详细错误消息,后者可能包含您看到的更通用的错误消息("Not authorized to requested resource").

其他需要检查的事项包括确保您将角色成员资格应用于正确的资源(在本例中为项目本身),而不是服务帐户,因为该角色列表应包含您需要的一切。检查:

gcloud projects get-iam-policy $PROJECT

确保您的所有这些角色的列表实际出现在那里 members: 列出您的服务帐户。您应该 期望 Dataproc Editor 等内容出现在服务帐户的资源策略本身中,如:

gcloud iam service-accounts get-iam-policy $SERVICE_ACCOUNT

应该 return 一个只有 etag: 字段的空响应。

使用自定义服务帐户时,了解所涉及的不同角色之间的区别也很重要。

首先要澄清的一件事是 Dataproc "worker" 和 Dataproc creator/user 通常不是同一身份,尽管它们可能是同一身份。因此,如果您打算将服务帐户用于 create Dataproc 集群,Dataproc Editor 是正确的,但如果您还打算让集群本身采用服务帐户,您还需要为服务帐户授予 Dataproc Worker 角色:https://cloud.google.com/dataproc/docs/concepts/iam/dataproc-principals

在这种情况下,如果您尝试使用服务帐户创建集群然后充当指定的服务帐户,即使指定的帐户是 "itself",您也需要授予 Service Account User 角色到您的服务帐户,在项目级别(如果您可以在项目中授予它广泛的 actAs 权限)或仅在单个服务帐户上。

由于您似乎在使用自定义图像,假设您遵循了 creating a Dataproc custom image you may also have to grant your service account the Compute Image User role 的高级说明。

除此之外,如果在其他项目中使用图像,您可能需要检查表格 service-[project-number]@dataproc-accounts.iam.gserviceaccount.com 的服务帐户,如果您的项目是在 2019 年 9 月之前创建的,那么遗留 [project-number]@cloudservices.gserviceaccount.com 服务帐号。这些将需要在图像或包含这些图像的项目上被授予 Compute Image user role。对于同一项目的图像,现有 Dataproc Service Agent 角色 应该 已经包含包含图像用户角色的 instanceAdmin 权限。