Как установить переменные среды с помощью Google Cloud Build или другого метода в стандартной среде Google App Engine? - PullRequest
Новая
       43

Как установить переменные среды с помощью Google Cloud Build или другого метода в стандартной среде Google App Engine?

0 голосов
/ 16 октября 2018

Есть ли способ добавить переменные среды из Cloud Build в стандартную среду App Engine?

Я не хочу передавать свои переменные окружения в GitHub внутри app.yaml или .env.Таким образом, при извлечении и развертывании Cloud Build отсутствует файл .env, и сервер не может выполнить некоторые запросы.

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

Я также попробовал учебное пособие здесь , чтобы импортировать файл .env в App Engine Standard из хранилища, но поскольку у Standard нет локального хранилища, я предполагаю, что оно идетв пустоту.

Так есть ли в любом случае для внедрения .env в стандартную среду App Engine без использования хранилища данных или фиксации app.yaml или .env для изменения управления?Потенциально с помощью Cloud Build, KMS или другого типа хранилища?

Вот что я пробовал для cloudbuild.yaml: 

steps:
- name: "gcr.io/cloud-builders/gcloud"
  args: ["app", "deploy"]
  secretEnv: ['SECRET1', 'SECRET2', 'SECRET3', 'SECRET4', 'SECRET5']
timeout: "1600s"

secrets:
- kmsKeyName: projects/<Project-Name>/locations/global/keyRings/<Key-Ring-Name>/cryptoKeys/<Key-Name>
  secretEnv:
    SECRET1: <encrypted-key-base64 here>
    SECRET2: <encrypted-key-base64 here>
    SECRET3: <encrypted-key-base64 here> 
    SECRET4: <encrypted-key-base64 here> 
    SECRET5: <encrypted-key-base64 here>

Ответы [ 2 ]

0 голосов
/ 29 июня 2019

Вот учебник о том, как безопасно хранить переменные env в настройках вашей облачной сборки (триггеры) и импортировать их в ваше приложение.

В основном есть три шага:

  1. Добавьте переменные env в раздел «переменные» в одной из настроек триггера сборки

    Снимок экрана, на котором необходимо добавить переменные в триггеры сборки

    По условию переменные, установленные в триггере сборки, должны начинаться с подчеркивания (_)

  2. Настроить cloudbuild.yaml (на втором шаге в примере кода) для чтения переменных изваш триггер сборки, установите их как env vars и запишите все env vars в локальный файл .env

    Добавьте couldbuild.yaml (ниже) в корневой каталог вашего проекта 

steps:
- name: node:10.15.1
  entrypoint: npm
  args: ["install"]
- name: node:10.15.1
  entrypoint: npm
  args: ["run", "create-env"]
  env:
    - 'MY_SECRET_KEY=${_MY_SECRET_KEY}'
- name: "gcr.io/cloud-builders/gcloud"
  args: ["app", "deploy"]
timeout: "1600s"

Добавить create-env скрипт к package.json

"scripts": {
  "create-env": "printenv > .env"
},

Чтение переменных env из .env в ваше приложение (config.js)

Установка пакета dotenv

npm i dotenv -S

Добавление config.js вваше приложение 

// Import all env vars from .env file
require('dotenv').config()

export const MY_SECRET_KEY = process.env.MY_SECRET_KEY

console.log(MY_SECRET_KEY) // => Hello

Готово!Теперь вы можете развернуть свое приложение, запустив облачную сборку, и ваше приложение получит доступ к env vars.

0 голосов
/ 17 октября 2018

На основе ваших предпочтений, которые вы выделили (Cloud Build, KMS).Ссылка на секреты Google, о которой вы упомянули, включает в себя хранение конфиденциальных данных во время сборки или выполнения с использованием Cloud KMS : KeyRing и CryptoKey.Тем не менее, Google предлагает и другие решения для секретного управления, использующие Cloud KMS.

Вот несколько других опций, которые вы можете использовать при хранении секретов :

1 : Вы можете хранить секреты в коде , которые зашифрованы ключом от Cloud KMS. (Обычно используется для шифрования вашего секрета на прикладном уровне.)

Преимущество: Обеспечивает уровень защиты от внутренних угроз, поскольку ограничивает доступ к коду с соответствующим ключом .

[Дополнительную информацию об этих параметрах можно найти в документации Google здесь .]

Опция 2: Вы можете хранить секреты в Google Storage Bucket , где ваши данные находятся в остальном шифровании. (По аналогии сВариант 1 позволяет ограничить доступ к секретам небольшой группе разработчиков.)

Преимущество: Хранение ваших секретов в отдельном месте гарантирует, что , если нарушение вашего репозитория кода произошло , ваши секреты все еще может быть защищено .)

[Примечание: Google рекомендует использовать два проекта для правильного разделения обязанностей .Один проект будет использовать Cloud KMS для управления ключами, а другой проект будет использовать Cloud Storage для хранения секретов.]

Если перечисленные выше варианты по-прежнему не соответствуют вашим потребностям, я обнаружил Вопрос StackOverflow , который преследует ту же цель, что и ваш проект.(т.е.: хранение переменных среды в GAE без хранилища данных)

Решение, предоставленное для этой ссылки , иллюстрирует использование хранения ключей в файле client_secrets.json, который исключаетсяпри загрузке в git, перечислив его в .gitignore.Вы можете найти Google примеров (Python) использования здесь .

...