Сигурност за 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\ngrub2-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 за офлайн сканиране на уязвимости в образи. Редовното сканиране на образите помага да ги направите по-безопасни: потребителят получава предупреждения за откритите уязвимости. Повече информация за това как може да стане, вижте тук.

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

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

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

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

Допълнителна информация за най-добрите практики в областта на безопасността на Docker можете да намерите на docs.docker.com. Препоръчваме също да изтеглите тестовете на Центъра за киберсигурност за 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 контейнери за наличие на уязвимости, троянски коне, вируси и malware. В базите 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 и pentesting»;
• «В 19% от най-популярните Docker образи няма парола за root»;
• «33+ инструмента за сигурност на Kubernetes»;
• «Docker и Kubernetes в среди с високи изисквания за сигурност»;
• «9 най-добри практики за осигуряване на сигурност в Kubernetes»;
• «OPA и SPIFFE — два нови проекта в CNCF за сигурността на облачните приложения».

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