[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"question-bezopasnost-konteynerov-kak-zashchitit-docker-daemon":3},{"id":4,"slug":5,"topicId":6,"topicSlug":7,"topicName":8,"topicEmoji":9,"question":10,"answer":11,"codeLang":12,"codeSrc":12,"important":12,"commonMistakes":12,"modernUsage":12,"difficulty":13,"tags":14,"related":20,"progress":21,"seo":22},323,"kak-zashchitit-docker-daemon",9,"bezopasnost-konteynerov","Безопасность контейнеров","🛡️","Как защитить Docker daemon?","\u003C!-- grade: -->\n\nDocker daemon (`dockerd`) работает с правами root и управляет всеми контейнерами на хосте. Компрометация Docker daemon эквивалентна полному контролю над хостом: злоумышленник может запускать произвольные контейнеры, читать данные из любых томов и выполнять команды на хосте. Поэтому защита daemon — одна из приоритетных задач безопасности.\n\n**1. Защита Docker socket:**\n\nПо умолчанию Docker daemon слушает на Unix-сокете `\u002Fvar\u002Frun\u002Fdocker.sock`. Доступ к этому сокету равнозначен root-доступу к хосту, потому что через него можно запустить привилегированный контейнер с монтированием корневой файловой системы хоста.\n\n```bash\n# Проверить права на сокет\nls -la \u002Fvar\u002Frun\u002Fdocker.sock\n# srw-rw---- 1 root docker 0 ... \u002Fvar\u002Frun\u002Fdocker.sock\n\n# Только пользователи группы docker должны иметь доступ\n```\n\n**Категорически запрещено** монтировать Docker socket в production-контейнеры:\n\n```yaml\n# ОПАСНО! Даёт контейнеру полный контроль над Docker daemon\nvolumes:\n  - \u002Fvar\u002Frun\u002Fdocker.sock:\u002Fvar\u002Frun\u002Fdocker.sock\n```\n\nЕсли монтирование сокета необходимо (например, для CI runner), используйте read-only монтирование и авторизационные плагины для ограничения доступных операций.\n\n**2. Включение TLS для удалённого доступа:**\n\nЕсли Docker daemon должен быть доступен по сети (например, для удалённого управления), обязательна настройка mutual TLS (mTLS) — проверка и серверного, и клиентского сертификатов.\n\n```bash\n# Генерация CA (Certificate Authority)\nopenssl genrsa -aes256 -out ca-key.pem 4096\nopenssl req -new -x509 -days 365 -key ca-key.pem -sha256 -out ca.pem\n\n# Генерация серверного ключа и сертификата\nopenssl genrsa -out server-key.pem 4096\nopenssl req -subj \"\u002FCN=docker-host.bank.local\" -sha256 \\\n    -new -key server-key.pem -out server.csr\n\necho subjectAltName = DNS:docker-host.bank.local,IP:10.0.1.100 >> extfile.cnf\necho extendedKeyUsage = serverAuth >> extfile.cnf\nopenssl x509 -req -days 365 -sha256 \\\n    -in server.csr -CA ca.pem -CAkey ca-key.pem \\\n    -CAcreateserial -out server-cert.pem -extfile extfile.cnf\n\n# Генерация клиентского ключа и сертификата\nopenssl genrsa -out client-key.pem 4096\nopenssl req -subj '\u002FCN=client' -new -key client-key.pem -out client.csr\necho extendedKeyUsage = clientAuth > extfile-client.cnf\nopenssl x509 -req -days 365 -sha256 \\\n    -in client.csr -CA ca.pem -CAkey ca-key.pem \\\n    -CAcreateserial -out client-cert.pem -extfile extfile-client.cnf\n```\n\n**3. Безопасная конфигурация daemon.json:**\n\n```json\n{\n  \"tls\": true,\n  \"tlscacert\": \"\u002Fetc\u002Fdocker\u002Fcerts\u002Fca.pem\",\n  \"tlscert\": \"\u002Fetc\u002Fdocker\u002Fcerts\u002Fserver-cert.pem\",\n  \"tlskey\": \"\u002Fetc\u002Fdocker\u002Fcerts\u002Fserver-key.pem\",\n  \"tlsverify\": true,\n  \"hosts\": [\"unix:\u002F\u002F\u002Fvar\u002Frun\u002Fdocker.sock\", \"tcp:\u002F\u002F0.0.0.0:2376\"],\n  \"icc\": false,\n  \"userns-remap\": \"default\",\n  \"no-new-privileges\": true,\n  \"live-restore\": true,\n  \"userland-proxy\": false,\n  \"log-driver\": \"json-file\",\n  \"log-opts\": {\n    \"max-size\": \"10m\",\n    \"max-file\": \"3\"\n  },\n  \"default-ulimits\": {\n    \"nofile\": {\n      \"Name\": \"nofile\",\n      \"Hard\": 64000,\n      \"Soft\": 64000\n    }\n  }\n}\n```\n\nНазначение ключевых параметров:\n\n| Параметр | Значение | Описание |\n|----------|----------|----------|\n| `tlsverify: true` | Обязательная mTLS | Клиент должен предоставить сертификат, подписанный доверенным CA. Без этого параметра любой может подключиться к daemon |\n| `icc: false` | Запрет Inter-Container Communication | Контейнеры в одной bridge-сети не смогут общаться друг с другом напрямую — только через явно опубликованные порты (--link или docker network) |\n| `userns-remap: default` | Маппинг user namespace | UID 0 (root) внутри контейнера маппится на непривилегированный UID на хосте (например, 100000). Даже при побеге из контейнера атакующий не получит root на хосте |\n| `no-new-privileges: true` | Запрет повышения привилегий | Блокирует setuid\u002Fsetgid-бинарники и другие механизмы повышения привилегий |\n| `live-restore: true` | Сохранение контейнеров при перезапуске daemon | Контейнеры продолжают работать, даже если Docker daemon перезапускается (важно для обновлений без простоя) |\n| `userland-proxy: false` | Отключение userland-proxy | Использование iptables вместо docker-proxy для маршрутизации портов — эффективнее и безопаснее |\n\n**4. Docker Authorization Plugin:**\n\n```json\n{\n  \"authorization-plugins\": [\"casbin-authz-plugin\"]\n}\n```\n\nAuthorization plugin — это webhook, который перехватывает каждый запрос к Docker daemon и применяет политики авторизации. Позволяет определять гранулярные правила: кто может запускать контейнеры, с какими параметрами (например, запретить `--privileged` или монтирование `\u002F` хоста). Это особенно важно в средах с несколькими пользователями Docker.\n\n**5. Rootless Docker:**\n\n```bash\n# Установка rootless Docker\ndockerd-rootless-setuptool.sh install\n\n# Docker daemon работает от обычного пользователя\nexport DOCKER_HOST=unix:\u002F\u002F\u002Frun\u002Fuser\u002F1000\u002Fdocker.sock\n```\n\nRootless Docker полностью исключает работу daemon от root — и сам daemon, и все контейнеры работают в user namespace непривилегированного пользователя. Это радикально снижает риск при компрометации daemon, но имеет ограничения: нельзя использовать некоторые storage drivers (overlay2 требует fuse-overlayfs), нет привязки к портам ниже 1024 без дополнительных настроек, невозможно использовать cgroup v1.\n\n**6. Ограничение логов (защита от заполнения диска):**\n\n```json\n{\n  \"log-driver\": \"json-file\",\n  \"log-opts\": {\n    \"max-size\": \"10m\",\n    \"max-file\": \"3\"\n  }\n}\n```\n\nБез ограничений логи контейнера могут заполнить весь диск хоста, что приведёт к отказу в обслуживании всех контейнеров. Параметр `max-size` ограничивает размер одного файла лога, а `max-file` — количество ротируемых файлов. В данном примере максимальный объём логов на контейнер — 30 MB (3 файла по 10 MB).","","middle",[15,16,17,18,19],"rootless-docker","tls","container-security","daemon","docker",[],null,{"title":23,"description":24,"ogTitle":23,"ogDescription":25,"keywords":26,"schemaAnswer":34,"featuredSnippetReady":35},"Защита Docker daemon: TLS, rootless, authorization plugins — Gymterview","Как защитить Docker daemon? Защита Docker socket, настройка TLS для удалённого доступа, daemon.json параметры безопасности, Authorization Plugin, Rootless Docker.","Защита Docker daemon: настройка TLS, ограничение доступа к socket, параметры daemon.json (icc, userns-remap, no-new-privileges), Rootless Docker.",[27,28,29,30,31,32,33],"Docker daemon безопасность","Docker socket защита","Docker TLS","daemon.json","Rootless Docker","Docker authorization plugin","userns-remap","Docker daemon работает с правами root, и его компрометация означает полный контроль над хостом. Защита включает: ограничение доступа к Docker socket (не монтировать в контейнеры); настройку TLS с клиентскими сертификатами для удалённого доступа; конфигурацию daemon.json — tlsverify, icc: false (запрет межконтейнерного взаимодействия), userns-remap (маппинг UID), no-new-privileges; использование Authorization Plugin для политик доступа; Rootless Docker — запуск daemon от обычного пользователя; ограничение логов через max-size и max-file.",true]