добавление существующей учетной записи службы GCP в модуль Terraform root для облачной сборки для создания конфигурации Terraform - PullRequest
Новая
       81

добавление существующей учетной записи службы GCP в модуль Terraform root для облачной сборки для создания конфигурации Terraform

0 голосов
/ 14 февраля 2020

enter image description here Спросите сообщество, возможно ли сделать следующее. (не удалось найти дополнительную информацию)

Я создаю конвейер ci / cd с помощью Github / cloudbuild / Terraform. У меня есть конфигурация Terraform сборки buildbull по запросу github pull и слияние с новой веткой Однако у меня есть учетная запись службы Cloudbuild (по умолчанию) с наименьшими привилегиями. Вопрос придерживается, я хотел бы, чтобы terraform получал разрешение от существующей учетной записи службы с наименьшими привилегиями для предотвращения любых эксплойтов, и т. Д. c. как только cloudbuild получит триггеры pull build для инициализации конфигурации terraform. В это время, т.е. terraform будет извлекать существующую внешнюю SA для получения разрешения на создание TF. Я попытался использовать служебную учетную запись и привязать роли к этой служебной учетной записи, но произошла ошибка, которая указывает, что учетная запись службы уже существует. Следующим шагом для меня будет использование модуля, но я думаю, что это также создаст новый SA с реплицированными ролями. Если это сбивает с толку, я прошу прощения, я помогу в уточнении вопроса, чтобы быть более кратким.

1 Ответ

1 голос
/ 19 февраля 2020

У вас есть 2 решения:

  1. Используйте учетную запись службы Cloud Build при запуске вашей Terraform. Ваш провайдер выглядит следующим образом: 
provider "google" {
//  Useless with Cloud Build
//  credentials = file("${var.CREDENTIAL_FILE}}")
  project = var.PROJECT_ID
  region = "europe-west1"
}

Но это решение подразумевает предоставление нескольких ролей Cloud Build только для процесса Terraform. Пользовательская роль - хороший выбор для предоставления только того, что требуется.

Вторым решением является использование файла ключа учетной записи службы. Здесь снова 2 решения:

  • Cloud Build создает учетную запись службы, предоставляет всю роль для нее, генерирует ключ и передает его в terraform. После выполнения terraform учетная запись службы удаляется Cloud Build. Хорошее решение, но вы должны предоставить учетной записи службы Cloud Build возможность назначать себе любые роли и генерировать файл json Key. Это большая ответственность!
  • Использовать существующую учетную запись службы и сгенерированный на ней ключ. Но вы должны закрепить ключ и регулярно поворачивать его. Я рекомендую вам надежно хранить его в секретном менеджере , но для ротации вы должны сами управлять им сегодня. С помощью этого процесса Cloud Build загрузите ключ (в секретном менеджере) и передайте его в terraform. И здесь учетная запись службы Cloud Build имеет право доступа к секретам, что является критически важной привилегией. Шаг в Cloud Build выглядит примерно так: 
steps:
        - name: gcr.io/cloud-builders/gcloud:latest
          entrypoint: "bash"
          args:
                  - "-c"
                  - |
                      gcloud beta secrets versions access --secret=test-secret latest > my-secret-file.txt
...