Сигурност за Docker контейнерите

Прим. прев.: Темата за сигурността на Docker е една от вечните в съвременния IT свят. Затова, без излишни обяснения, ви представяме превод на поредната подбрана колекция от съответни препоръки. Ако вече сте се интересували от този въпрос, много от тях ще ви бъдат познати. А самата подборка допълнихме със списък от полезни утилити и няколко ресурса за по-нататъшно изучаване на темата.

Предлагам вниманието ви ръководство за осигуряване на сигурността на Docker. Обратната връзка е добре дошла, тъй като това е по-скоро сборник от различни ресурси и не всички от тях са били подложени на дълбочинна проверка. Препоръките са разделени на три категории:

1. Необходими мерки вътре в операционната система на хоста при работа с Docker;
2. Инструкции, отнасящи се до файла за конфигурация на сборката и създаването на контейнери;
3. Инструменти за сигурност, които могат да се интегрират със специфични функции на Docker Enterprise.

Основата на ръководството са различни ресурси, много от които са изброени по-долу. То не може да се нарече изчерпателно, но обхваща всички основи. Допълнителна информация може да бъде намерена в описанието на тестовете CIS (връзката е предоставена в края на това ръководство), както и в документацията на Docker.

Docker Security Benchmark

Docker Bench for Security автоматично проверява вашия Docker за съответствие на най-разпространените добри практики. Скриптът представлява неплох тест за хрумвания по сигурността, но не трябва да се разглежда като инструмент за комплексен анализ.

ОС на хоста

Очевидно е, че Docker-контейнерът не може да бъде защитен, ако самата хост-система не е защитена. Затова е необходимо да се следват добрите практики в областта на сигурността на операционните системи. Освен това, би било разумно да се проведе анализ на уязвимостите в допълнение към следващите препоръки.

Правила за одит

Създавайте и използвайте правила за одит за файлове, свързани с Docker, с помощта на auditctl. Например, можете да добавите -w /usr/bin/dockerd -k docker к /etc/audit.rules и да рестартирате услугата за одит.

Режим FIPS

Включването на режима FIPS налага криптографските инструменти да превключат към алгоритми, включени в FIPS (американски Federal Information Processing Standards — забележка на преводача), съответствайки на федералните и секторните норми и изисквания. Ако хостната ОС поддържа FIPS режим, можете да го активирате, като изпълните следните команди:

sed -i 's/GRUB_CMDLINE_LINUX="/GRUB_CMDLINE_LINUX="fips=1 /g' /etc/default/grub
grub2-mkconfig -o /boot/grub2/grub.cfg && reboot

Необходимо е също да активирате FIPS в Docker Engine:

mkdir -p /etc/systemd/system/docker.service.d 2>&1; echo -e "[Service]\n Environment=\"DOCKER_FIPS=1\"" > /etc/systemd/system/docker.service.d/fips-module.conf; systemctl daemon-reload; systemctl restart docker

За допълнителна информация вижте документацията Docker и Red Hat.

Docker Secrets

Конфиденциални данни трябва да се съхраняват като секрети. Можете да стартирате съответния сервис с командата docker service create:

docker service create --label com.docker.ucp.access.label=/prod --name nginx --publish 443 --secret source=orcabank_prod_mobile.ca.pem.v1,target=ca.pem nginx

Повече подробности вижте в документацията.

Конфигурационен файл на Docker

Следните настройки могат да бъдат добавени в конфигурационния файл /etc/docker/daemon.json:

• "icc":false — деактивира обмена на данни между контейнерите, за да се избегне ненужно изтичане на информация.
• log-level: "info" — улавя всички логове, освен отладъчните.

• {
    "log-driver": "syslog",
    "log-opts": {
      "syslog-address": "udp://1.2.3.4:1111"
    }
  }

  — свързва дистанционно водене на логовете, изпраща ги на указан адрес. Работи само ако демона syslog е пуснат. Приемат се TCP и UDP опции. Също така е възможно свързване за всеки конкретен контейнер. За целта се задава специален флаг при стартиране на Docker (--log-opt syslog-address=ADDRESS).

• "userns-remap": "Your_User" — предотвратява повишаване на привилегиите (privilege escalation), изолирайки пространството на имената под конкретен потребител.

Сигурност на транспортния слой

Достъпът до демона на Docker (ако е необходим дистанционен достъп) трябва да бъде само за потребители с достъп до TLS клиента.

Плагини за авторизация

Определете на кои потребители какви команди им е разрешено да изпълняват и създайте съответния плагин за авторизация за Docker. След това стартирайте демона на Docker и добавете плагина:

dockerd --authorization-plugin=PLUGIN_ID

За да научите повече за създаването на авторизационни плъгини, вижте в документацията.

