GAE: Как развернуть различные среды с секретами?

Question

У меня есть сценарий и производственный проект на App Engine, с 6 сервисами на каждом.

На данный момент мы развертываем с компьютера разработчиков, используя gcloud app deploy app.staging.yaml --project staging-project

или gcloud app deploy app.production.yaml --project production-project

Работает, но вызывает проблемы с переменными среды, особенно с секретами.

Наши приложения получают ключи Api, учетные данные базы данных и другие данные из переменных среды, что позволяет нам запускать одно и то же приложение локально, в контейнере Docker или в App Engine, не зная, где оно развернуто.

Если я буду использовать документацию для развертывания, наши файлы app.yaml будут выглядеть так:

app.production.yaml

runtime: nodejs
env: flex

manual_scaling:
  instances: 1
env_variables:
  DATABASE_PASSWORD: "topsecret"
  MY_API_KEY: "ultrasecret"

Я думаю, что все легко понимают, почему плохая идея хранить это в репозитории Git.

На данный момент у нас есть этот теневой файл, который каждый разработчик должен заполнить перед развертыванием

app.production.yaml.shadow

runtime: nodejs
env: flex

manual_scaling:
  instances: 1
env_variables:
  DATABASE_PASSWORD: "set me"
  MY_API_KEY: "set me"

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

Я обнаружил 3 обходных пути и причину их неиспользования:

• Использование Google KMS - позволяет нам помещать зашифрованные секреты непосредственно в проект, но для их расшифровки требуется, чтобы мы добавили пользовательский код в наши приложения. Это создает другую среду управления между местным, промежуточным и производственным. Это увеличивает риск ошибок из-за сложности.
• Хранить секреты в Google Datastore - Я попробовал, я создал помощник, который ищет env vars в proccess.ENV, затем в кеше и в конечном итоге в Datastore. Но, как и в KMS, это значительно увеличивает сложность.
• Хранить секреты в файле JSON и помещать в Google Cloud Storage : опять же, требуется загрузить переменные env через помощника, который проверяет env vars, затем загружает файл и т. Д. ...

В конечном счете, мы изучаем возможность использования сервера развертывания , который будет запускаться разработчиками или Continuous Integration и обрабатывать все инъекции секретов при развертывании в App Engine. Но такие инструменты, как Ansible , Salt, Puppet, Chef имеют только плагины для Compute Engine и не поддерживают App Engine.

+-------------------------+    +-------------------+   +---------------------+
|                         |    |                   +--->                     |
| Developer workspace     |    |    Ansible        |   | App Engine STAGING  |
|                         +---->   (or other)      |   |                     |
+-------------------------+    |                   |   +---------------------+
                               |                   |
+-------------------------+    |                   |   +---------------------+
|                         +---->   Injects secrets |   |                     |
| Continous Integration        |                   |   | App Engine PROD.    |
|                         |    |                   +--->                     |
+-------------------------+    +-------------------+   +---------------------+

Это подводит меня к 3 вопросам:

• Считаете ли вы хорошей идеей использование сервера развертывания с App Engine?
• Как я могу убедиться, что производственные и промежуточные секреты поддерживают синхронизацию, чтобы развертывания от разработчиков всегда были правильными?
• Есть ли способ использовать классические переменные среды для секретов в App Engine?

Answer 1

Я настоятельно рекомендую вам рассмотреть возможность использования комбинации KMS и облачного хранилища, как Google выделяет здесь .

Вы правы, что установка шеи может быть немного болезненной, но как только она на месте, с ней очень легко работать.Мы установили отдельные цепочки ключей для каждой среды (dev, test, staging, prod), а затем разделили ключи для каждого приложения и написали утилиту командной строки, которая позволяет любому разработчику в нашей команде писать тривиальносекреты в секретное хранилище (в то же время не позволяя им читать секреты производства обратно).

В конечном счете, управление секретами остается сложной проблемой.Управлять секретами для нескольких приложений / сред по мере роста вашей команды сложно.Но я бы действительно рекомендовал вам просто заплатить стоимость инвестиций в что-то вроде KMS, потому что это существенно облегчит вашу жизнь навсегда и действительно уменьшит риск того, что вы случайно выстрелите себе в ногу.

Answer 2

Несколько раз позже, вот что я могу сказать по этому вопросу:

• Создайте один app.yaml для каждой среды. Вы можете указать файл app.yaml для использования во время развертывания в соответствии с вашей средой.
• Поместите ваши не секретные параметры среды (например, URL-адреса конечных точек) в раздел env_variables.
• Для ваших секретов (ключей API, секретных токенов ...) используйте специальный инструмент, например Hashicorp Vault или AWS Secrets Manager . Это позволит вам делиться ими между вашими проектами и определять, кто может получить к ним доступ в вашей команде.

Answer 3

Как вы сказали, ни одно из этих решений (Ansible, Salt и т. Д.) Невозможно использовать с App Engine. Если бы вы использовали их, вам пришлось бы перейти в GCE. У Google есть несколько официальных руководств о том, как начать использовать любую из этих технологий.

Если вы остаетесь в App Engine, вы можете использовать одно из упомянутых решений, KMS лучше ориентируется для этой цели.

Другим возможным решением будет переход на пользовательскую среду выполнения. На основе вашего приложения вы можете сгенерировать Dockerfile с:

$ gcloud beta app gen-config --custom

Ваш Dockerfile будет выглядеть так:

FROM gcr.io/google_appengine/nodejs
RUN /usr/local/bin/install_node '>=4.3.2'
COPY . /app/
RUN npm install --unsafe-perm || \
  ((if [ -f npm-debug.log ]; then \
      cat npm-debug.log; \
    fi) && false)
CMD npm start

Затем вы можете изменить его, включив в него секретные ключи, хранящиеся в переменных вашей среды, с помощью чего-то вроде этого примера того, как вводить ключи в ваш файл:

sed 's/topsecret/'"$KEY_1"'/g;s/ultrasecret/'"$KEY_2"'/g' app.production.yaml.shadow > app.production.yaml

Помните об использовании одинарных и двойных кавычек до и после KEY_1 и KEY_2, так как они вам нужны для ввода переменных окружения с помощью sed.