Google Cloud Build – доступ к секретам другого проекта во время сборки
В моем проекте есть настройка сборки для производства и разработки в проекте сборки облака GCP. Это отдельные проекты с отдельными секретами. Обычно мы хотим, чтобы prod использовал только секреты prod, а dev — секреты разработчика.
Однако нам бы хотелось, чтобы модульные тесты выполнялись как для продукта, так и для разработки, и чтобы сборка не завершилась в случае сбоя. Модульные тесты всегда используют секреты среды разработки.
Есть ли способ предоставить учетной записи службы облачной сборки производственных сред доступ к секретам среды разработки?
Вот что я пытался сделать:
availableSecrets:
secretManager:
- versionName: projects/$PROJECT_ID/secrets/github_token/versions/latest
env: 'GITHUB_TOKEN'
- versionName: projects/617239722448/secrets/gpapi-gcr-env-dev/versions/latest
env: 'DEV_TEST_ENV'
и используйте $$DEV_TEST_ENV в строфе, чтобы записать секреты в файл .env.test, который используют тесты (используется secretEnv: ['DEV_TEST_ENV'] в строфе).
Это приводит к ошибке, указывающей, что конкретная учетная запись службы не имела доступа к секретам среды разработки сразу после запуска сборки (даже не выполняла никаких шагов).
Итак, я попробовал следовать этим инструкциям, чтобы предоставить сервисной учетной записи из-за ошибки доступ к секретам разработчика. Кажется, это не работает. Я заметил в IAM, что для этой учетной записи службы в проекте разработки, когда я предоставил доступ, не указана информация о безопасности (в отличие от учетной записи prod, где эта учетная запись показывает информацию)... см. снимок экрана ниже, чтобы понять, что я имею в виду. Это заставляет меня думать, что на самом деле это не предоставление доступа.
Есть идеи, как заставить это работать?
Как мне дать указание облачной сборке использовать эту учетную запись службы для сборки?
Обратитесь к этому официальному документу GCP для настройки доступа к учетной записи службы Cloud Build.
Я понял это. Спасибо @Капил Схаре. Я начал создавать новую учетную запись службы и при этом заметил, что фактически предоставил доступ к учетной записи службы COMPUTE по умолчанию в разработке, а не к облачной сборке. Они так близки по названию. Облачная сборка не отображается по умолчанию. Отображается только после установки флажка «Включить предоставление ролей от Google».
Ответы 1
Это была моя собственная глупость. Имена субъектов учетных записей служб очень близки по именам. Я вставил субъект учетной записи вычислительной службы в свой проект разработки. Учетная запись службы Cloudbuild отображается в списке только тогда, когда вы устанавливаете флажок Include Google-provided role grants, как показано ниже. Вычислительный вариант появился в списке первым и на первый взгляд выглядел так же, как принцип учетной записи службы облачной сборки.
После добавления ПРАВИЛЬНОЙ сервисной учетной записи в проект dev IAM и предоставления ей роли Secret Manager Secret Accessor все работает.
Попробуйте использовать новую учетную запись службы для обоих проектов вместо учетной записи службы облачной сборки по умолчанию; это может решить вашу проблему. Также убедитесь, что обе новые учетные записи службы имеют роль секретного доступа диспетчера секретов.