Как хранить и извлекать секреты из Hashicorp Vault с помощью Docker-Compose?

Я установил экземпляр Hashicorp Vault. Я успешно написал и прочитал секреты этого и от него. Установить и запустить Vault - это самая простая часть. Теперь, как мне использовать Vault в качестве хранилища для замены файла .env в docker-compose.yml? Как мне прочитать секреты из Vault во всех моих файлах docker-compose?

Еще сложнее: как мне динамически генерировать ключи для доступа к секретам в Vault, а затем использовать эти ключи в моих файлах docker-compose.yml, не редактируя эти файлы каждый раз, когда я перезапускаю стек? Как этот процесс автоматизирован? Короче говоря, как именно я могу использовать Hashicorp Vault для защиты секретов, которые в противном случае раскрываются в файлах .env?

Я прочитал всю их литературу и сообщения в блогах и не смог найти ничего, что описывало бы этот процесс. Я застрял, и я буду благодарен за любые советы.

Примечание. Это не вопрос запуска контейнера Hashicorp Vault с docker-compose, я уже успешно это сделал.

Также примечание: я не могу изменять сами контейнеры; Я могу изменять только файл docker-compose.yml


person Shōgun8    schedule 05.03.2020    source источник


Ответы (1)


Вам нужно будет запросить API хранилища, чтобы заполнить либо ваш .env файл, либо точку входа вашего контейнера. В худшем случае я бы предпочел точку входа в контейнер, а в идеале - прямо в вашем приложении. Причина в том, что секреты хранилища могут быть недолговечными, и любой контейнер, работающий дольше этого периода, должен будет обновить свои секреты.

Если вы выберете наихудший вариант выполнения этого в точке входа, на ум приходят несколько инструментов. confd от Келси Хайтауэр и gomplate.

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

gomplate будет запускаться вашей точкой входа для расширения файла шаблона необходимыми значениями. Этот файл может быть просто env.sh, который вы затем отправляете в свою среду, если вам нужны переменные env. Или вы можете запустить его в командной строке как подоболочку, например

your-app --arg "$(gomplate ...sometemplate...)"

Если вы используете эти инструменты только для установки значения один раз, а затем запускаете приложение, обязательно настройте проверку работоспособности и / или плавный выход из приложения, когда срок действия учетных данных истечет. Затем запустите свой контейнер с оркестровкой (Kubernetes / Swarm Mode) или установите политику перезапуска, чтобы он перезапускался после истечения срока действия любых учетных данных, чтобы получить новые учетные данные.

person BMitch    schedule 05.03.2020
comment
Спасибо, что ответили так быстро. Наверное, мне следовало упомянуть, что я пытаюсь применить это к своим существующим стекам. Это означает, что я не могу редактировать точку входа или каким-либо образом изменять контейнеры; Я могу только редактировать файл docker-compose. Я просто хочу заменить файл .env как средство для хранения секретов. - person Shōgun8; 05.03.2020
comment
Вы можете запустить gomplate на хосте для сборки .env, но это предполагает, что ваши секреты никогда не меняются между развертываниями. Также предполагается, что вы не возражаете, чтобы ваши секреты хранились в виде открытого текста в файловой системе и были видны в инспектируемом контейнере. Идет вразрез со всей ценностью хранилища. - person BMitch; 05.03.2020
comment
Итак, confd и gomplate на 110% исключены: я имею в виду, зачем добавлять так много уровней сложности и абстракции для достижения точно такого же результата? Нет ли способа обеспечить шифрование для переменных среды docker-compose.yml? Я предполагал, что это будет простая функция в Vault, и это единственная причина, по которой я вообще подумал об использовании Vault. - person Shōgun8; 05.03.2020
comment
Вот почему я предлагаю сделать это либо в точке входа в худшем случае, либо в самом приложении в лучшем случае. - person BMitch; 05.03.2020