Параметри на демона

Демонът на Docker работи с набор от параметри по подразбиране.

• --live-restore — този параметър помага да се намали времето на престой на контейнерите при изключване или рестартиране на системата. Става по-лесно да ги пачнете или актуализирате с минимален престой;
• --userland-proxy=false — когато се използват или активират hairpin NAT, прокси в потребителското пространство става излишна услуга, която само увеличава броя на възможните вектори на атака;
• --no-new-privileges — предотвратява получаването на допълнителни привилегии от контейнерите чрез suid или sguid;
• --seccomp-profile /path/to/profile — ако имате собствен seccomp профил, можете да го приложите с този флаг. Научете повече за Seccomp и Docker можете тук..

Конфигурация на контейнерите и файловете за изграждане

Създаване на потребител

Уверете се, че за контейнера е създаден потребител и го стартирайте под този потребител (НЕ стартирайте контейнера като root).

Отдалечен достъп

Забранете удалечения достъп до демона. Ако все пак е необходим, защитете го с сертификати.

Изолирайте пространството на имената на потребителите

Особено важно е да се уверите, че пространството на имената на потребителите в Docker е изолирано, тъй като по подразбиране то се използва заедно с пространството на имената на хоста. В някои случаи това може да бъде използвано за повишаване на привилегиите или дори за напускане на контейнера. Изолирането на потребителското пространство на имената може да се направи чрез редактиране на конфигурационния файл (както е описано по-горе в раздела „Конфигурационен файл на Docker“). Допълнителното споменаване на този проблем тук е повикано от неговата важност.

Healthcheck-и

Healthcheck (проверка на работоспособността) — мощен инструмент, позволяващ проверка на целостта на контейнера. Настройва се в Dockerfile с помощта на инструкция HEALTHCHECK. Healthcheck-ите позволяват да се уверите, че контейнерът работи правилно. В следващия пример проверката за работоспособност завършва с 0, ако сървърът работи, и 1, ако е "паднал":

HEALTHCHECK CMD curl --fail http://localhost || exit 1

SELinux

Ако SELinux се поддържа от операционната система на хоста, създайте или импортирайте политика SELinux и стартирайте Docker в режим демона с включен SELinux:

docker daemon --selinux-enable

В този случай Docker-контейнерите могат да се стартират с параметри за сигурност, например:

docker run --interactive --tty --security-opt label=level:TopSecret centos /bin/bash

Мрежови интерфейси

По подразбиране Docker слуша всички мрежови интерфейси. Тъй като в повечето случаи трафикът се очаква само на един от тях, такъв подход неоправдано увеличава риска от атака. Затова при стартиране на контейнера можете да свържете неговите портове към конкретни интерфейси на хоста:

docker run --detach --publish 10.2.3.4:49153:80 nginx

Кеширани версии на образите

При свалянето на образи, уверете се, че локалният кеш съответства на съдържанието на репозитория. В противен случай, може да получите остаряла версия на образа или образ, съдържащ уязвимости.

Мрежов мост

По подразбиране мрежовата модел docker0, е уязвим на атаки от типа ARP-spoofing и MAC-flooding. За да решите този проблем, създайте мрежов мост в съответствие със своите спецификации, както е описано тук..

Предупреждение за Docker сокета

Никога не пробуждайте Docker сокета в контейнера. В противен случай, контейнерът ще има възможността да изпълнява Docker команди и, следователно, да свързва с хост операционната система и да я контролира. Не правете това.

Конфигуриране на Docker Enterprise

Docker Trust

Docker Trust позволява генерирането на ключове, с помощта на които може да се проверява криптографската цялост на образите. Ключовете на Docker Trust могат да се използват за подписване на Docker образи с частни ключове, които се проверяват с публични ключове на Notary Server. Допълнителна информация — тук.. Включването на Docker Trust в Enterprise Engine е подробно описано в този раздел на документацията.

Сканиране на уязвимости

В Docker Enterprise има вграден скенер за уязвимости, който позволява да се изтегли база с CVE за offline сканиране на уязвимости в образите. Редовното сканиране на образите помага да ги направи по-сигурни: потребителят веднага получава предупреждения за откритите уязвимости. Повече информация относно това как може да се направи, вижте тук..

Прим. прев.: Съществуват и Open Source скенери за уязвимости в Docker образи, примери за които можете да видите в края на материала.

Интеграция с LDAP и UCP

Universal Control Plane може да бъде интегриран с LDAP. Резултатът ще бъде опростена система за удостоверяване, която позволява избягване на ненужно дублиране. Повече информация за това може да бъде прочетена в статията Integrate with an LDAP directory.

Други материали

