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

#list #permissions #google-compute-engine #roles #google-cloud-iam

# #Список #разрешения #google-compute-engine #роли #google-cloud-iam

Вопрос:

Я создал новую виртуальную машину в проекте 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
 

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

Ответ №1:

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

 gcloud init
 

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

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

 gcloud config list
 

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

Ответ №2:

ЧАСТЬ 1

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

Объединение областей вычислительного ядра и разрешений учетной записи службы.

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

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

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

ЧАСТЬ 2

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

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

Для выполнения команды gcloud iam service-accounts list требуется разрешение iam.serviceAccounts.list , которое присутствует в таких ролях, как roles/iam.serviceAccountUser named 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, к которой требуется доступ Compute Engine.

Комментарии:

1. Спасибо, очень полезное объяснение того, как все работает. Поскольку я вошел в систему как я, чтобы создать виртуальную машину на console.cloud.google.com/compute Я бы подумал, что нажатие кнопки SSH на новой виртуальной машине откроет сеанс SSH от моего имени, но это не так. Разумно, но нелогично.

2. @GaryAitken Нажатие кнопки SSH Google Cloud Console использует идентификатор пользователя вашего веб-браузера для подключения к виртуальной машине с использованием SSH и ничего более. Это не влияет на учетные данные, используемые при входе в систему. После входа в систему по SSH вы принимаете идентификатор Compute Engine. Затем вы можете изменить это, gcloud auth login чтобы получить новые учетные данные.