Вопрос или проблема
Я новенький в Google Cloud Platform и настроил учетную запись службы, которую использую для того, чтобы разрешить Terraform настраивать некоторые сервисы через рабочий процесс GitHub Actions. Кажется, что все завязано между моими учетными записями GitHub и GCP, поскольку я могу запускать Terraform init и plan из своего рабочего процесса, и я вижу, что создаются файлы состояния в ведре для хранения GCP, которое я создал вручную. Однако шаг apply (который просто пытается создать еще одно ведро для хранения) завершается неудачей с следующей ошибкой:
Ошибка: googleapi: Ошибка 403: У звонившего нет доступа storage.buckets.create к проекту Google Cloud. Разрешение 'storage.buckets.create' отклонено для ресурса (или он может не существовать)., запрещено
Когда я проверяю вкладку IAM в веб-консоли (IAM & Admin), я вижу, что принципал учетной записи службы, используемый Terraform, имеет роли ‘Storage Admin’, ‘Service Account Token Creator’ и ‘Service Account User’.
Однако, когда я проверяю тот же принципал на вкладке Учетные записи службы, он показывает только роли ‘Service Account Token Creator’ и ‘Service Account User’. Я также не могу добавить ‘Storage Admin’ отсюда.
Я ожидал, что принципал учетной записи службы будет иметь одни и те же роли, независимо от того, в какой таблице я его просматриваю, или что я смогу прикрепить необходимую роль к нему, чтобы решить вышеупомянутую ошибку. Показывают ли действительно эти панели управления разные данные, и если да, то как я могу предоставить роль ‘Storage Admin’ своей учетной записи службы, чтобы разрешить Terraform использовать ее для создания нового ведра для хранения?
Это хороший вопрос из-за двойственности учетной записи службы.
Учетная запись службы — это идентичность, техническая учетная запись. На странице IAM вы можете использовать электронную почту учетной записи службы, как любую другую электронную почту пользователя, чтобы предоставить учетной записи службы доступ к таким сервисам, как Cloud Storage, BigQuery и другим.
Когда вы используете страницу IAM, вы предоставляете разрешение на уровне проекта. Ресурс — это проект. Вы можете перейти к некоторым сервисам, таким как Cloud Storage или BigQuery, и у вас также есть вкладка разрешений для предоставления идентичностей (пользователей/учетных записей служб) на уровне ресурса, ведра, набора данных или таблицы.
Я упоминаю уровень “ресурса”, потому что здесь возникает двойственность учетной записи службы. Учетная запись службы также является ресурсом, и вы можете предоставить разрешение на нее на вкладке разрешений в учетной записи службы.
Хорошо, это немного тревожно. Я не знаю, почему возможно предоставить так много ролей учетной записи службы. Я обычно использую 2: ‘Service Account User’ и ‘Service Account Token Creator’.
Эти 2 роли позволяют вам создавать имитацию учетной записи службы. Представим себе следующее: как пользователь, я мог бы имитировать только одну учетную запись службы, а не ВСЕ учетные записи служб проекта.
В этом случае ваша электронная почта пользователя не должна быть предоставлена на странице IAM, потому что это уровень ресурсов проекта, а только на самой специализированной учетной записи службы, то есть на уровне ресурса учетной записи службы; вкладка разрешений на странице вашей учетной записи службы.
И да, однажды вы столкнетесь с этой абсурдной ситуацией, когда вам придется предоставить учетной записи службы (то есть электронной почте, идентичности) доступ к самой себе (то есть ресурсу) как Service Account Token Creator, чтобы, например, она могла сгенерировать токен идентичности (необходимый для вызова Cloud Run или Cloud Function) на Composer 3 (я сделал это на прошлой неделе!)
Ответ или решение
Почему существует несоответствие между ролями в IAM и Сервисных учетных записях Google Cloud Platform
Когда вы работаете с Google Cloud Platform (GCP) и используете сервисные учетные записи (Service Accounts) для автоматизации процессов, таких как развертывание сервисов с помощью Terraform, важно понимать механизм управления доступом и то, как роли применяются к учетным записям. Ваша ситуация, связанная с ошибкой доступа к созданию хранения (storage.buckets.create), и наблюдаемое несоответствие между IAM и Сервисными учетными записями — это распространенная проблема, которая требует детального разъяснения.
Понимание IAM и Сервисных учетных записей
В GCP IAM (Identity and Access Management) используется для управления доступом к ресурсам вашего проекта. Сервисные учетные записи представляют собой уникальные учетные записи, созданные для автоматизации и выполнения задач. Это вызывает путаницу, когда вы проверяете роли, потому что IAM и Сервисные учетные записи представляют собой разные уровни управления доступом.
-
IAM: Вкладка IAM в консоли GCP позволяет назначать роли на уровне проекта. Здесь вы можете предоставить вашей сервисной учетной записи, такой как ‘Storage Admin’, доступ к созданиям определенных ресурсов, например, ведро объектов (storage bucket) в вашем проекте.
-
Сервисные учетные записи: На вкладке "Service Accounts" отображаются роли, которые были назначены непосредственно сервисной учетной записи как ресурсу. Эти роли, такие как ‘Service Account Token Creator’ и ‘Service Account User’, позволяют пользователю или сервисной учетной записи взаимодействовать с учетной записью.
В вашем случае, сервисная учетная запись успешно имеет роли ‘Service Account Token Creator’ и ‘Service Account User’ в контексте самих сервисных учетных записей, но ее роль ‘Storage Admin’ не отображается, поскольку эта роль относится к проекту, а не к самой учетной записи.
Как назначить роли
Для решения вашей проблемы необходимо убедиться, что ваша сервисная учетная запись обладает необходимыми правами на уровне проекта для создания новых хранилищ:
-
Назначение роли ‘Storage Admin’:
- Перейдите на вкладку IAM в консоли GCP.
- Найдите вашу сервисную учетную запись.
- Нажмите "Редактировать" (Edit).
- В разделе "Добавить роль" (Add Role) выберите ‘Storage Admin’.
- Сохраните изменения.
-
Проверка уровня доступа:
- Убедитесь, что ваш Terraform настроен на использование правильной сервисной учетной записи. Убедитесь, что переменные среды или конфигурационные файлы Terraform не ссылаются на другую учетную запись.
- Убедитесь, что проект, в который вы пытаетесь создать ведро, действительно та же GCP-проект, для которой была назначена роль ‘Storage Admin’.
Заключение
Несоответствие между ролями в IAM и Сервисных учетных записях — это результат того, что IAM предоставляет доступ на уровне проекта, в то время как вкладка "Сервисные учетные записи" управляет доступом на уровне самой учетной записи. Данное понимание поможет вам более эффективно управлять доступом в GCP и устранить ошибки, вызванные недостатком разрешений.
Если после этих шагов ваша проблема не решена, проверьте настройки вашей Terraform конфигурации и используемую аутентификацию, чтобы убедиться, что все компоненты взаимодействуют корректно.