Докер и защита паролей

Недавно я экспериментировал с Docker над созданием некоторых сервисов, с которыми можно поиграться, и одна вещь, которая меня постоянно раздражает, это вставка паролей в Dockerfile. Я разработчик, поэтому хранение паролей в исходном коде похоже на удар по лицу. Должно ли это быть проблемой? Есть ли хорошие соглашения о том, как обрабатывать пароли в Dockerfiles?

Определенно это проблема. Файлы Docker обычно регистрируются в репозиториях и передаются другим людям. Альтернативой является предоставление любых учетных данных (имена пользователей, пароли, токены и т. Д.) В качестве переменных среды во время выполнения . Это возможно с помощью -eаргумента (для отдельных переменных в CLI) или --env-fileаргумента (для нескольких переменных в файле) для docker run. Прочитайте это для использования среды с docker-compose.

Использование --env-file, безусловно, более безопасный вариант, так как это защищает от секретов, отображаемых в psжурналах или в журналах, если таковые используются set -x.

Однако env vars также не особенно безопасны. Они видны через docker inspect, и, следовательно, они доступны любому пользователю, который может запускать dockerкоманды. (Конечно, любой пользователь, имеющий доступ к dockerхосту, также имеет права root ).

Мой предпочтительный шаблон - использовать скрипт-обертку в качестве ENTRYPOINTили CMD. Сценарий-оболочка может сначала импортировать секреты из внешнего местоположения в контейнер во время выполнения, а затем запустить приложение, предоставив секреты. Точная механика этого зависит от вашей среды выполнения. В AWS вы можете использовать комбинацию ролей IAM, службы управления ключами и S3 для хранения зашифрованных секретов в корзине S3. Что-то вроде HashiCorp Vault или credstash - это еще один вариант.

AFAIK Не существует оптимального шаблона для использования конфиденциальных данных в процессе сборки. На самом деле, у меня есть вопрос по этой теме. Вы можете использовать docker-squash для удаления слоев с изображения. Но для этого в Docker нет встроенной функциональности.

Вы можете найти полезные комментарии к конфигурации в контейнерах .

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

Мы решаем для этого, используя docker-compose.

Внутри docker-compose.ymlвы можете указать файл, который содержит переменные среды для контейнера:

 env_file:
- .env

Убедитесь в том , чтобы добавить .envв .gitignore, а затем установить учетные данные в пределах .envфайла , как:

SOME_USERNAME=myUser
SOME_PWD_VAR=myPwd

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

Смотрите: https://docs.docker.com/compose/environment-variables/#/the-env-file

Docker сейчас (версия 1.13 или 17.06 и выше) имеет поддержку для управления секретной информацией. Вот обзор и более подробная документация

Подобная особенность существует в kubernetes и DCOS

Никогда не следует добавлять учетные данные в контейнер, если вы не согласны с передачей кредитов тому, кто сможет загрузить изображение. В частности, выполнение и ADD credsпозже RUN rm credsне является безопасным, поскольку файл creds остается в конечном изображении на уровне промежуточной файловой системы. Любой, имеющий доступ к изображению, может легко извлечь его.

Типичное решение, которое я видел, когда вам нужны кредиты для проверки зависимостей, например, использование одного контейнера для создания другого. То есть обычно у вас есть базовая среда сборки в базовом контейнере, и вам нужно вызывать ее для сборки контейнера приложения. Поэтому простое решение - добавить исходный код приложения, а затем RUNкоманды сборки. Это небезопасно, если вам нужны кредиты в этом RUN. Вместо этого вы помещаете свой источник в локальный каталог, запускаете (как в docker run) контейнер для выполнения шага сборки, когда локальный каталог источника монтируется как том, а кредиты либо внедряются, либо монтируются как другой том. После того, как шаг сборки завершен, вы создаете свой окончательный контейнер, просто ADDиспользуя локальный исходный каталог, который теперь содержит встроенные артефакты.

Я надеюсь, что Docker добавляет некоторые функции, чтобы упростить все это!

Обновление: похоже, что в будущем будет использоваться метод построения вложенных сборок. Вкратце, файл dockerfile будет описывать первый контейнер, который используется для построения среды выполнения, а затем вторую сборку вложенного контейнера, которая может собрать все части в конечный контейнер. Таким образом, материал во время сборки не находится во втором контейнере. Это Java-приложение, в котором вам нужен JDK для сборки приложения, но только JRE для его запуска. Обсуждается ряд предложений, лучше всего начать с https://github.com/docker/docker/issues/7115 и перейти по некоторым ссылкам для получения альтернативных предложений.

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

