Поделиться через

Базовые настройки безопасности Docker

Внимание

Эта статья ссылается на CentOS, дистрибутив Linux, который является состоянием "Конец жизни" (EOL). Пожалуйста, рассмотрите возможность использования и планирования соответствующим образом. Дополнительные сведения см. в руководстве centOS End Of Life.

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

  • [Предварительная версия]: компьютеры под управлением Linux должны соответствовать требованиям базовой конфигурации безопасности Azure для узлов Docker
  • Уязвимости конфигурации безопасности на ваших компьютерах должны быть устранены в Центре безопасности Azure.

Дополнительные сведения см. в разделах Общие сведения о функции настройки гостевых систем в рамках политики Azure и Обзор производительности системы безопасности Azure (версия 2).

Общие средства управления безопасностью

Имя.
(CCEID)		 Сведения Проверка исправления
Инвентарные сведения о Docker
(0.0)		 Описание: нет нет
Убедитесь, что был создан отдельный раздел для контейнеров
(1.01)		 Описание: Docker зависит от /var/lib/docker в качестве каталога по умолчанию, в котором хранятся все связанные файлы Docker, включая образы. Этот каталог может быстро заполниться, и вскоре Docker и узел могут стать непригодными для использования. Поэтому для хранения файлов Docker рекомендуется создать отдельный раздел (логический том). Для новых установок создайте отдельный раздел для точки подключения /var/lib/docker. Для систем, которые были установлены ранее, используйте для создания разделов диспетчер логических томов (LVM).
Убедитесь, что версия Docker актуальна
(1.03)		 Описание. Использование актуальной версии Docker обеспечит безопасность узла Сведения по обновлению версии содержатся в документации к Docker
Убедитесь, что аудит настроен для управляющей программы Docker
(1.05)		 Описание. Помимо аудита обычных вызовов файловой системы Linux и системных вызовов проверьте управляющую программу Docker. Управляющая программа Docker выполняется с правами привилегированного пользователя. Следовательно, необходимо провести аудит его деятельности и использования. Добавьте строку -w /usr/bin/docker -k docker в файл /etc/audit/audit.rules. Затем перезапустите управляющую программу аудита, выполнив следующую команду: service auditd restart
Убедитесь, что аудит настроен для файлов и каталогов Docker — /var/lib/docker
(1.06)		 Описание. Помимо аудита обычных вызовов файловой системы Linux и системных вызовов необходимо выполнить аудит всех связанных файлов и каталогов Docker. Управляющая программа Docker выполняется с правами привилегированного пользователя. Ее поведение зависит от некоторых ключевых файлов и каталогов. /var/lib/docker — один из таких каталогов. Он содержит всю информацию о контейнерах. Необходимо выполнить его аудит. Добавьте строку -w /var/lib/docker -k docker в файл /etc/audit/audit.rules. Затем перезапустите управляющую программу аудита, выполнив следующую команду: service auditd restart
Убедитесь, что аудит настроен для файлов и каталогов Docker — /etc/docker
(1.07)		 Описание. Помимо аудита обычных вызовов файловой системы Linux и системных вызовов необходимо выполнить аудит всех связанных файлов и каталогов Docker. Управляющая программа Docker выполняется с правами привилегированного пользователя. Ее поведение зависит от некоторых ключевых файлов и каталогов. /etc/docker — один из таких каталогов. Он содержит различные сертификаты и ключи, используемые для связи TLS между управляющей программой Docker и клиентом Docker. Необходимо выполнить его аудит. Добавьте строку -w /etc/docker -k docker в файл /etc/audit/audit.rules. Затем перезапустите управляющую программу аудита, выполнив следующую команду: service auditd restart
Убедитесь, что аудит настроен для файлов и каталогов Docker — docker.service
(1.08)		 Описание. Помимо аудита обычных вызовов файловой системы Linux и системных вызовов необходимо выполнить аудит всех связанных файлов и каталогов Docker. Управляющая программа Docker выполняется с правами привилегированного пользователя. Ее поведение зависит от некоторых ключевых файлов и каталогов. Docker.service — один из таких файлов. Файл docker.service может присутствовать, если параметры управляющей программы были изменены администратором. Он содержит различные параметры для управляющей программы Docker. Если применимо, его необходимо проверить. Уточните расположение файла docker.service, выполнив команду systemctl show -p FragmentPath docker.service, и добавьте строку -w {docker.service file location} -k docker в файл /etc/audit/audit.rules, где {docker.service file location} — путь к файлу, который вы уточнили выше. Перезапустите управляющую программу аудита, выполнив следующую команду: service auditd restart
Убедитесь, что аудит настроен для файлов и каталогов Docker — docker.service
(1.09)		 Описание. Помимо аудита обычных вызовов файловой системы Linux и системных вызовов необходимо выполнить аудит всех связанных файлов и каталогов Docker. Управляющая программа Docker выполняется с правами привилегированного пользователя. Ее поведение зависит от некоторых ключевых файлов и каталогов. Docker.socket является одним из таких файлов. Он содержит различные параметры для сокета управляющей программы Docker. Если применимо, его необходимо проверить. Уточните расположение файла docker.socket, выполнив команду systemctl show -p FragmentPath docker.socket, и добавьте строку -w {docker.socket file location} -k docker в файл /etc/audit/audit.rules, где {docker.socket file location} — путь к файлу, который вы уточнили выше. Перезапустите управляющую программу аудита, выполнив следующую команду: service auditd restart
Убедитесь, что аудит настроен для файлов и каталогов Docker — /etc/default/docker
(1.10)		 Описание. Помимо аудита обычных вызовов файловой системы Linux и системных вызовов необходимо выполнить аудит всех связанных файлов и каталогов Docker. Управляющая программа Docker выполняется с правами привилегированного пользователя. Ее поведение зависит от некоторых ключевых файлов и каталогов. /etc/default/docker является одним из таких файлов. Он содержит различные параметры для управляющей программы Docker. Если применимо, его необходимо проверить. Добавьте строку -w /etc/default/docker -k docker в файл /etc/audit/audit.rules. Затем перезапустите управляющую программу аудита, выполнив следующую команду: service auditd restart
Убедитесь, что аудит настроен для файлов и каталогов Docker — /etc/docker/daemon.json
(1.11)		 Описание. Помимо аудита обычных вызовов файловой системы Linux и системных вызовов необходимо выполнить аудит всех связанных файлов и каталогов Docker. Управляющая программа Docker выполняется с правами привилегированного пользователя. Ее поведение зависит от некоторых ключевых файлов и каталогов. /etc/docker/daemon.json является одним из таких файлов. Он содержит различные параметры для управляющей программы Docker. Если применимо, его необходимо проверить. Добавьте строку -w /etc/docker/daemon.json -k docker в файл /etc/audit/audit.rules. Затем перезапустите управляющую программу аудита, выполнив следующую команду: service auditd restart
Убедитесь, что аудит настроен для файлов и каталогов Docker — /usr/bin/docker-containerd
(1.12)		 Описание. Помимо аудита обычных вызовов файловой системы Linux и системных вызовов необходимо выполнить аудит всех связанных файлов и каталогов Docker. Управляющая программа Docker выполняется с правами привилегированного пользователя. Ее поведение зависит от некоторых ключевых файлов и каталогов. /usr/bin/docker-containerd является одним из таких файлов. Docker теперь использует для создания контейнеров containerd и runC. Если применимо, его необходимо проверить. Добавьте строку -w /usr/bin/docker-containerd -k docker в файл /etc/audit/audit.rules. Затем перезапустите управляющую программу аудита, выполнив следующую команду: service auditd restart
Убедитесь, что аудит настроен для файлов и каталогов Docker — /usr/bin/docker-runc
(1.13)		 Описание. Помимо аудита обычных вызовов файловой системы Linux и системных вызовов необходимо выполнить аудит всех связанных файлов и каталогов Docker. Управляющая программа Docker выполняется с правами привилегированного пользователя. Ее поведение зависит от некоторых ключевых файлов и каталогов. /usr/bin/docker-runc является одним из таких файлов. Docker теперь использует для создания контейнеров containerd и runC. Если применимо, его необходимо проверить. Добавьте строку -w /usr/bin/docker-runc -k docker в файл /etc/audit/audit.rules. Затем перезапустите управляющую программу аудита, выполнив следующую команду: service auditd restart
Убедитесь, что сетевой трафик ограничен контейнерами на мосте по умолчанию
(2.01)		 Описание. Межконтейнерное взаимодействие будет отключено на сетевом мосте по умолчанию. Если требуется какой-либо обмен данными между контейнерами на одном узле, необходимо явно определить его, используя связывание контейнеров, или определить пользовательские сети. Запустите Docker в режиме управляющей программы и передайте --icc=false в качестве аргумента или задайте для параметра icc значение false в файле daemon.json. Кроме того, вы можете выполнить инструкции в документации Docker, создать пользовательскую сеть и присоединить только контейнеры, которые должны взаимодействовать с этой пользовательской сетью. Параметр --icc применяется только к мосту Docker по умолчанию. Если используются пользовательские сети, вместо этого следует применить сегментирование сетей.
Убедитесь, что для уровня ведения журнала задано значение info.
(2.02)		 Описание. Настройка соответствующего уровня журнала настраивает управляющую программу Docker для регистрации событий, которые требуется просмотреть позже. Базовый уровень журнала info и выше будет записывать все журналы, кроме журналов отладки. Управляющую программу Docker следует выполнять на уровне журнала debug только в случае необходимости. Запустите управляющую программу Docker, как показано ниже: dockerd --log-level info
Убедитесь, что Docker может вносить изменения в iptables
(2.03)		 Описание: Docker никогда не будет вносить изменения в системные правила iptables, если вы решили это сделать. Сервер Docker будет автоматически вносить необходимые изменения в iptables в зависимости от способа выбора сетевых параметров для контейнеров, если это разрешено. Рекомендуется разрешить серверу Docker вносить изменения в iptables автоматически, чтобы избежать неправильной настройки сети, что может препятствовать обмену данными между контейнерами и внешним миром. Кроме того, при каждом запуске контейнеров или изменении параметров сети вы сможете сэкономить время и силы на обновление iptable. Не запускайте управляющую программу Docker с параметром --iptables=false. Например, не запускайте управляющую программу Docker, как показано ниже: dockerd --iptables=false
Убедитесь, что небезопасные реестры не используются
(2.04)		 Описание. Не следует использовать небезопасные реестры в рабочей среде. В небезопасные реестры могут быть внесены нежелательные изменения, в результате чего функционирование рабочей системы может быть нарушено. Удаление флага --insecure-registry из команды dockerd start
Драйвер хранилища aufs не должен использоваться управляющей программой Docker
(2.05)		 Описание. Драйвер хранилища aufs является самым старым драйвером хранилища. Он основан на наборе исправлений ядра Linux, который вряд ли будет объединен в основное ядро Linux. Драйвер aufs также известен тем, что может вызывать некоторые серьезные сбои ядра. aufs пользуется только устаревшей поддержкой Docker. Самое главное, aufs не является поддерживаемым драйвером во многих дистрибутивах Linux с использованием последних ядер Linux Драйвер хранилища aufs должен быть заменен другим драйвером хранилища, рекомендуется использовать overlay2.
Убедитесь, что настроена проверка подлинности TLS для управляющей программы Docker
(2.06)		 Описание. По умолчанию управляющая программа Docker привязывается к несетевому сокету Unix и выполняется с привилегиями root. При изменении привязки управляющей программы Docker по умолчанию к TCP-порту или любому другому сокету Unix любой пользователь с доступом к такому порту или сокету может иметь полный доступ к управляющей программе Docker и, в свою очередь, к системе размещения. Поэтому управляющая программа Docker не должна быть привязана к другому IP-порту или сокету Unix. Если необходимо предоставить управляющую программу Docker через сетевой сокет, настройте проверку подлинности TLS для управляющей программы и API Docker Swarm (если они используются). Это приведет к ограничению подключений к управляющей программе Docker по сети до определенного числа клиентов, которые смогли успешно пройти проверку подлинности по протоколу TLS. Выполните действия, описанные в документации Docker или другой справочной документации.
Убедитесь, что параметр ulimit по умолчанию настроен соответствующим образом.
(2.07)		 Описание. Если ulimits не заданы должным образом, возможно, требуемый элемент управления ресурсами не будет достигнут и может даже сделать систему непригодной для использования. Запустите Docker в режиме управляющей программы и передайте --default-ulimit в качестве аргумента с параметрами ulimits, соответствующими вашей среде. Кроме того, можно задать определенное ограничение ресурсов для каждого контейнера по отдельности, используя аргумент --ulimit с параметрами ulimits, соответствующими вашей среде.
Включение поддержки пользовательского пространства имен
(2.08)		 Описание. Поддержка пользовательского пространства имен ядра Linux в управляющей программе Docker обеспечивает дополнительную безопасность для системы размещения Docker. Это позволяет контейнеру иметь уникальный диапазон идентификаторов пользователей и групп, которые находятся за пределами традиционного диапазона пользователей и групп, используемых в системе размещения. Например, корневой пользователь будет иметь ожидаемые права администратора в контейнере, но может быть сопоставлен непривилегированному пользовательскому идентификатору в системе размещения. Сведения о различных способах настройки в зависимости от ваших требований содержатся в документации по Docker. Действия также могут различаться в зависимости от платформы. Например, в Red Hat, создание сопоставлений вложенных идентификаторов пользователя и вложенных идентификаторов GID не выполняется автоматически. Возможно, потребуется создать собственное сопоставление. Однако общие шаги приведены ниже: Шаг 1. Убедитесь, что файлы /etc/subuid и /etc/subgid существуют.touch /etc/subuid /etc/subgidШаг 2. Запустите управляющую программу Docker с флагом --userns-remapdockerd --userns-remap=default
Убедитесь, что базовый размер устройства не изменяется до тех пор, пока не потребуется
(2.10)		 Описание. Увеличение базового размера устройства позволяет присвоить всем будущим образам и контейнерам новый базовый размер устройства. Это может привести к отказу в обслуживании из-за выделения всех или даже избыточных ресурсов системы. Удалите флаг --storage-opt dm.basesize из команды dockerd start, пока он не потребуется.
Убедитесь, что авторизация для команд клиента Docker включена.
(2.11)		 Описание. Готовая модель авторизации Docker не допускает компромиссов. Любой пользователь с разрешением на доступ к управляющей программе Docker может выполнить любую команду клиента Docker. То же самое верно для вызывающих абонентов, использующих удаленный API Docker для связи с управляющей программой. Если требуется более широкий контроль доступа, можно создать подключаемые модули авторизации и добавить их в конфигурацию управляющей программы Docker. С помощью подключаемого модуля авторизации администратор Docker может настроить детализированные политики доступа для управления доступом к управляющей программе Docker. Сторонние интеграции Docker могут реализовать собственные модели авторизации, чтобы требовать авторизации в управляющей программе Docker за пределами собственного подключаемого модуля авторизации Docker (т. е. Kubernetes, Cloud Foundry, OpenShift). Шаг 1. Установите/Создайте подключаемый модуль авторизации. Шаг 2. Настройте политику авторизации должным образом. Шаг 3. Запустите управляющую программу Docker, как показано ниже: dockerd --authorization-plugin=
Убедитесь, что настроено централизованное и удаленное ведение журнала
(2.12)		 Описание. Централизованное и удаленное ведение журнала гарантирует, что, несмотря на катастрофические события, все важные записи журнала остаются в безопасности. Docker теперь поддерживает различные драйверы ведения журнала. Используйте тот, который подходит для вашей среды лучше всего. Шаг 1. Настройте желаемый драйвер журнала, следуя инструкциям в документации. Шаг 2. Запустите управляющую программу Docker с соответствующим драйвером ведения журнала. Например: dockerd --log-driver=syslog --log-opt syslog-address=tcp://192.xxx.xxx.xxx
Убедитесь, что динамическое восстановление включено
(2.14)		 Описание. Одним из важных аспектов безопасности является доступность. Настройка флага --live-restore в управляющей программе Docker гарантирует, что выполнение контейнера не прерывается, если управляющая программа Docker недоступна. Это также означает, что теперь обновлять и исправлять управляющую программу Docker стало проще, без прерывания процесса выполнения.нения. Запустите Docker в режиме управляющей программы и передайте --live-restore в качестве аргумента. Например, dockerd --live-restore.
Убедитесь, что прокси-сервер Userland отключен
(2.15)		 Описание. Подсистема Docker предоставляет два механизма переадресации портов с узла на контейнеры, шпильку NAT и прокси-сервер Userland. В большинстве случаев режим шпильки NAT предпочтительнее, так как он повышает производительность и использует собственные функции IPTables Linux вместо дополнительного компонента. Если доступна шпилька NAT, прокси-сервер Userland следует отключить во время запуска, чтобы уменьшить поверхность атаки установки. Запустите управляющую программу Docker, как показано ниже: dockerd --userland-proxy=false
Убедитесь, что экспериментальные функции не используются в рабочей среде
(2.17)		 Описание. Экспериментальные функции теперь представляют собой флаг управляющей программы Docker в среде выполнения, а не отдельную сборку. Передача --experimental в качестве флага среды выполнения в управляющую программу Docker активирует экспериментальные функции. Экспериментальные функции теперь считаются стабильным выпуском, однако пара функций не была протестирована, стабильность API не гарантируется. Не передавайте --experimental в управляющую программу Docker в качестве параметра среды выполнения.
Убедитесь, что возможность получения новых привилегий контейнерами ограничена.
(2.18)		 Описание. Процесс может задать бит no_new_priv в ядре. Он сохраняется в вилке, клонировании и файле execve. Бит no_new_priv гарантирует, что процесс или его дочерние процессы не получают дополнительных привилегий с помощью битов suid или sgid. Следовательно, многочисленные опасные операции становятся гораздо менее опасными, потому что нет возможности испортить привилегированные двоичные файлы. Установка этого параметра на уровне управляющей программы гарантирует, что по умолчанию все новые контейнеры ограничены в получении новых привилегий. Запустите управляющую программу Docker, как показано ниже: dockerd --no-new-privileges
Убедитесь, что для параметра владения файлом docker.service задано значение root:root.
(3.01)		 Описание. Файл docker.service содержит конфиденциальные параметры, которые могут изменить поведение управляющей программы Docker. Таким образом, для сохранения целостности файла он должен принадлежать root (в том числе в составе группы). Шаг 1. Узнайте расположение файла: шаг 2. systemctl show -p FragmentPath docker.service Если файл не существует, эта рекомендация не применима. Если файл существует, выполните приведенную ниже команду, указав правильный путь к файлу, чтобы задать владельца и владельца группы для файла root. Например: chown root:root /usr/lib/systemd/system/docker.service
Убедитесь, что для файла docker.service количество разрешений ограничено 644 или еще меньшим числом.
(3.02)		 Описание. Файл docker.service содержит конфиденциальные параметры, которые могут изменить поведение управляющей программы Docker. Следовательно, для сохранения целостности файла возможность записи в файл должна быть только у пользователя root. Шаг 1. Узнайте расположение файла: шаг 2. systemctl show -p FragmentPath docker.service Если файл не существует, эта рекомендация не применима. Если файл существует, выполните приведенную ниже команду, указав правильный путь к файлу, чтобы задать разрешения для файла 644. Например: chmod 644 /usr/lib/systemd/system/docker.service
Убедитесь, что для параметра владения файлом docker.socket задано значение root:root.
(3.03)		 Описание. Файл docker.socket содержит конфиденциальные параметры, которые могут изменить поведение удаленного API Docker. Таким образом, для сохранения целостности файла он должен принадлежать root (в том числе в составе группы). Шаг 1. Узнайте расположение файла: шаг 2. systemctl show -p FragmentPath docker.socket Если файл не существует, эта рекомендация не применима. Если файл существует, выполните приведенную ниже команду, указав правильный путь к файлу, чтобы задать владельца и владельца группы для файла root. Например: chown root:root /usr/lib/systemd/system/docker.socket
Убедитесь, что для файла .docker.socket количество разрешений ограничено 644 или еще меньшим числом
(3.04)		 Описание. Файл docker.socket содержит конфиденциальные параметры, которые могут изменить поведение управляющей программы Docker. Следовательно, для сохранения целостности файла возможность записи в файл должна быть только у пользователя root. Шаг 1. Узнайте расположение файла: шаг 2. systemctl show -p FragmentPath docker.socket Если файл не существует, эта рекомендация не применима. Если файл существует, выполните приведенную ниже команду, указав правильный путь к файлу, чтобы задать разрешения для файла 644. Например: chmod 644 /usr/lib/systemd/system/docker.service
Убедитесь, что владение каталогом /etc/docker задано равным root:root.
(3.05)		 Описание. Каталог /etc/docker помимо различных конфиденциальных файлов содержит сертификаты и ключи. Таким образом, для сохранения целостности каталога он должен принадлежать root (в том числе в составе группы). chown root:root /etc/docker В результате владение (в том числе в составе группы) каталогом будет задано равным root.
Убедитесь, что количество разрешений для каталога /etc/docker ограничено 755 или еще меньшим числом.
(3.06)		 Описание. Каталог /etc/docker помимо различных конфиденциальных файлов содержит сертификаты и ключи. Следовательно, для сохранения целостности каталога возможность записи должна быть только у пользователя root. chmod 755 /etc/docker В результате разрешения для каталога будут заданы равными 755.
Убедитесь, что для параметра владения файлом сертификата реестра задано значение root:root.
(3.07)		 Описание. Каталог /etc/docker/certs.d/ содержит сертификаты реестра Docker. Для сохранения целостности сертификатов эти файлы сертификатов должны принадлежать (в том числе в составе группы) root. chown root:root /etc/docker/certs.d//* В результате владение (в том числе в составе группы) файлами сертификата реестра будет задано равным root.
Убедитесь, что количество разрешений для файла сертификата реестра ограничено 444 или еще меньшим числом.
(3.08)		 Описание. Каталог /etc/docker/certs.d/ содержит сертификаты реестра Docker. Для сохранения целостности сертификатов эти файлы сертификатов должны иметь разрешения 444. chmod 444 /etc/docker/certs.d//* В результате разрешения для файлов сертификата реестра будут заданы равными 444.
Убедитесь, что для параметра владения файлом сертификата ЦС TLS задано значение root:root.
(3.09)		 Описание. Файл сертификата ЦС TLS должен быть защищен от любых незаконных изменений. Он используется для проверки подлинности сервера Docker на основе заданного сертификата ЦС. Таким образом, для сохранения целостности сертификата ЦС он должен принадлежать root (в том числе в составе группы). chown root:root В результате владение (в том числе в составе группы) файлом сертификата ЦС TLS будет задано равным root.
Убедитесь, что количество разрешений для файла сертификата ЦС TLS ограничено 444 или еще меньшим числом.
(3.10)		 Описание. Файл сертификата ЦС TLS должен быть защищен от любых незаконных изменений. Он используется для проверки подлинности сервера Docker на основе заданного сертификата ЦС. Следовательно, для сохранения целостности сертификата ЦС он должен иметь разрешения 444. chmod 444 В результате разрешения файла сертификата ЦС TLS будут заданы равными 444.
Убедитесь, что для параметра владения файлом сертификата сервера Docker задано значение root:root.
(3.11)		 Описание. Файл сертификата сервера Docker должен быть защищен от любых незаконных изменений. Он используется для проверки подлинности сервера Docker на основе заданного сертификата сервера. Таким образом, для сохранения целостности сертификата он должен принадлежать root (в том числе в составе группы). chown root:root В результате владение (в том числе в составе группы) файлом сертификата сервера Docker будет задано равным root.
Убедитесь, что количество разрешений для файла сертификата сервера Docker ограничено 444 или еще меньшим числом.
(3.12)		 Описание. Файл сертификата сервера Docker должен быть защищен от любых незаконных изменений. Он используется для проверки подлинности сервера Docker на основе заданного сертификата сервера. Следовательно, для сохранения целостности сертификата он должен иметь разрешения 444. chmod 444 Для этого разрешения для файла сервера Docker должны быть заданы равными 444.
Убедитесь, что для параметра владения файлом ключа сертификата сервера Docker задано значение root:root.
(3.13)		 Описание. Файл ключа сертификата сервера Docker должен быть защищен от любых незаконных изменений или считываний, в которых нет необходимости. Он содержит закрытый ключ для сертификата сервера Docker. Таким образом, для сохранения целостности сертификата сервера Docker он должен принадлежать root (в том числе в составе группы). chown root:root В результате владение (в том числе в составе группы) файлом ключа сертификата сервера Docker будет задано равным root.
Убедитесь, что количество разрешений для файла ключа сертификата сервера Docker задано равным 400.
(3.14)		 Описание. Файл ключа сертификата сервера Docker должен быть защищен от любых незаконных изменений или считываний, в которых нет необходимости. Он содержит закрытый ключ для сертификата сервера Docker. Следовательно, для сохранения целостности сертификата сервера Docker он должен иметь разрешения 400. chmod 400 Это позволит задать разрешения для файла ключа сертификата сервера Docker равными 400.
Убедитесь, что для параметра владения файлом сокета Docker задано значение root:docker.
(3.15)		 Описание. Управляющая программа Docker выполняется как root. Поэтому сокет Unix по умолчанию должен принадлежать root. Если какой-либо другой пользователь или процесс владеет этим сокетом, такой непривилегированный пользователь или процесс может взаимодействовать с управляющей программой Docker. Кроме того, такой не привилегированный пользователь или процесс могут взаимодействовать с контейнерами. Это небезопасное и нежелательное поведение. Кроме того, установщик Docker создает группу Unix с именем docker. Можно добавить пользователей в эту группу, а затем эти пользователи смогут считывать и осуществлять запись в сокет Docker Unix по умолчанию. Членство в группе docker строго контролируется системным администратором. Если какая-либо другая группа владеет этим сокетом, участники такой группы смогут взаимодействовать с управляющей программой Docker. Кроме того, такая группа может контролироваться не так строго, как группа docker. Это небезопасное и нежелательное поведение. Таким образом, для сохранения целостности файла сокета файл сокета Docker Unix по умолчанию должен принадлежать root (в том числе docker в составе группы). chown root:docker /var/run/docker.sock В результате файл сокета Docker по умолчанию будет принадлежать root и docker в составе группы.
Убедитесь, что количество разрешений для файла сокета Docker ограничено 660 или еще меньшим числом
(3.16)		 Описание. Разрешение на считывание и запись в сокет Docker Unix по умолчанию следует предоставить только root и участникам группы docker. Таким образом, количество разрешений для файла сокета Docket должно быть ограничено 660 или меньшим числом. chmod 660 /var/run/docker.sock В результате разрешения для файла сокета Docker будут заданы равными 660.
Убедитесь, что для параметра владения файлом daemon.json задано значение root:root
(3.17)		 Описание. Файл daemon.json содержит конфиденциальные параметры, которые могут изменить поведение управляющей программы Docker. Таким образом, для сохранения целостности файла он должен принадлежать root (в том числе в составе группы). chown root:root /etc/docker/daemon.json В результате владение (в том числе в составе группы) файлом будет задано равным root.
Убедитесь, что количество разрешений для файла daemon.json ограничено 644 или меньшим числом.
(3.18)		 Описание. Файл daemon.json содержит конфиденциальные параметры, которые могут изменить поведение управляющей программы Docker. Следовательно, для сохранения целостности файла возможность записи должна быть только у пользователя root. chmod 644 /etc/docker/daemon.json В результате разрешения для этого файла будут заданы равными 644.
Убедитесь, что для параметра владения файлом /etc/default/docker задано значение root:root
(3.19)		 Описание. Файл /etc/default/docker содержит конфиденциальные параметры, которые могут изменить поведение управляющей программы Docker. Таким образом, для сохранения целостности файла он должен принадлежать root (в том числе в составе группы). chown root:root /etc/default/docker В результате владение (в том числе в составе группы) файлом будет задано равным root.
Убедитесь, что для файла /etc/default/docker количество разрешений ограничено 644 или еще меньшим числом.
(3.20)		 Описание. Файл /etc/default/docker содержит конфиденциальные параметры, которые могут изменить поведение управляющей программы Docker. Следовательно, для сохранения целостности файла возможность записи должна быть только у пользователя root. chmod 644 /etc/default/docker В результате разрешения для этого файла будут заданы равными 644.
Убедитесь, что создан пользователь для контейнера
(4.01)		 Описание. По возможности рекомендуется запускать контейнер от имени пользователя, не являющегося корневым. Несмотря на то что сейчас доступно сопоставление пользовательских пространств имен, если пользователь уже определен в образе контейнера, контейнер запускается от имени такого пользователя по умолчанию, повторное сопоставление определенных пользовательских пространств имен не требуется. Убедитесь, что файл Dockerfile для образа контейнера содержит USER {username or ID}, где имя пользователя или идентификатор ссылается на пользователя, которого можно найти в базовом образе контейнера. Если в базовом образе контейнера не создан конкретный пользователь, добавьте перед инструкцией USER команду useradd, чтобы добавить конкретного пользователя.
Убедитесь, что инструкции HEALTHCHECK добавлены в образ контейнера
(4.06)		 Описание. Одним из важных аспектов безопасности является доступность. Добавление инструкции HEALTHCHECK в образ контейнера гарантирует, что подсистема Docker периодически проверяет запущенные экземпляры контейнеров на соответствие этой инструкции, чтобы убедиться, что экземпляры по-прежнему работают. В зависимости от зафиксированного состояния работоспособности подсистема Docker может выйти из нерабочих контейнеров и создать экземпляры новых. Перестройте образ контейнера с инструкцией HEALTHCHECK, следуя указаниям из документации к Docker.
Убедитесь, что функция SELinux или AppArmor включена должным образом.
(5.01-2)		 Описание. AppArmor защищает ОС Linux и приложения от различных угроз, применяя политику безопасности, которая также называется профилем AppArmor. Можно создать собственный профиль AppArmor для контейнеров или использовать профиль AppArmor (профиль Docker по умолчанию). Это приведет к принудительному применению политик безопасности для контейнеров, как определено в профиле. SELinux предоставляет систему обязательного контроля доступа (MAC), которая значительно расширяет модель контроля доступа на уровне пользователей (DAC), используемую по умолчанию. Таким образом, вы можете добавить дополнительный уровень безопасности, включив SELinux на узле Linux, если применимо. После включения соответствующего подключаемого модуля обязательного контроля доступа для дистрибутива запустите управляемую программу Docker как docker run --interactive --tty --security-opt="apparmor:PROFILENAME" centos /bin/bash для AppArmor или docker run --interactive --tty --security-opt label=level:TopSecret centos /bin/bash для SELinux.
Убедитесь, что возможности ядра Linux ограничены в контейнерах
(5.03)		 Описание. Docker поддерживает добавление и удаление возможностей, позволяя использовать профиль, отличный от используемого по умолчанию. Это может повысить безопасность Docker путем удаления возможностей или понизить безопасность Docker путем добавления возможностей. Поэтому рекомендуется удалить все возможности, кроме тех, которые явно необходимы для процесса контейнера. Например, для процесса контейнера обычно не требуются такие возможности, как показано ниже: NET_ADMIN SYS_ADMIN SYS_MODULE Выполните приведенную ниже команду, чтобы добавить необходимые возможности: $> docker run --cap-add={"Capability 1","Capability 2"} Например,docker run --interactive --tty --cap-add={"NET_ADMIN","SYS_ADMIN"} centos:latest /bin/bash выполните приведенную ниже команду, чтобы удалить ненужные возможности: $> docker run --cap-drop={"Capability 1","Capability 2"} Например,docker run --interactive --tty --cap-drop={"SETUID","SETGID"} centos:latest /bin/bash можно удалить все возможности и добавить только необходимые: $> docker run --cap-drop=all --cap-add={"Возможность 1","Возможность 2"} Например, docker run --interactive --tty --cap-drop=all --cap-add={"NET_ADMIN","SYS_ADMIN"} centos:latest /bin/bash
Убедитесь, что привилегированные контейнеры не используются
(5.04)		 Описание: Флаг --privileged предоставляет все возможности контейнеру, а также отменяет все ограничения, применяемые контроллером cgroup устройства. Другими словами, контейнер может сделать почти все, что может сделать узел. Этот флаг существует для разрешения особых вариантов использования, таких как запуск Docker в Docker. Не запускайте контейнер с флагом --privileged. Например, не запускайте контейнер, как показано ниже: docker run --interactive --tty --privileged centos /bin/bash
Убедитесь, что конфиденциальные каталоги системы узлов не подключены к контейнерам
(5.05)		 Описание. Если конфиденциальные каталоги подключены в режиме чтения и записи, можно было бы внести изменения в файлы в этих конфиденциальных каталогах. Изменения могут привести к нарушению безопасности или неоправданным изменениям, которые могут скомпрометировать состояние узла Docker. Не подключайте конфиденциальные каталоги узлов к контейнерам, особенно в режиме чтения и записи.
Убедитесь, что сетевое пространство имен узла не используется совместно
(5.09)		 Описание: Это потенциально опасно. Это позволяет процессу контейнера открывать порты с малыми номерами, как и любой другой процесс root. Это также позволяет контейнеру осуществлять доступ к сетевым службам, таким как D-bus на узле Docker. Таким образом, процесс контейнера может выполнять непредвиденные действия, такие как завершение работы узла Docker. Не следует использовать этот параметр. Не передавайте параметр --net=host при запуске контейнера.
Убедитесь, что использование памяти для контейнера ограничено
(5.10)		 Описание. По умолчанию контейнер может использовать всю память на узле. Вы можете использовать механизм ограничения памяти для предотвращения отказа в обслуживании, вызванного тем, что один контейнер потребляет все ресурсы узла так, что другие контейнеры на этом же узле не могут выполнять свои предполагаемые функции. Отсутствие ограничений на память может привести к проблемам, когда один контейнер может легко сделать всю систему нестабильной и в результате непригодной для использования. Запускайте контейнер с минимально необходимым объемом памяти. Всегда запускайте контейнер, используя аргумент --memory. Например, можно запустить контейнер, как показано ниже: docker run --interactive --tty --memory 256m centos /bin/bash В приведенном выше примере контейнер запускается с ограничением памяти в 256 МБ. Примечание. Обратите внимание, что выходные данные приведенной ниже команды возвращают значения в экспоненциальном представлении, если существуют ограничения памяти. docker inspect --format='{{.Config.Memory}}' 7c5a2d4c7fe0 Например, если для указанного выше экземпляра контейнера задано ограничение памяти 256 MB, выходные данные приведенной выше команды будут иметь значение 2.68435456e+08, а НЕ 256m. Это значение следует преобразовать с помощью научного калькулятора или программных методов.
Убедитесь, что корневая файловая система контейнера подключена только для чтения.
(5.12)		 Описание. Включение этого параметра заставляет контейнеры во время выполнения явно определить стратегию записи данных для сохранения или не сохранения данных. Это также сокращает векторы атак на систему безопасности, так как изменить файловую систему или выполнить в нее запись возможно только при наличии явных разрешений на чтение и запись в папке и каталогах файловой системы. Добавьте флаг --read-only в среду выполнения контейнера, чтобы обеспечить принудительное подключение корневой файловой системы контейнера только для чтения.docker run --read-only Включение параметра --read-only в среде выполнения контейнера должно использоваться администраторами, чтобы принудительно обеспечить только запись данных контейнера в явные расположения хранилища исполняемыми процессами контейнера во время выполнения контейнера. Примеры явных расположений хранилища во время выполнения контейнера включают в себя, но не ограничиваются следующим: 1. Используйте параметр --tmpfs для подключения временной файловой системы для записи несохраняемых данных. docker run --interactive --tty --read-only --tmpfs "/run" --tmpfs "/tmp" centos /bin/bash 2. Включение подключения Docker rw в среде выполнения контейнера для сохранения данных контейнера непосредственно в файловой системе узла Docker. docker run --interactive --tty --read-only -v /opt/app/data:/run/app/data:rw centos /bin/bash 3. Использование подключаемых модулей тома общего хранилища Docker для тома данных Docker для сохранения данных контейнера. docker volume create -d convoy --opt o=size=20GB my-named-volume``````docker run --interactive --tty --read-only -v my-named-volume:/run/app/data centos /bin/bash 4. Передача данных контейнера за пределы Docker во время выполнения контейнера для сохранения данных контейнера. К примерам относятся размещенные базы данных, сетевые файловые ресурсы и API.
Убедитесь, что входящий трафик контейнера привязан к определенному интерфейсу узла
(5.13)		 Описание. Если на основном компьютере имеется несколько сетевых интерфейсов, контейнер может принимать подключения к предоставленным портам в любом сетевом интерфейсе. Это может быть нежелательным и небезопасным поведением. Во многих случаях определенный интерфейс предоставляется извне, а такие службы, как обнаружение и предотвращение вторжений, брандмауэр, балансировка нагрузки и т. д. выполняются в этих интерфейсах для проверки входящего общедоступного трафика. Следовательно, вы не должны принимать входящие подключения в любом интерфейсе. Следует разрешать только входящие подключения из определенного внешнего интерфейса. Привяжите порт контейнера к определенному интерфейсу узла на нужном порту узла. Например, docker run --detach --publish 10.2.3.4:49153:80 nginx. В приведенном выше примере порт контейнера 80 привязан к порту узла 49153 и будет принимать входящие подключения только из внешнего интерфейса 10.2.3.4.
Убедитесь, что для политики перезапуска контейнера "при сбое" задано значение "5" или ниже
(5.14)		 Описание. Если вы постоянно пытаетесь запустить контейнер, это может привести к отказу в обслуживании на узле. Это может стать простым способом атаки DDoS, особенно если у вас много контейнеров в одном узле. Кроме того, игнорирование состояния выхода контейнера и попытка always перезапустить контейнер препятствует анализу первопричины завершения работы контейнеров.ершением работы контейнеров. Если работа контейнера завершается, нужно разобраться в причинах, вместо того чтобы просто бесконечно перезапускать его. Поэтому рекомендуется использовать политику перезапуска on-failure и ограничить ее максимальным числом попыток перезапуска 5. Если необходимо перезапустить контейнер самостоятельно, например, можно запустить контейнер, как показано ниже: docker run --detach --restart=on-failure:5 nginx
Убедитесь, что пространство имен процесса узла не используется совместно
(5.15)		 Описание. Пространство имен PID обеспечивает разделение процессов. Пространство имен PID удаляет представление системных процессов и позволяет повторно использовать идентификаторы процесса, включая PID 1. Если пространство имен PID узла используется совместно с контейнером, по сути, процессы в контейнере смогут видеть все процессы в размещающей системе. Это лишает вас преимущества изоляции на уровне процессов между узлом и контейнерами. Кто-то, кто имеет доступ к контейнеру, может в конечном итоге изучить все процессы, выполняемые в размещающей системе, и даже завершать происходящие в размещающей системе процессы из контейнера. Последствия этого могут быть катастрофическими. Поэтому не следует использовать пространство имен процесса узла совместно с контейнерами. Не запускайте контейнер с аргументом --pid=host. Например, не запускайте контейнер, как показано ниже: docker run --interactive --tty --pid=host centos /bin/bash
Убедитесь, что пространство имен IPC узла не используется совместно
(5.16)		 Описание. Пространство имен IPC обеспечивает разделение IPC между узлом и контейнерами. Если пространство имен IPC узла используется совместно с контейнером, по сути, процессы в контейнере смогут видеть все IPC в размещающей системе. Это лишает вас преимущества изоляции на уровне IPC между узлом и контейнерами. Кто-то, кто имеет доступ к контейнеру, может в конечном итоге получить возможность управления IPC узла. Последствия этого могут быть катастрофическими. Поэтому не следует использовать пространство имен IPC узла совместно с контейнерами. Не запускайте контейнер с аргументом --ipc=host. Например, не запускайте контейнер, как показано ниже: docker run --interactive --tty --ipc=host centos /bin/bas
Убедитесь, что устройства узла не предоставляются непосредственно контейнерам
(5.17)		 Описание. Параметр --device предоставляет устройства узла контейнерам и, следовательно, контейнеры могут напрямую обращаться к таким устройствам узла. Для доступа к устройствам узла и выполнения операций с ними вам не потребуется запускать контейнер в режиме privileged. По умолчанию контейнер сможет читать, записывать эти устройства и выполнять с ними команды mknod. Кроме того, контейнеры могут удалять устройства блока с узла. Поэтому не предоставляйте устройства узла контейнерам напрямую. В крайнем случае, если требуется предоставить устройство узла контейнеру, используйте разрешения общего доступа правильно: - r — только чтение; w — возможность записи; - m — возможность выполнения команды mknod Не предоставляйте устройства узла контейнерам напрямую. В крайнем случае, если требуется предоставить устройства узла контейнерам, используйте подходящий набор разрешений. Например, не запускайте контейнер, как показано ниже: docker run --interactive --tty --device=/dev/tty0:/dev/tty0:rwm --device=/dev/temp_sda:/dev/temp_sda:rwm centos bash Например, при совместном использовании устройства узла назначайте правильные разрешения: docker run --interactive --tty --device=/dev/tty0:/dev/tty0:rw --device=/dev/temp_sda:/dev/temp_sda:r centos bash
Убедитесь, что для режима распространения подключения не задано совместное использование
(5.19)		 Описание. Общее подключение реплицируется на всех подключениях, и изменения, внесенные в любой точке подключения, распространяются на все подключения. Подключение тома в режиме общего доступа не ограничивает подключение и внесение изменений в этот том другим контейнером. Это может иметь катастрофические последствия, если подключенный том чувствителен к изменениям. Настраивайте совместное использование для режима распространения подключения только в случае необходимости. Не подключайте тома в при распространении режима совместного использования. Например, не запускайте контейнер, как показано ниже: docker run --volume=/hostPath:/containerPath:shared
Убедитесь, что пространство имен UTS узла не является общим
(5.20)		 Описание. При совместном использовании пространства имен UTS с узлом контейнеру предоставляется полное разрешение на изменение имени узла. Это небезопасно, разрешать такое поведение не следует. Не запускайте контейнер с аргументом --uts=host. Например, не запускайте контейнер, как показано ниже: docker run --rm --interactive --tty --uts=host rhel7.2
Убедитесь, что использование cgroup подтверждено
(5.24)		 Описание. Системные администраторы обычно определяют группы cgroup, в которых должны выполняться контейнеры. Даже если группы cgroup не определены системными администраторами явным образом, контейнеры выполняются в группе cgroup docker по умолчанию. Во время выполнения можно подключиться к группе cgroup, отличной от той, которую предполагалось использовать. Такое использование необходимо отслеживать и подтверждать. При подключении к группе cgroup, отличной от той, которую предполагалось использовать, контейнеру могут быть предоставлены избыточные разрешения и ресурсы, что может оказаться небезопасным. Используйте параметр --cgroup-parent в команде docker run только в случае крайней необходимости.
Убедитесь, что получение дополнительных прав контейнером ограничено
(5.25)		 Описание. Процесс может задать бит no_new_priv в ядре. Он сохраняется в вилке, клонировании и файле execve. Бит no_new_priv гарантирует, что процесс или его дочерние процессы не получают дополнительных привилегий с помощью битов suid или sgid. Следовательно, многочисленные опасные операции становятся гораздо менее опасными, потому что нет возможности испортить привилегированные двоичные файлы. Например, необходимо запустить контейнер, как показано ниже. docker run --rm -it --security-opt=no-new-privileges ubuntu bash
Убедитесь, что работоспособность контейнера проверяется во время выполнения.
(5.26)		 Описание. Одним из важных аспектов безопасности является доступность. Если в используемом образе контейнера отсутствует предварительно определенная инструкция HEALTHCHECK, для проверки работоспособности контейнера во время выполнения используйте параметр --health-cmd. В зависимости от сообщаемого состояния работоспособности можно предпринять необходимые действия. Запустите контейнер с помощью --health-cmd и других параметров. Например: docker run -d --health-cmd='stat /etc/passwd || exit 1' nginx
Убедитесь, что используется лимит группы cgroup PID
(5.28)		 Описание. Злоумышленники могут запустить "ветвящуюся" бомбу с помощью одной команды в контейнере. Эта "ветвящаяся" бомба может привести к аварийному завершению работы всей системы и потребует перезапуска узла, чтобы система снова заработала. Группа cgroup PID --pids-limit предотвратит такие атаки, ограничивая количество возможных вилок внутри контейнера в определенный момент. Используйте флаг --pids-limit при запуске контейнера с соответствующим значением. Например, docker run -it --pids-limit 100 в приведенном выше примере. Число процессов, разрешенных для выполнения в любое время, равно 100. По достижении лимита в 100 одновременно выполняемых процессов Docker ограничит создание новых процессов.
Убедитесь, что мост Docker по умолчанию docker0 не используется
(5.29)		 Описание: Docker подключает виртуальные интерфейсы, созданные в режиме моста, к общему мосту с именем docker0. Эта сетевая модель по умолчанию уязвима для спуфинга ARP и flood-атак MAC, так как фильтрация не применяется. Настройте пользовательскую сеть, следуя инструкциям в документации Docker. Запустите все контейнеры в определенной сети.
Убедитесь, что пользовательское пространство имен узла не является общим
(5.30)		 Описание. Пользовательские пространства имен гарантируют, что корневой процесс внутри контейнера будет сопоставлен некорневому процессу за пределами контейнера. Таким образом, совместное использование пользовательских пространств имен узла с контейнером не изолирует пользователей узла от пользователей контейнеров. Совместное использование пользовательских пространств имен узлом и контейнерами не рекомендовано. Например, не запускайте контейнер, как показано ниже: docker run --rm -it --userns=host ubuntu bash
Убедитесь, что сокет Docker не подключен внутри каких-либо контейнеров
(5.31)		 Описание. Если сокет Docker подключен внутри контейнера, это позволит процессам, выполняемым в контейнере, выполнять команды Docker, которые обеспечивают полный контроль над узлом. Убедитесь, что ни один контейнер не подключил docker.sock в качестве тома.
Убедитесь, что службы группы мелких объектов привязаны к определенному интерфейсу узла
(7.03)		 Описание. При инициализации группы мелких объектов значение по умолчанию для флага --listen-addr — 0.0.0.0:2377, что значит, что службы групп мелких объектов будут слушать все интерфейсы на узле. Если на узле несколько сетевых интерфейсов, это может предоставлять службы групп мелких объектов Docker сетям, которые не участвуют в работе группы мелких объектов, что может быть нежелательным. Передавая определенный IP-адрес --listen-addr, это предоставление можно ограничить, задав определенный сетевой интерфейс. Исправление этого требует повторной инициализации группы мелких объектов путем задания определенного интерфейса для параметра --listen-addr.
Убедитесь, что данные, которыми обмениваются контейнеры, шифруются на разных узлах в сети наложения
(7.04)		 Описание. По умолчанию обмен данными между контейнерами на разных узлах в сети наложения не шифруется. Это может привести к раскрытию трафика между узлами контейнера. Создайте сеть наложения с флагом --opt encrypted.
Убедитесь, что диспетчер групп мелких объектов запущен в режиме автоматической блокировки
(7.06)		 Описание. При перезапуске Docker ключ TLS, используемый для шифрования связи между узлами группы мелких объектов, и ключ, используемый для шифрования и расшифровки журналов Raft на диске, загружается в память каждого узла диспетчера. Необходимо защитить ключ взаимного шифрования TLS и ключ, используемый для шифрования и расшифровки неактивных журналов Raft. Эту защиту можно включить путем инициализации группы мелких объектов с флагом --autolock. Если параметр --autolock включен, при перезапуске Docker сначала необходимо разблокировать группу мелких объектов, используя ключ шифрования ключей, созданный Docker при инициализации группы мелких объектов. Если вы инициализируете группу мелких объектов, используйте приведенную ниже команду. docker swarm init --autolock Если требуется задать --autolock в существующем узле диспетчера группы мелких объектов, используйте команду ниже.docker swarm update --autolock

Примечание.

Возможность использования отдельных определений Политики Azure может отличаться в Azure для государственных организаций и в других национальных облаках.

Следующие шаги

Дополнительные статьи о политике Azure и гостевой конфигурации: