Skip to content

Секреты в Docker

Build secrets

Секреты передаваемые в сборку — это любая конфиденциальная информация, например пароль или токен API, используемая в процессе сборки приложения.

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

Типы секретов для передачи в сборку

  • Secret mounts — универсальный способ передачи секретов в сборку. При использовании этого способа, секрет берется из клиента осуществляющего сборку и делается временно доступным внутри контейнера сборки на время выполнения инструкции сборки.
  • SSH mounts — это специальные монтирования для предоставления сокетов SSH или ключей внутри сборок. Этот способ обычно используются, когда нужно работать с закрытыми репозиториями Git.
  • Git authentication for remote contexts — это набор предопределенных секретов для сборки с удаленным контекстом Git, который также является частным репозиторием. Эти секреты являются «предполетными» секретами: они не используются в инструкции по сборке, но используются для предоставления сборщику необходимых учетных данных для извлечения контекста.

Использование secret mounts

Для Secret mounts и SSH mounts использование секретов сборки — это двухэтапный процесс. Сначала нужно передать секрет в команду docker build, а затем нужно использовать секрет в Dockerfile.

Для передачи секрета используется флаг --secret

Поддерживаемые типы передаваемых секретов:

  • type=file
  • type=env

Секрет передается в качестве файла по следующему пути /run/secrets/id

Buildx пытается автоматически определить тип, если он не установлен. Если установлена ​​переменная окружения с тем же ключом, что и id, то Buildx использует type=env, а значение переменной становится секретом. Если такая переменная окружения не установлена, и type не установлен, то Buildx возвращается к type=file.

Bash
# собираем образ и передаем в него секрет из файла
docker build --secret id=secret_id,src=/path/to/secret_file .

# либо собираем образ с секретом из переменной окружения
SECRET_VARIABLE=secret_text
docker build --secret id=secret_id,env=SECRET_VARIABLE .
# также секрет из переменной можно передать без прмого указания env, тогда id автоматически примет имя переменной
docker build --secret id=SECRET_VARIABLE .

Теперь необходимо примонтировать созданный секрет внутрь образа. По умолчанию, файл с секретом монтируется в директорию /run/secrets/<id>. Но это поведение можно переопределить.

Docker
# Монтируем секрет в файл по умолчанию
FROM python:3 # берем базовый образ
RUN pip install something # выполняем какие-нибудь команды
RUN --mount=type=secret,id=secret_id \ # монтируем серкет по его id
    SECRET_VAR_FOR_PY=/run/secrets/secret_id # присваиваем переменной внутри контейнера значение секрета

Для того чтобы примонтировать секрет в другое место, используем опцию target

Docker
# Монтируем секрет в указанный файл
FROM python:3
RUN pip install something
RUN --mount=type=secret,id=secret_id,target=/path/to/secret_file

Еще можно примонтировать секрет, как переменную среды, для этого используем опцию env

Docker
# Монтируем секрет в указанную переменную
FROM python:3
RUN pip install something
RUN --mount=type=secret,id=secret_id1,env=SECRET_ENV1
    --mount=type=secret,id=secret_id2,env=SECRET_ENV2

Использование SSH mounts

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

Подробнее

Использование Git authentication for remote contexts

Подробнее

Использование секретов с Docker Compose

Помещение секрета в контейнер — это двухэтапный процесс. Сначала необходимо определить секрет с помощью элемента secrets верхнего уровня в Compose-файле. Затем добавить в определения служб атрибут secrets. Compose предоставляет доступ к секретам на основе настроек каждой службы.

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

Определение секретов верхнего уровня. Источником секрета является файл или переменная среды.

  • file: Секрет создается с содержимым файла по указанному пути.
  • environment: Секрет создается со значением переменной среды.
Передаем секреты в docker-compose
# Определяем какие секреты будут доступны и в каких файлах они хранятся
secrets:
   db_password:
     enviroment: DB_PASSWORD # секретная переменная среды
   db_root_password:
     file: /path/to/secret_dir/db_root_password.txt # секретная директория

volumes:
    db_data:

services:
   db:
     image: mysql:latest
     volumes:
       - db_data:/var/lib/mysql
     environment:
       MYSQL_ROOT_PASSWORD_FILE: /run/secrets/db_root_password # указываем сервису где искать секрет
       MYSQL_DATABASE: wordpress
       MYSQL_USER: wordpress
       MYSQL_PASSWORD_FILE: /run/secrets/db_password # указываем сервису где искать секрет
     secrets: # определяем какие секреты доступны этому сервису
       - db_root_password
       - db_password

   wordpress:
     depends_on:
       - db
     image: wordpress:latest
     ports:
       - "8000:80"
     environment:
       WORDPRESS_DB_HOST: db:3306
       WORDPRESS_DB_USER: wordpress
       WORDPRESS_DB_PASSWORD_FILE: /run/secrets/db_password # указываем сервису где искать секрет
     secrets: # определяем какие секреты доступны этому сервису
       - db_password