Как защитить конфиденциальные данные с помощью Docker Compose Secrets

Безопасное управление секретами — важный аспект безопасности контейнеров. Если вы внедряете пароли и ключи API в качестве переменных среды, вы рискуете непреднамеренным раскрытием информации. Переменные оболочки часто регистрируются, передаются дочерним процессам или утекают в службы отчетов об ошибках без вашего ведома.

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

Как работают секреты?

В интерфейсе командной строки Docker есть набор секретных команд управления, но они работают только с кластерами Swarm. Вы не можете добавлять секреты в автономные контейнеры, используя только интерфейс командной строки Docker.

Docker Compose добавил «поддельные» секреты, чтобы реализовать эти возможности для рабочих нагрузок без кластера. Реализация Compose работает аналогично функциям Docker Swarm и работает с любым файлом Compose.

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

Определение секретов в файлах Compose

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

Вот пример, в котором секреты используются для безопасного предоставления пароля службе:

version: "3"
services:
  app:
    image: example-app:latest
    secrets:
      - db_password
secrets:
    db_password:
      file: ./db_password.txt

Значение секрета будет считано из файла db_password.txt вашего рабочего каталога при запуске docker-compose up. Compose смонтирует файл в /run/secrets/db_password внутри контейнера. Ваше приложение может получить доступ к паролю базы данных, прочитав содержимое секретного файла.

Использование существующих секретов Docker

Помимо секретов на основе файлов, Compose также позволяет ссылаться на существующие секреты Docker Swarm. Если вы используете этот механизм, вы должны создать секреты в Docker до запуска docker-compose up. Командное пространство docker secrets будет работать, только если ваша активная конечная точка Docker является узлом диспетчера Swarm.

Создайте секрет с помощью интерфейса командной строки Docker:

# take value from standard input
echo P@55w0rd | docker secret create db_password -
 
OR 
 
# take value from a file
docker secret create db_password ./db_password.txt

Теперь обновите файл Docker Compose, указав секрет:

version: "3"
services:
  app:
    image: example-app:latest
    secrets:
      - db_password
secrets:
    db_password:
      external: true

Установка поля external секрета указывает, что Compose должен получать его значение из ваших существующих секретов Docker. Стек выйдет из строя с ошибкой, если вы попытаетесь запустить его до того, как секрет существует.

Расширенный секретный синтаксис

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

Доступны пять необязательных полей:

source — имя секрета, на который следует ссылаться. Это должно быть одно из значений, определенных в разделе secrets файла Compose.< /li>
target — имя файла, которое будет использоваться при монтировании секрета в контейнер.
uid — UID, который нужно установить для смонтированного секретного файла. По умолчанию 0.
gid — GID, который нужно установить для смонтированного секретного файла. По умолчанию 0.
mode — разрешения файловой системы для применения к смонтированному секретному файлу, выраженные в восьмеричном представлении. По умолчанию это 0444. Учтите, что секретные файлы никогда не доступны для записи, поскольку они всегда монтируются во временную файловую систему контейнера.

Вот модифицированный пример, который переименовывает смонтированный секретный файл и меняет его разрешения:

version: "3"
services:
  app:
    image: example-app:latest
    secrets:
      - source: db_password
        target: database_password_secret
        mode: 0440
secrets:
    db_password:
      external: true

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

Секреты и авторство изображений

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

Вы можете поддерживать оба механизма, разрешив для переменных среды указывать путь к файлу. Если вашему образу требуется подключение к базе данных, позвольте пользователям установить для переменной среды DB_PASSWORD значение P@55w0rd или /run/secrets/db_password. Ваш контейнер должен проверять, ссылается ли значение переменной на допустимый файл; если это так, отбросьте его и прочитайте окончательное значение из файла.

Эта модель дает пользователям гибкость в выборе наиболее подходящего механизма для их развертывания. Помните, что не все пользователи смогут принимать секреты — если Swarm и Compose недоступны, они не смогут предоставить свои значения.

Заключение

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

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

Секреты должны быть «секретными» на протяжении всего жизненного цикла вашего контейнера. Для производственных развертываний обычно лучше всего автоматизировать сборку с помощью системы CI. Установите свои секреты в настройках конвейера поставщика CI, а затем используйте сценарий сборки, чтобы записать их в файлы, к которым Compose может получить доступ. Это гарантирует, что только у вас есть доступ к фактическим значениям через интерфейс вашего инструмента CI.