как вы управляете секретными значениями с помощью docker-compose v3.1?

Вы можете прочитать соответствующий раздел официальной документации .

Чтобы использовать секреты, вам нужно добавить две вещи в ваш docker-compose.yml файл. Во-первых, блок верхнего уровня secrets:, определяющий все секреты. Затем еще один блок secrets: под каждой службой, в котором указывается, какие секреты должна получить служба.

В качестве примера создайте два типа секретов, которые будет понимать Docker: внешние секреты и файловые секреты.

1. Создайте «внешний» секрет с помощью docker secret create

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

$ docker swarm init

Затем создайте «внешний» секрет:

$ echo "This is an external secret" | docker secret create my_external_secret -

(Не забудьте добавить последнее тире, -. Его легко пропустить.)

2. Запишите еще один секрет в файл.

$ echo "This is a file secret." > my_file_secret.txt

3. Создайте docker-compose.yml файл, в котором используются оба секрета.

Теперь, когда созданы оба типа секретов, вот файл docker-compose.yml, который прочитает оба из них и запишет их в службу web:

version: '3.1'

services:
  web:
    image: nginxdemos/hello
    secrets:                    # secrets block only for 'web' service
     - my_external_secret
     - my_file_secret

secrets:                        # top level secrets block
  my_external_secret:
    external: true
  my_file_secret:
    file: my_file_secret.txt

Docker может читать секреты либо из своей собственной базы данных (например, секреты, созданные с помощью docker secret create), либо из файла. Выше показаны оба примера.

4. Разверните тестовый стек.

Разверните стек, используя:

$ docker stack deploy --compose-file=docker-compose.yml secret_test

Это создаст один экземпляр службы web с именем secret_test_web.

5. Убедитесь, что контейнер, созданный службой, содержит оба секрета.

Используйте docker exec -ti [container] /bin/sh, чтобы убедиться, что секреты существуют.

(Примечание: в приведенной ниже команде docker exec часть m2jgac... на вашем компьютере будет отличаться. Запустите docker ps, чтобы найти имя вашего контейнера.)

$ docker exec -ti secret_test_web.1.m2jgacogzsiaqhgq1z0yrwekd /bin/sh

# Now inside secret_test_web; secrets are contained in /run/secrets/
root@secret_test_web:~$ cd /run/secrets/

root@secret_test_web:/run/secrets$ ls
my_external_secret  my_file_secret

root@secret_test_web:/run/secrets$ cat my_external_secret
This is an external secret

root@secret_test_web:/run/secrets$ cat my_file_secret
This is a file secret.

Если все в порядке, два секрета, которые мы создали на шагах 1 и 2, должны находиться внутри контейнера web, который был создан при развертывании нашего стека.

Если у вас есть служба myapp и файл секретов secrets.yml:

Создайте файл для создания сообщения:

version: '3.1'

services:
  myapp:
    build: .
    secrets:
      secrets_yaml

Предоставьте секрет с помощью этой команды:

docker secret create secrets_yaml secrets.yml

Разверните свой сервис с помощью этой команды:

docker deploy --compose-file docker-compose.yml myappstack

Теперь ваше приложение может получить доступ к секретному файлу по адресу /run/secrets/secrets_yaml. Вы можете жестко указать этот путь в своем приложении или создать символическую ссылку.

Другой вопрос

Вероятно, это ответ на вопрос «как вы предоставляете свои секреты своему кластеру Docker Swarm».

Исходный вопрос «как управлять секретными значениями с помощью docker compose» подразумевает, что файл docker-compose содержит секретные значения. Это не так.

Есть другой вопрос: «Где вы храните канонический источник secrets.yml файла». Все зависит от вас. Вы можете хранить его в своей голове, распечатать на листе бумаги, использовать менеджер паролей, использовать специальное приложение / базу данных секретов. Черт возьми, вы даже можете использовать репозиторий git, если он надежно защищен. Конечно, никогда не храните его внутри системы, которую вы защищаете :)

Я бы порекомендовал хранилище. Чтобы сохранить секрет:

# create a temporary secret file
cat secrets.yml | vault write secret/myappsecrets -

Чтобы получить секрет и поместить его в свой роя докеров:

vault read -field=value secret/myappsecrets | docker secret create secrets_yaml -

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

Вопрос, который никто не задавал

Третий вопрос (который никто не задавал) - как предоставить секреты машинам разработчиков. Это может потребоваться, когда есть внешняя служба, которую невозможно имитировать локально, или большая база данных, которую невозможно скопировать.

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

Идеальное решение выглядит так:

• Разработчик открывает какое-то веб-приложение.
• Аутентифицируется с использованием какого-либо механизма единого входа.
• Копирует длинный список docker secret create команд и выполняет их в терминале.

Нам еще предстоит увидеть, появится ли такое приложение.

Вы также можете указать secrets храниться локально в файле, используя ключ file: в объекте secrets. Тогда вам не нужно docker secret create их самостоятельно, Compose / docker stack deploy сделает это за вас.

version: '3.1'

secrets:
  password:
    file: ./password

services:
  password_consumer:
    image: alpine
    secrets:
      - password

Ссылка: Ссылка на файл версии 3: Секреты

Это точный отступ вашего docker-compose.yml файла? Я думаю secret secrets должен быть вложен в a (т. Е. Одну из служб), а не непосредственно в раздел services.

В комментариях был поднят один вопрос, зачем мне инициализировать рой, если мне нужны только секреты? И я отвечу, что секреты создаются для роя, где у вас более одного узла, и вы хотите безопасно управлять секретами и делиться ими. Но если у вас есть один узел, это (почти) не добавит дополнительной безопасности, если кто-то может получить доступ к вашему хост-компьютеру, на котором у вас есть рой из одного узла, поскольку секреты могут быть получены из запущенных контейнеров или непосредственно на хосте, если секрет создается из файла, как закрытый ключ.

Посетите этот блог: https://www.docker.com/blog/docker-secrets-management/

И читайте комментарии: Большое спасибо за вводную статью. Упомянутые шаги для просмотра содержимого секретов в контейнере не будут работать, если контейнер redis создается на рабочем узле.

Я предполагаю, что ключевое слово secrets, а не secret. По крайней мере, это то, что я понял из чтения person fzgregor    schedule 09.02.2017