GCP cloudbuild.yaml: kmsKeyName требует жестко закодированного значения.Как мы можем адаптироваться к отдельным средам? - PullRequest
Новая
       64

GCP cloudbuild.yaml: kmsKeyName требует жестко закодированного значения.Как мы можем адаптироваться к отдельным средам?

0 голосов
/ 27 сентября 2019

У нас есть два отдельных проекта GCP (один для разработчика и один для продукта).Мы используем CloudBuild для развертывания нашего проекта с помощью зеркалирования репозитория и триггера CloudBuild, который срабатывает при обновлении веток dev или prod.Файл cloudbuild.yaml выглядит следующим образом: 

# Firestore security rules deploy
- name: "gcr.io/$PROJECT_ID/firebase"
  args: ["deploy", "--only", "firestore:rules"]
  secretEnv: ['FIREBASE_TOKEN']

# Firestore indexes deploy
- name: "gcr.io/$PROJECT_ID/firebase"
  args: ["deploy", "--only", "firestore:indexes"]
  secretEnv: ['FIREBASE_TOKEN']

secrets:
- kmsKeyName: 'projects/my-dev-project/locations/global/keyRings/ci-ring/cryptoKeys/deployment'
  secretEnv:
    FIREBASE_TOKEN: 'myreallylongtokenstring'

timeout: "1600s"

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

secrets:
- kmsKeyName: 'projects/$PROJECT_ID/locations/global/keyRings/ci-ring/cryptoKeys/deployment'
  secretEnv:
    FIREBASE_TOKEN: 'myreallylongtokenstring'

Это не подходит для процесса непрерывного развертывания, подобного тому, который мы используем, так как мы хотели бы, чтобы строка kmsKeyName была динамически установлена ​​с соответствующим значением id проекта в зависимости от dev илиокружающая среда, в которой мы развертываем.

Есть ли способ обойти это, что позволило бы нам динамически указывать kmsKeyName?

Обновление: Мы нашли быстрое / грязное решение, которое было бысоздайте отдельные файлы cloudbuild.yaml: один для dev (cloudbuild-dev.yaml) и один для prod (cloudbuild-prod.yaml).Каждый файл cloudbuild идентичен, за исключением последней части, где мы указываем нашу жестко закодированную информацию о «секретах».Объяснение: GCP Cloud Build использует отдельные триггеры для каждой сборки среды, и каждый триггер можно настроить так, чтобы он указывал на определенный файл yaml cloudbuild, что мы и сделали.Триггерные точки сборки для разработчиков в cloudbuild-dev.yaml, а также производственные триггерные точки в cloudbuild-prod.yaml.

1 Ответ

0 голосов
/ 27 сентября 2019

Действительно, я пробовал разные конфигурации с простой кавычкой, двойной, без, с переменными подстановки, ...

Скучное решение - использовать ручное декодирование, как описано здесь .Но вы можете использовать переменные и переменные подстановки по своему усмотрению

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

- name: "gcr.io/$PROJECT_ID/firebase"
  entrypoint: "bach"
  args: 
    - "-c"
    - "export FIREBASE_TOKEN=$(cat secrets.json) && firebase deploy --only firestore:rules"

Я не знаю другого обходного пути

...