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

Я хочу сравнить Google Cloud Run с Google App Engine и Google Cloud Functions. 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. Но это позволяет команде развертывания действовать как учетная запись службы времени выполнения проекта, которая имеет роль по умолчанию. Создание служебной учетной записи с (фактически) ролями Editor и Viewer не намного лучше, чем использование моих учетных данных приложения по умолчанию.

Поэтому я должен изменить разрешения учетной записи службы времени выполнения. В документах EditorИдентификация службы говорится о конфигурации наименее привилегированного доступа:

This changes the permissions for all services in a project, as well as Compute Engine and Google Kubernetes Engine instances. Therefore, the minimum set of permissions must contain the permissions required for Cloud Run, Compute Engine, and Google Kubernetes Engine in a project.

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

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

1. Используйте консоль разработчика, чтобы создать новый проект GCP.
2. Используйте консоль разработчика, чтобы создать новую учетную запись службы с ролью Cloud Run.
3. Используйте консоль разработчика, чтобы создать (и загрузить) ключ для учетной записи службы.
4. Создайте (и активируйте) конфигурацию Cloud Run Admin для проекта

$ gcloud config list
[core]
account = {service-account-name}@{project-id}.iam.gserviceaccount.com
disable_usage_reporting = True
project = {project-id}
[run]
region = us-central1

5. Активируйте сервисный аккаунт с помощью скачанного ключа
6. Используйте консоль разработчика, чтобы включить gcloud
7. Используйте консоль разработчика, чтобы включить Cloud Run API→Container Registry→Settings
8. Создайте образец приложения и Container Analysis API в соответствии с инструкциями в документации по быстрому запуску.
9. Беги Dockerfile
   ... не удается из-за отсутствия разрешений на сборку в облаке
10. Добавьте роль gcloud builds submit --tag gcr.io/[PROJECT-ID]/helloworld в сервисный аккаунт и повторно отправьте сборку
    ... терпит неудачу из-за отсутствия разрешений на хранение. Я не обратил пристального внимания на то, что пропало.
11. Добавьте роль Cloud Build Editor в сервисный аккаунт и повторно отправьте сборку
    ...сбой из-за отсутствия прав доступа ведро к хранилищу
12. Замените роль Storage Object Admin сервисного аккаунта на роль Storage Object 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>

13. Изучите набор доступных ролей и автоматически созданные сервисные учетные записи проекта. Поймите, что роль Storage Admin имеет гораздо больше разрешений, чем роль Cloud Build Service Account. Это меня удивило; устаревшая роль Cloud Build Editor имеет «Редактировать доступ ко всем ресурсам».
14. Удалить роли Editor и Cloud Build Editor из сервисного аккаунта
15. Добавьте роль Storage Admin в сервисный аккаунт и повторно отправьте сборку
    ... не работает с той же ошибкой Cloud Build Service Account (отсутствует доступ к файлу журнала)
16. Проверьте HTTP 403→Cloud Build в консоли разработчика; найти удачные сборки!
17. Проверьте History→Container Registry в консоли разработчика; найти изображения!

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