Ошибка при создании кластера GCP Datapro c: в «compute.projects.get» отказано в разрешении - PullRequest
1 голос
/ 25 января 2020

пытаюсь создать кластер Datapro c с учетной записью службы через облачный sdk. Выдает ошибку, что compute.projects.get запрещен. Учетная запись службы имеет доступ к средству просмотра вычислений, администратору экземпляров вычислений, редактору datapro c. Невозможно понять, почему эта ошибка. В инструменте устранения неполадок политики IAM я проверил dataproc.cluster.create, назначенный учетной записи службы

Команда:

gcloud dataproc clusters create cluster-dqm01 \
  --region europe-west-2 \
  --zone europe-west2-b \
  --subnet dataproc-standalone-paasonly-europe-west2 \
  --master-machine-typne n1-standard-4 \
  --master-boot-disk-size 500 \
  --num-workers 2 \
  --worker-machine-type n1-standard-4 \
  --worker-boot-disk-size 500 \
  --image-version 1.3-deb9 \
  --project xxxxxx \
  --service-account xxxx.iam.gserviceaccount.com

ОШИБКА: (gcloud.datapro c .clusters .create) PERMISSION_DENIED: Обязательные права 'compute.projects.get' для 'projects / xxxxxx'

Проект правильный, так как я пытался создать из консоли ошибку, сгенерированную, сгенерировал gcloud Команда из консоли для запуска с учетной записью службы. Впервые кластер datapro c создается для проекта

1 Ответ

1 голос
/ 25 января 2020

Если вы присвоили различные разрешения одной и той же учетной записи службы, которую вы указали с помощью --service-account, проблема заключается в том, что вы, вероятно, хотели указать - impersonate-service-account .

Здесь есть три идентификатора, которые имеют отношение к данному вопросу:

  1. Идентификатор, выполняющий команду CreateCluster - это часто человеческая идентификация, но если вы автоматизируете вещи, используя --impersonate-service-account или при запуске команды из другой виртуальной машины GCE, это может быть сама учетная запись службы.
  2. Идентификатор «Уровень управления» - это то, что серверная служба Datapro c использует для фактического создания виртуальных машин

Как правило, # 1 и # 2 нужны различные разрешения на «вычисления» и некоторые минимальные GCS разрешения. # 3 обычно требуется только GCS и опционально BigQuery, Cloud SQL, Bigtable и др. c. разрешения в зависимости от того, что вы на самом деле обрабатываете.

См. https://cloud.google.com/dataproc/docs/concepts/iam/dataproc-principals для более подробного объяснения этих идентичностей.

В нем также перечислены ранее существующие курированные роли, чтобы все это было легко (и, как правило, настройки проекта «по умолчанию» автоматически будут иметь правильные роли, так что вам не придется об этом беспокоиться). По сути, «человеческая идентификация» или учетная запись службы, которую вы используете с --impersonate-service-account, нуждается в Dataproc Editor или Project Editor ролях, «идентификация плоскости управления» требует Dataproc Service Agent, а «идентификация плоскости данных» требует Dataproc Worker.

...