Как управлять секретами в среде Microservice/Container/Cloud?

Микросервисы и облако - вещь. Все говорят и пишут. Лично я много думаю об этих темах: как это можно использовать, чтобы извлечь выгоду из этого? Каковы возможные проблемы? Как это ускорит ежедневное развитие? И как управлять всем? Один вопрос, который беспокоит меня с нескольких дней, - "Как управлять секретами в среде Microservice/Cloud?".

Представьте себе компанию с 150 инженерами-программистами и различными командами с различными продуктами. Каждая команда создает программное обеспечение, и каждый сервис нуждается в различных количествах секретов (API-ключи, пароли, SSH-ключи, что угодно). Путь "старой моды" состоял в том, чтобы создать несколько файлов конфигурации в формате ini/yaml/txt и прочитать его. 12Factor apps говорят: сделайте это за env vars.

Env vars может быть настроен для каждой машины, и файлы конфигурации также могут быть размещены там. Это работает, если у вас есть рука, полная машин, и развертывание выполняется несколькими системными администраторами. Одно из общих правил говорит: "Не храните тайны в репозитории Git.

Теперь приходит новый мир. Вся команда отвечает за приложение, которое они производят сами. Они должны быть развернуты и управляться командой. Поэтому наша компания переходит на контейнер и способ самообслуживания (например, Mesos и Marathon или Kubernetes).

Конечно, Dockerfiles также может устанавливать env vars. И да, вы можете добавить свой файл конфигурации в контейнер Docker во время сборки. Но при этом каждый может получить доступ к секретам (например, от других команд). И никто не знает, кто использует эти секреты и делает что-то опасное.

Вы хотите также дозировать ваши файлы Docker. И приложения, которые вы хотите запускать на марафоне, должны быть представлены в версии (Git или что-то еще) (и применяются REST API). Итак, где хранить и управлять всеми секретами для этих контейнеров/приложений? Потому что с фреймворками планировщика, такими как Swarm and Machine (для Docker), Mesos и Marathon (также можно использовать Docker) или Kubernetes, вы не знаете, где будет работать ваше приложение. Это будет запланировано на нескольких машинах. И большинство этих инструментов не имеют аутентификации (по умолчанию, конечно, это может быть добавлено прокси Nginx или что-то в этом роде).

Одна идея управлять секретами - использовать инструмент, например Vault. Но я никогда не видел "родной" поддержки в приложении. То же самое относится к Blackbox. И я не знаю, как это может решить управление конфигурацией. Я знаю, что Шеф-повар поддерживает зашифрованные файлы данных, но afaik не может использовать Chef для установки/сборки контейнеров Docker.

Как вы управляете секретами в нескольких командах с несколькими инженерами в среде Microservice/Container/Cloud?

Ответы

Ответ 1

Существует несколько решений.

Сначала НЕ НЕ поместите свои секреты в изображение. Это просто плохая идея, как вы поняли. Если вы не добавляете свои секреты во время сборки, вам нужно сделать это во время выполнения. Это оставляет нам несколько вариантов:

  • Используйте переменные среды, предложенные 12 Factor App. Затем вам нужно написать script, который заполняет файлы конфигурации значениями этих переменных при запуске контейнера. Это работает, но мне это не очень нравится, так как переменные среды легко просачиваются (их можно увидеть в связанных контейнерах и docker inspect и часто включаются в отчеты об ошибках). Также см. Summon.

  • Используйте тома. Просто монтируйте файл конфигурации с секретами во время выполнения. Это работает, но это значит, что у вас есть файл с секретами, лежащими на хосте. Это усложняется, когда вы не знаете, на каком хосте будет работать ваш контейнер, например, при использовании фреймворков, таких как Swarm и Mesos.

  • Используйте безопасное хранилище k/v, такое как Vault/Keywhiz. Как вы заметили, вам нужно будет сделать некоторые скрипты, чтобы получить значения в приложении (как с env vars). Вам также нужно как-то аутентифицироваться в хранилище k/v (вы можете посмотреть драйверы тома для Keywhiz и Vault или использовать одноразовый токен, переданный через env var).

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