Docker: защита TCP‑сокета с TLS

Быстрые ссылки

Exposing the TCP Socket
Creating Your Certificate Authority
Generating a Server Key and Certificate Signing Request
Setting Up Certificate Extensions
Generating a Signed Certificate
Generating a Client Certificate
Preparing to Configure Docker
Configuring the Docker Daemon
Configuring the Docker Client
Заключение

Изображение схемы защиты Docker‑сокета TLS

Docker API по умолчанию не защищён при доступе по TCP: единственная защита — права на доступ к Unix‑сокету в файловой системе. Если вы будете экспонировать Docker API по TCP, обязательно настройте TLS — это позволит Docker Engine и клиентам проверять подлинность друг друга. Иначе любой, кто имеет доступ к открытому порту, сможет просматривать контейнеры, запускать новые и выполнять команды с правами

root

в вашей системе.

Настроенный TLS требует от клиента предоставления корректного сертификата, подписанного вашим CA. В этом руководстве вы найдёте последовательность действий: от создания CA до настройки демона и клиента Docker. Также приведены рекомендации по безопасной эксплуатации, продлению сертификатов и устранению неисправностей.

Зачем это важно

TLS добавляет шифрование и взаимную аутентификацию между клиентом и сервером.
Без TLS любой атакующий может получить управление Docker и, следовательно, системой.
TLS не заменяет разграничение прав; он защищает канал и удостоверяет участников.

Условные обозначения и термины

CA — Certificate Authority, центр сертификации, который подписывает сертификаты.
CSR — Certificate Signing Request, запрос на подпись сертификата.
FQDN — полностью квалифицированное доменное имя сервера.

Exposing the TCP Socket

Чтобы открыть TCP‑эндпоинт Docker, при запуске демона укажите дополнительный хост через флаг -H. Флаг можно указать несколько раз; в примере ниже будут доступны и Unix‑сокет, и TCP‑порт:

/usr/bin/dockerd -H unix:///var/run/docker.sock -H tcp://0.0.0.0:2375

Порт 2375 обычно используется для незашифрованных подключений. После настройки TLS используйте порт 2376.

Чтобы флаги применялись автоматически, измените конфигурацию systemd. Создайте или отредактируйте файл /etc/systemd/system/docker.service.d/override.conf и замените строку ExecStart так, чтобы dockerd запускался с нужными флагами.

После изменения перезагрузите конфигурацию systemd:

sudo systemctl daemon-reload
sudo systemctl restart docker

Важно: открывая порт на 0.0.0.0, вы делаете службу доступной со всех интерфейсов. По возможности ограничьте адрес (например, 192.168.1.10) или используйте firewall.

Creating Your Certificate Authority

Сначала создайте собственный CA, который будет подписывать все серверные и клиентские сертификаты. Выполняйте команды на машине, где вы планируете хранить CA (обычно это сервер или отдельная защищённая машина).

Сгенерируйте приватный ключ CA и публичный сертификат CA с помощью OpenSSL:

# Сгенерировать приватный ключ CA (шифруется паролем)
openssl genrsa -aes256 -out ca-private.pem 4096

# Создать публичный сертификат CA (самоподписанный)
openssl req -new -x509 -days 365 -key ca-private.pem -sha256 -out ca-public.pem

Вы будете запрошены ввести passphrase (пароль для приватного ключа), затем данные субъекта (страна, регион, организация, email и т.д.). Для автоматизации можно использовать параметры -subj, но храните приватный ключ и пароль надёжно.

Скриншот процесса создания CA с OpenSSL

Совет: храните ca-private.pem в офлайн‑хранилище или на машине с очень ограниченным доступом. Если CA будет скомпрометирован, вам придётся перевыпустить все сертификаты.

Generating a Server Key and Certificate Signing Request

Создайте приватный ключ сервера и CSR (запрос на подпись). Проверьте, что значение Common Name (CN) соответствует FQDN сервера, под которым клиенты будут к нему обращаться.

# Сгенерировать приватный ключ сервера
openssl genrsa -out server-key.pem 4096

# Создать запрос на подпись (CSR) — CN должен быть FQDN сервера
openssl req -subj "/CN=example.com" -sha256 -new -key server-key.pem -out server-request.csr

Если вы будете подключаться по IP‑адресу или по нескольким именам, укажите это позже через subjectAltName в файле расширений.

Скриншот генерации ключа сервера TLS

Setting Up Certificate Extensions

Для поддержки дополнительно доменов или IP‑адресов в сертификате используйте расширения X.509 — в частности, subjectAltName и extendedKeyUsage. Создайте файл, который будет содержать нужные поля.

Пример содержания файла extfile.cnf:

