Какие предопределенные роли IAM необходимы учетной записи службы для выполнения быстрого запуска Google Cloud Run: сборка и развертывание?

Я хочу сравнить Google Cloud Run с функциями Google App Engine и Google Cloud. Быстрый запуск Cloud Run : создание и развертывание - хорошая отправная точка.

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

Вопрос:

Какой наименее привилегированный набор предопределенных ролей я могу назначить учетной записи службы, которая должна выполнять эти команды без ошибок:

gcloud builds submit --tag gcr.io/{PROJECT-ID}/helloworld
gcloud beta run deploy --image gcr.io/{PROJECT-ID}/helloworld

Первая команда завершается с ошибкой (кажущейся ложной) при запуске через учетную запись службы с двумя ролями: Cloud Build Service Account а также Cloud Run Admin, Я не выполнил вторую команду.

Редактировать: ошибка не ложная. Команда строит образ и копирует его в реестр контейнера проекта, а затем не может распечатать журнал сборки на консоль (недостаточно прав).

Изменить: я выполнил вторую команду. Это не с Permission 'iam.serviceaccounts.actAs' denied on {service-account}, Я мог бы решить эту проблему, назначив Service Account User роль. Но это позволяет команде deploy выступать в качестве учетной записи службы времени выполнения проекта, которая имеет Editor роль по умолчанию. Создание учетной записи службы с (эффективно) обоими Viewer а также Editor Роли не намного лучше, чем использование моих учетных данных по умолчанию.

Поэтому я должен изменить разрешения учетной записи службы времени выполнения. Cloud Run Документы службы идентификации имеют это, чтобы сказать о конфигурации с наименее привилегированным доступом:

Это изменяет разрешения для всех служб в проекте, а также для экземпляров Compute Engine и Google Kubernetes Engine. Поэтому минимальный набор разрешений должен содержать разрешения, необходимые для Cloud Run, Compute Engine и Google Kubernetes Engine в проекте.

К сожалению, в документах не указано, что это за разрешения или какой набор предопределенных ролей покрывает их.

Что я сделал до сих пор:

  1. Используйте консоль разработчика для создания нового проекта GCP
  2. Используйте консоль разработчика для создания новой учетной записи службы с Cloud Run Admin роль
  3. Используйте консоль разработчика для создания (и загрузки) ключа для учетной записи службы
  4. Создать (и активировать) gcloud конфигурация для проекта
$ gcloud config list
[core]
account = {service-account-name}@{project-id}.iam.gserviceaccount.com
disable_usage_reporting = True
project = {project-id}
[run]
region = us-central1
  1. Активируйте учетную запись службы, используя загруженный ключ
  2. Используйте консоль разработчика, чтобы включить Cloud Run API
  3. Используйте консоль разработчика, чтобы включить Container RegistrySettingsContainer Analysis API
  4. Создать образец приложения и Dockerfile в соответствии с инструкцией по быстрому старту
  5. Бежать gcloud builds submit --tag gcr.io/[PROJECT-ID]/helloworld
    ... происходит сбой из-за отсутствия прав на сборку в облаке
  6. Добавить Cloud Build Editor роль для обслуживания учетной записи и повторной отправки сборки
    ... происходит сбой из-за отсутствия разрешений на хранение. Я не обращал пристального внимания на то, что пропало.
  7. Добавить Storage Object Admin роль для обслуживания учетной записи и повторной отправки сборки
    ... происходит сбой из-за отсутствия разрешений для хранилища
  8. Заменить сервисный аккаунт Storage Object Admin роль с Storage Admin Ролевая и повторная сборка
    ... терпит неудачу с
Error: (gcloud.builds.submit) HTTPError 403:
<?xml version='1.0' encoding='UTF-8'?>
<Error>
<Code>AccessDenied</Code>
<Message>Access denied.</Message>
<Details>
{service-account-name} does not have storage.objects.get access to
{number}.cloudbuild-logs.googleusercontent.com/log-{uuid}.txt.</Details>
</Error>
  1. Изучите набор доступных ролей и автоматически созданные учетные записи служб проекта. Поймите, что Cloud Build Service Account Роль имеет гораздо больше разрешений, что Cloud Build Editor, Это удивило меня; наследие Editor Роль имеет "Редактировать доступ ко всем ресурсам".
  2. Удалить Cloud Build Editor а также Storage Admin роли из учетной записи службы
  3. Добавить Cloud Build Service Account роль для обслуживания учетной записи и повторной отправки сборки
    ... терпит неудачу с тем же HTTP 403 ошибка (отсутствует доступ к файлу журнала)
  4. Проверьте Cloud BuildHistory в консоли разработчика; найти успешные сборки!
  5. Проверьте Container RegistryImages в консоли разработчика; найти изображения!

На данный момент, я думаю, я мог бы закончить Быстрый запуск Google Cloud Run : Построение и Развертывание. Но я не хочу продолжать (на первый взгляд поддельные) сообщения об ошибках в процессе сборки.

2 ответа

Решение

Cloud Run PM здесь:

Мы можем разбить это на два набора необходимых разрешений:

# build a container image
gcloud builds submit --tag gcr.io/{PROJECT_ID}/helloworld

Тебе понадобиться:

  1. Cloud Build Editor а также Cloud Build Viewer (согласно @wlhee)
# deploy a container image
gcloud beta run deploy --image gcr.io/{PROJECT_ID}/helloworld

Вам нужно сделать две вещи:

  1. Предоставьте свой сервисный аккаунт Cloud Run Deployer роль (если вы хотите изменить политику IAM, скажем, для публичного развертывания службы, вам потребуется Cloud Run Admin).
  2. Следуйте дополнительным инструкциям по развертыванию, чтобы предоставить этой учетной записи службы возможность развертывания вашей учетной записи службы.
#1
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="serviceAccount:{service-account-name}@{project-id}.iam.gserviceaccount.com" \
  --role="roles/run.developer"

#2
gcloud iam service-accounts add-iam-policy-binding \
  PROJECT_NUMBER-compute@developer.gserviceaccount.com \
  --member="serviceAccount:{service-account-name}@{project-id}.iam.gserviceaccount.com" \
  --role="roles/iam.serviceAccountUser"

РЕДАКТИРОВАТЬ: Как уже отмечалось, последний дает вашей учетной записи службы возможность actAs учетная запись службы времени выполнения. То, какую роль играет эта служебная учетная запись, зависит от того, к чему она должна получить доступ: если единственная вещь, к которой Run/GKE/GCE обращается, - это GCS, то дайте ей что-то вроде Storage Object Viewer вместо редактора. Мы также работаем над идентификаторами для каждой службы, поэтому вы можете создать учетную запись службы и "переопределить" значение по умолчанию с помощью чего-то с наименьшими привилегиями.

Согласно https://cloud.google.com/cloud-build/docs/securing-builds/set-service-account-permissions

"Учетная запись службы Cloud Build" - Cloud Build выполняет ваши сборки, используя служебную учетную запись, специальную учетную запись Google, которая выполняет сборки от вашего имени.

Для вызова сборок gcloud отправьте --tag gcr.io/path

Изменить: Пожалуйста, "Редактор сборки Cloud" и "Просмотр" вашей учетной записи службы, которая запускает сборку, это из-за текущей модели авторизации Cloud Build.

Приносим извинения за неудобства.

Другие вопросы по тегам