Невозможно перечислить учетные записи служб на новой виртуальной машине GCE

Я создал новую виртуальную машину в проекте вычислительного движка Google. Я изменил область доступа Compute Engine на чтение и запись после создания виртуальной машины.

На существующей (долго работающей) ВМ, если я сделаю:

gcloud iam service-accounts list

Я вижу учетную запись службы по умолчанию для проекта.

Однако, если я делаю то же самое на только что созданной виртуальной машине, я получаю сообщение об ошибке:

  gcloud iam service-accounts list
ERROR: (gcloud.iam.service-accounts.list) User [<service-account>] does not have permission to access projects instance [<project>] (or it may not exist): Request had insufficient authentication scopes.

Исходная виртуальная машина — это ubuntu-16, новая виртуальная машина — ubuntu-18, только что созданная из образа Google.

Если я смотрю на роли IAM проекта, у моего пользователя есть следующие роли:

 - Access Approval Config Editor
 - Compute Admin
 - Role Viewer
 - Service Account Admin
 - Owner
 - Organization Administrator

Что мне не хватает? Области доступа для двух виртуальных машин одинаковы:

 - Compute Engine               Read Write
 - Service Control              Enabled
 - Service Management           Read Only
 - Stackdriver Logging API      Write Only
 - Stackdriver Monitoring API   Write Only
 - Stackdriver Trace            Write Only
 - Storage                      Read Only

Что контролирует доступ для отдельных виртуальных машин, кроме областей доступа?


list permissions google-compute-engine google-cloud-iam roles
person Gary Aitken    schedule 28.11.2020    source источник

Ответы (2)


arrow_upward
0
arrow_downward

Проблема заключалась в том, что окно SSH работало под учетной записью службы, а не под моей обычной учетной записью пользователя. мне нужно было бежать

gcloud init

перенастроить на использование моей обычной учетной записи.

Я обнаружил это, выполнив

gcloud config list

на обеих машинах.

person Gary Aitken    schedule 28.11.2020

arrow_upward
0
arrow_downward

ЧАСТЬ 1

Что контролирует доступ для отдельных виртуальных машин, кроме областей доступа?

Объединение областей Compute Engine и разрешений сервисного аккаунта.

Области Google Compute Engine ограничивают разрешения, области не предоставляют разрешения.

Учетная запись службы, назначенная Compute Engine, определяет доступные разрешения/роли. Области действия могут ограничивать разрешения, предоставленные учетной записи службы. Области не могут предоставлять разрешения, которых еще нет у учетной записи службы.

Области — это устаревший механизм авторизации.

ЧАСТЬ 2

gcloud iam service-accounts list ОШИБКА: (gcloud.iam.service-accounts.list) Пользователь [] не имеет разрешения на доступ к экземпляру проекта [] (или он может не существовать): в запросе недостаточно областей проверки подлинности.

Часть этого сообщения сбивает с толку большинство людей. Scopes — это устаревший механизм аутентификации, который Google использовал до IAM. Области аналогичны разрешениям и в этом сообщении означают OAuth 2 Permissions.

Для команды gcloud iam service-accounts list требуется разрешение iam.serviceAccounts.list, которое присутствует в таких ролях, как roles/iam.serviceAccountUser с именем Service Account User. Учетная запись службы, упомянутая в ошибке, не имеет ни одной из ролей, предоставляющих разрешение на перечисление учетных записей служб, или Области ограничивают разрешение, предоставленное учетной записи службы. Прочтите мою рекомендацию в конце.

Роли сервисного аккаунта

Часть 3

Если я смотрю на роли IAM проекта, у моего пользователя есть следующие роли:

Роли, назначенные пользователю, не связаны с ролями, назначенными сервисной учетной записи Compute Engine.

Если вы вошли в Compute Engine с помощью SSH и ничего не сделали для аутентификации, значит, вы используете учетные данные служебной учетной записи Compute Engine по умолчанию. Учетная запись службы и области действия влияют на ваши разрешения.

Если вы вошли в Compute Engine с помощью SSH и используете свою собственную учетную запись для аутентификации (gcloud auth login или аналогичную), то ваше удостоверение пользователя использует разрешения, предоставленные вашей учетной записи пользователя, а не учетные данные учетной записи службы Compute Engine по умолчанию.

Часть 4

Исходная виртуальная машина — это ubuntu-16, новая виртуальная машина — ubuntu-18, только что созданная из образа Google.

Если области одинаковы для обеих виртуальных машин, проблема заключается в служебной учетной записи. Обычно виртуальные машины Compute Engine используют учетную запись службы Compute Engine по умолчанию. Вы можете изменить учетную запись службы, назначенную каждой виртуальной машине. Дважды проверьте, что назначено каждой виртуальной машине.

Сводка

Я рекомендую вам установить области на Allow full access to all Cloud APIs и управлять разрешениями с помощью ролей, предоставленных учетной записи службы. Не используйте такие роли, как Project Owner или Project Editor. Эти роли очень сильные. Используйте детальные разрешения для каждой службы Google Cloud, к которой Compute Engine должен получить доступ.

person John Hanley    schedule 28.11.2020
comment
Спасибо, очень полезное объяснение того, как все работает. Поскольку я вошел в систему как сам, чтобы создать виртуальную машину на console.cloud.google.com/compute, я подумал, что нажатие кнопки SSH на новой виртуальной машине откроет сеанс SSH от моего имени, но это не так. Разумно, но контринтуитивно. - person Gary Aitken; 30.11.2020
comment
@GaryAitken При нажатии кнопки SSH в Google Cloud Console используется идентификатор пользователя вашего веб-браузера для подключения к виртуальной машине с использованием SSH и ничего более. Это не влияет на учетные данные, используемые после входа в систему. После входа в систему по SSH вы принимаете идентификатор Compute Engine. Затем вы можете изменить это с помощью gcloud auth login, чтобы получить новые учетные данные. - person John Hanley; 30.11.2020