subjectAltName = DNS:example.com,DNS:sub.example.com,IP:192.168.0.1
extendedKeyUsage = serverAuth

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

Примечание: современные браузеры и клиенты игнорируют CN, опираясь на subjectAltName. Поэтому обязательно указывайте все нужные имена/адреса в subjectAltName.

Generating a Signed Certificate

Подпишите CSR вашим CA, добавив файл расширений:

openssl x509 -req -days 365 -sha256 \
  -in server-request.csr \
  -CA ca-public.pem \
  -CAkey ca-private.pem \
  -CAcreateserial \
  -extfile extfile.cnf \
  -out server-certificate.pem

Команда создаёт сертификат server-certificate.pem, подписанный вашим CA, который будет действителен 365 дней. При этом вам будет нужно ввести пароль от ca-private.pem.

Скриншот подписи TLS‑сертификата

Планируйте процесс продления заранее: настройте напоминание за 30–60 дней до истечения срока действия.

Generating a Client Certificate

Для клиентов (например, вашей рабочей станции или CI‑сервера) создайте отдельные ключ и сертификат, подписанные тем же CA. Используйте расширения extendedKeyUsage = clientAuth.

# Сгенерировать приватный ключ клиента
openssl genrsa -out client-key.pem 4096

# Создать CSR для клиента
openssl req -subj "/CN=client" -new -key client-key.pem -out client-request.csr

# Файл расширений для клиентского сертификата
echo "extendedKeyUsage = clientAuth" > extfile-client.cnf

# Подписать клиентский сертификат
openssl x509 -req -days 365 -sha256 \
  -in client-request.csr \
  -CA ca-public.pem \
  -CAkey ca-private.pem \
  -CAcreateserial \
  -extfile extfile-client.cnf \
  -out client-certificate.pem

Храните клиентские приватные ключи (client-key.pem) безопасно. При необходимости можно дополнительно защитить их паролем.

Preparing to Configure Docker

Скопируйте сгенерированные файлы в отдельные каталоги:

На сервере Docker: ca-public.pem, server-certificate.pem, server-key.pem.
На каждом клиенте: ca-public.pem, client-certificate.pem, client-key.pem.

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

Краткие рекомендации по правам доступа:

chmod 600 server-key.pem
chmod 644 server-certificate.pem ca-public.pem

Configuring the Docker Daemon

Запустите демона Docker с указанием TLS‑флагов. Параметры --tlscacert, --tlscert и --tlskey указывают на соответствующие файлы:

/usr/bin/dockerd \
  -H unix:///var/run/docker.sock \
  -H tcp://0.0.0.0:2376 \
  --tlsverify \
  --tlscacert=/path/to/ca-public.pem \
  --tlscert=/path/to/server-certificate.pem \
  --tlskey=/path/to/server-key.pem

Флаг --tlsverify включает проверку TLS и требует от клиента наличия корректного сертификата. Если флаг не задан, TLS может использоваться без проверки клиента (односторонняя аутентификация).

После изменения конфигурации перезапустите сервис Docker через systemd (см. выше).

Альтернатива: конфигурация через daemon.json

Вместо длинной строки ExecStart можно указать опции в /etc/docker/daemon.json. Однако некоторые TLS‑опции не поддерживаются напрямую в daemon.json — в таком случае удобнее управлять через systemd‑юнит.

Configuring the Docker Client

При подключении к защищённому демону укажите адрес хоста и TLS‑файлы:

docker \
  -H tcp://server.example.com:2376 \
  --tlsverify \
  --tlscacert=/home/user/.docker/ca-public.pem \
  --tlscert=/home/user/.docker/client-certificate.pem \
  --tlskey=/home/user/.docker/client-key.pem \
  ps

Чтобы не указывать флаги каждый раз, настройте переменные окружения в вашем shell‑профиле и поместите сертификаты в ~/.docker:

export DOCKER_HOST=tcp://server.example.com:2376
export DOCKER_TLS_VERIFY=1

Файлы в ~/.docker должны называться ca.pem, cert.pem, key.pem либо соответствовать опциям --tlscacert, --tlscert, --tlskey.

Docker также поддерживает контексты (contexts), которые позволяют переключаться между разными хостами и профилями.

Варианты проверки TLS

Только --tls — сервер аутентифицируется стандартным пулом CA (системный trust store).
--tlscacert + --tlsverify без клиентского ключа — сервер проверяется по указанному CA, а клиенты не проходят взаимную проверку.
С --tlsverify и клиентским сертификатом — полнофункциональная взаимная (mutual) TLS‑аутентификация.

Продление сертификатов и ротация