Допълнителна информация за най-добрите практики в областта на сигурността на Docker може да бъде намерена на docs.docker.com. Също така препоръчваме да изтеглите тестовете на Center for Internet Security за Docker.

Бонус от преводача

Като логично допълнение към тази статия публикуваме списък от 10 популярни Open Source инструменти за осигуряване на безопасността в Docker. Той е заимстван от друга статия (от Bill Doerrfeld от Doerrfeld.io).

NB: Научете повече за много от споменатите тук проекти в статията „33+ инструмента за безопасност на Kubernetes».

1. Docker Bench for Security — вече споменатият в самото начало на статията скрипт, който проверява Docker контейнери за съответствие с разпространените практики за сигурност.

   

2. Clair — вероятно най-популярният инструмент за статичен анализ на уязвимости в контейнерите. Използва многобройни бази данни с уязвимости CVE (включително трекери на водещи Linux дистрибуции като Red Hat, Debian, Ubuntu). Предлага API за разработчици и лесна възможност за разширяване на функциите (чрез добавяне на „драйвери“). Използва се в популярния публичен регистър на образи от контейнери (аналог на Docker Hub) — Quay.io.
3. Cilium — решение за осигуряване на мрежова безопасност на ниво ядро, основано на технологията за филтриране на мрежови пакети BPF.
4. Anchore — инструмент за анализ на съдържанието на образи за наличие на уязвимости по базата CVE. Освен това позволява прилагане на потребителски политики (на базата на различни данни, включително бели/черни списъци, съдържание на файлове и др.) за оценка на сигурността на контейнерите.
5. OpenSCAP Workbench — цяла екосистема за създаване и поддържане на политики за сигурност на различни платформи. За проверка на контейнери предлага инструмент oscap-docker.
6. Dagda — инструмент за сканиране на Docker контейнери за наличие на уязвимости, троянски коне, вируси и злонамерен софтуер. Базите CVE включват проверки за зависимости от OWASP, базата Red Hat Oval, репозитория на експлоити Exploit Database.
7. Notary — фреймворк за подписване на Docker образи, първоначално създаден в Docker Inc (а след това предаден на развитие в CNCF). Неговото използване позволява делегиране на роли и разпределение на отговорности за контейнерите, както и верифициране на криптографската цялост на образите.
8. Grafaes — API за метаданни, предназначен за управление на вътрешните политики за сигурност. Например, позволява подобрение на работата на скенерите за сигурност на контейнерите. Shopify използва този API за управление на метаданните на своите 500 хиляди образи.
9. Sysdig Falco — инструмент за Kubernetes, който следи поведението на системата: активността в контейнерите, на хостовете, в мрежата. Позволява настройване на непрекъснати проверки в инфраструктурата, откриване на аномалии и изпращане на аларми по каквито и да е системни повиквания на Linux.
10. Banyanops Collector — още един инструмент за статичен анализ на образи на Docker контейнери. Позволява „да надникнете“ в файловете на образа, събирайки необходимите данни, прилагайки нужните политики и т.н.

Още една добра селекция от практически насоки как да направите Docker по-безопасен, можете да намерите в тази статия компанията Aqua Security. Много от техните съвети се припокриват с вече споменатите по-горе, но има и други. Например, авторите предлагат организиране на мониторинг на активността в контейнерите и посочват какво да се има предвид при използване на Docker Swarm.

За тези, които искат да се запознаят по-подробно с темата, миналата година излезе книгата „Docker Security: Quick Reference», части от която са свободно достъпни тук..

Накрая, за практически запознанства с някои аспекти на сигурността на Docker: профили Seccomp и използването на capabilities на ядрото на Linux в контейнерите — можете да преминете през съответните лабораторни работи на ресурса Play with Docker* — вижте секцията „Security“.

* За самия този ресурс ние разказваха пишем преди две години, а през ноември 2018 г. се случи доста интересна (от гледна точка на сигурността) история с него. В кратце, специалисти от CyberArk Software Ltd. успяха да го хакнат: да получат възможност за изпълнение на команди извън контейнери, т.е. на хост системата. Отлична илюстрация на проблемите със сигурността в Docker, нали? За всички подробности относно случилото се четете тук..

P.S. от преводача

Прочетете също в нашия блог:

• «Уязвима Docker VM — виртуална машина-пъзел по Docker и пен тестинг»;
• «В 19% от най-популярните Docker образи няма парола за root»;
• «33+ инструмента за безопасност на Kubernetes»;
• «Docker и Kubernetes в среди, изискващи сигурност»;
• «9 най-добри практики за осигуряване на безопасността в Kubernetes»;
• «OPA и SPIFFE — два нови проекта в CNCF за сигурност на облачни приложения».

Източник: habr.com