Если вы поместите все свои учетные данные в виде файлов в эту папку, тогда контейнер сможет читать файлы и использовать их по своему усмотрению.

Например:

$ echo "secret" > /root/configs/password.txt
$ docker run -v /root/configs:/cfg ...

In the Docker container:

# echo Password is `cat /cfg/password.txt`
Password is secret

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

решение только во время выполнения

docker-compose также предоставляет решение не в режиме роя (начиная с v1.11: секреты с использованием bind mounts ).

Секреты смонтированы в виде файлов ниже с /run/secrets/помощью docker-compose. Это решает проблему во время выполнения (запуск контейнера), но не во время сборки (сборка образа), поскольку /run/secrets/не монтируется во время сборки. Кроме того, это поведение зависит от запуска контейнера с docker-compose.

Пример:

Dockerfile

FROM alpine
RUN cat /run/secrets/password
CMD sleep inifinity

докер-compose.yml

version: '3.1'
services:
  app:
    build: .
    secrets:
      - password

secrets:
  password:
    file: password.txt

Чтобы построить, выполните:

docker-compose up -d

Дальнейшее чтение:

• Блог mikesir87 - Использование секретов Docker во время разработки

В Docker v1.9 вы можете использовать инструкцию ARG для извлечения аргументов, переданных из командной строки, в образ при действии сборки . Просто используйте флаг --build-arg . Таким образом, вы можете избежать сохранения явного пароля (или другой разумной информации) в Dockerfile и передавать его на лету.

источник: https://docs.docker.com/engine/reference/commandline/build/ http://docs.docker.com/engine/reference/builder/#arg

Пример:

Dockerfile

FROM busybox
ARG user
RUN echo "user is $user"

команда построения образа

docker build --build-arg user=capuccino -t test_arguments -f path/to/dockerfile .

во время сборки распечатать

$ docker build --build-arg user=capuccino -t test_arguments -f ./test_args.Dockerfile .

Sending build context to Docker daemon 2.048 kB
Step 1 : FROM busybox
 ---> c51f86c28340
Step 2 : ARG user
 ---> Running in 43a4aa0e421d
 ---> f0359070fc8f
Removing intermediate container 43a4aa0e421d
Step 3 : RUN echo "user is $user"
 ---> Running in 4360fb10d46a
**user is capuccino**
 ---> 1408147c1cb9
Removing intermediate container 4360fb10d46a
Successfully built 1408147c1cb9

Надеюсь, поможет! До свидания.

Мой подход, кажется, работает, но, вероятно, наивен. Скажи мне, почему это неправильно.

ARG, установленные во время сборки докера, выставляются подкомандой history, поэтому идти туда не нужно. Однако при запуске контейнера переменные среды, указанные в команде run, доступны для контейнера, но не являются частью образа.

Итак, в Dockerfile выполните настройку, которая не использует секретные данные. Установите CMD что-то вроде /root/finish.sh. В команде run используйте переменные среды для отправки секретных данных в контейнер. finish.shпо существу использует переменные для завершения задач сборки.

Чтобы упростить управление секретными данными, поместите их в файл, который загружается программой Docker, запущенной с --env-fileкоммутатором. Конечно, держите файл в секрете. .gitignoreи тому подобное.

Для меня finish.shработает программа на Python. Он проверяет, чтобы убедиться, что он не запускался раньше, а затем завершает настройку (например, копирует имя базы данных в Django settings.py).

Появилась новая команда docker для управления «секретами». Но это работает только для скоплений роя.

docker service create
--name my-iis
--publish target=8000,port=8000
--secret src=homepage,target="\inetpub\wwwroot\index.html"
microsoft/iis:nanoserver 

Методология приложение 12-фактор говорит, что любая конфигурация должна храниться в переменных окружения.

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

Хотя я полностью согласен, простого решения не существует. Там продолжает быть единственная точка отказа. Либо dockerfile, etcd и так далее. У Apcera есть план, который выглядит как кореш - двойная аутентификация. Другими словами, два контейнера не могут общаться, если нет правила конфигурации Apcera. В их демонстрации uid / pwd был в открытом виде и не мог быть повторно использован, пока администратор не настроил связь. Однако, чтобы это работало, это, вероятно, означало исправление Docker или, по крайней мере, сетевого плагина (если есть такая вещь).