Ведите реестр выданных сертификатов и сроков их действия.
Автоматизируйте процесс: скрипт, cron или CI/CD пайплайн, который генерирует новые ключи/CSR и пересылает подписанные сертификаты на сервер и клиенты.
При ротации серверного сертификата перезапустите Docker daemon; при ротации client‑сертификата — обновите файл на клиенте.

Итоговый чек‑лист перед открытием порта в продакшн

CA создан и приватный ключ хранится в безопасном месте
Сертификаты выданы и проверены на соответствие CN/subjectAltName
На сервере установлены ca-public.pem, server-certificate.pem, server-key.pem с корректными правами
Демон Docker запущен с –tlsverify и правильными путями к сертификатам
Клиентам выданы client-certificate.pem и client-key.pem, и они проверены
Ограничен доступ к порту через firewall и/или привязан IP
Настроена ротация/уведомления о сроке действия сертификатов

Чек‑лист ролей

DevOps / Сисадмин:
- Создать CA и держать приватный ключ офлайн
- Подписать серверные сертификаты
- Настроить systemd и firewall
Разработчик/инженер приложений:
- Получить клиентский сертификат
- Настроить локальный docker client/CI для использования TLS
Команда безопасности:
- Аудит прав доступа к ключам
- Мониторинг логов и проверка соответствия политик

Отладка и частые ошибки

Ошибка: “x509: certificate signed by unknown authority”
- Убедитесь, что клиент использует тот же ca-public.pem, которым подписан сервер.
- Проверьте, что путь, переданный в --tlscacert, корректен.
Проблема: имя в сертификате не соответствует хосту
- Убедитесь, что CN или subjectAltName содержит FQDN или IP, используемые клиентом.
Проблема: неправильные права на ключи
- Docker может отказать в загрузке ключа, если права открыты (chmod 600 для приватных ключей).
Нет соединения после включения TLS
- Проверьте, что клиент и сервер используют одинаковые флаги (--tlsverify vs --tls).
- Уточните правила firewall и прослушивание порта через ss -ltnp или netstat -ltnp.

Когда TLS не решит проблему

TLS обеспечивает шифрование и взаимную аутентификацию, но не референтную модель доступа. Для тонкой фильтрации операций используйте авторизационный плагин Docker или reverse proxy с ACL.
Если злоумышленник уже имеет root‑доступ на хосте, TLS не защитит ваши контейнеры.

Пример Playbook / SOP для обновления серверного сертификата

На защищённой машине с CA создайте новый CSR и подпишите его:

openssl genrsa -out new-server-key.pem 4096
openssl req -subj "/CN=example.com" -new -key new-server-key.pem -out new-server-request.csr
openssl x509 -req -days 365 -sha256 -in new-server-request.csr -CA ca-public.pem -CAkey ca-private.pem -CAcreateserial -extfile extfile.cnf -out new-server-certificate.pem

Передайте new-server-certificate.pem и new-server-key.pem на сервер Docker (по защищённому каналу).
На сервере выполните резервное копирование старых файлов, замените их новыми и рестартаньте Docker:

sudo cp server-certificate.pem server-certificate.pem.bak
sudo cp server-key.pem server-key.pem.bak
sudo mv new-server-certificate.pem /etc/docker/server-certificate.pem
sudo mv new-server-key.pem /etc/docker/server-key.pem
sudo systemctl restart docker

Проверить подключение клиента и сервисы.

Пример конфигурации curl

Если нужно обратиться к Docker API напрямую (HTTP over TLS), curl поддерживает те же файлы:

curl --cacert ca-public.pem --cert client-certificate.pem --key client-key.pem https://server.example.com:2376/containers/json

Совместимость, особенности и миграция

Разные версии Docker могут не поддерживать одинаковые опции в daemon.json; systemd‑юнит остаётся универсальным решением.
При миграции на Kubernetes или другой оркестратор планируйте интеграцию управления сертификатами централизованно.

Заключение

Защита Docker API с помощью TLS — обязательный шаг при экспонировании TCP‑порта. TLS обеспечивает шифрование и проверку подлинности, но не заменяет авторизацию и контроль доступа. Комбинируйте TLS с firewall, авторизационными плагинами или обратным прокси для многоуровневой защиты.

Дополнительные действия: автоматизируйте выдачу и продление сертификатов, храните CA‑ключ в защищённом месте, ограничьте интерфейсы прослушивания и мониторьте события доступа.

Ключевые ссылки и примеры команд приведены в теле статьи. Следуйте чек‑листам перед открытием порта в продакшн. Безопасное развёртывание Docker — это сочетание криптографии, минимизации поверхности атаки и надёжной операционной практики.

Защита TCP‑сокета Docker с помощью TLS