10 практических рекомендаций по безопасности образов Docker. Часть 1

Перевод статьи подготовлен специально для студентов курса «Безопасность Linux».

---

В этой статье мы хотели бы сосредоточиться на Docker и обсудить советы и рекомендации, которые обеспечивают более безопасный и качественный процесс обработки образов Docker.

Итак, начнем с нашего списка из 10 практических рекомендаций по безопасности образов Docker.

1. Предпочитайте минимальные базовые образы

Зачастую вы можете начинать проекты с базового образа контейнера Docker, например, с написания Dockerfile с FROM node «по умолчанию». Однако при указании образа node следует учитывать, что полностью установленный дистрибутив Debian Stretch является базовым образом, который используется для его сборки. Если ваш проект не требует каких-либо общих системных библиотек или утилит, то лучше избегать использования полнофункциональной операционной системы (ОС) в качестве базового образа.

В отчете Snyk о состоянии безопасности открытого исходного кода — 2019 мы обнаружили, что многие популярные контейнеры Docker, представленные на веб-сайте Docker Hub, содержат в себе образы, содержащие много известных уязвимостей. Например, когда вы используете популярный универсальный образ docker pull node вы фактически вводите в свое приложение ОС, которая, как известно, имеет 580 уязвимостей в своих системных библиотеках.



Как видно из отчета по безопасности, каждый из десяти популярнейших образов Docker, которые мы проверяли в Docker Hub, содержал известные уязвимости. Предпочитая минимальные образы, которые объединяют только необходимые системные инструменты и библиотеки, необходимые для запуска вашего проекта, вы также сводите к минимуму пространство для атаки злоумышленников и гарантируете, что поставляете защищенную ОС.

УЗНАЙТЕ БОЛЬШЕ О БЕЗОПАСНОСТИ ВАШИХ ОБРАЗОВ

2. Наименее привилегированный пользователь

Когда Dockerfile не указывает USER, по умолчанию контейнер выполняется с использованием root-пользователя. На практике существует очень мало причин, по которым контейнер должен иметь root-привилегии. Docker по умолчанию запускает контейнеры, используя root-пользователя. Затем когда это пространство имен сопоставляется с root-пользователем в работающем контейнере, из этого следует, что контейнер потенциально имеет root-доступ на хосте Docker. Запуск приложения в контейнере с root-пользователем еще больше расширяет пространство для атаки и обеспечивает легкий путь к повышению привилегий, если само приложение уязвимо для эксплойтов.

Чтобы минимизировать незащищенность, включите создание специально выделенного пользователя и группу в образе Docker для приложения; используйте директиву USER в Dockerfile, чтобы убедиться, что контейнер запускает приложение с наименее привилегированным доступом.

Выделенный пользователь может не существовать в образе; создайте этого пользователя, используя инструкции в Dockerfile.

Ниже приведен полный пример того, как это сделать для универсального образа Ubuntu:

FROM ubuntu
RUN mkdir /app
RUN groupadd -r lirantal && useradd -r -s /bin/false -g lirantal lirantal
WORKDIR /app
COPY . /app
RUN chown -R lirantal:lirantal /app
USER lirantal
CMD node index.js

Пример выше:

• создает системного пользователя (-r) без пароля, без установки домашнего каталога и без оболочки
• добавляет пользователя, которого мы создали, к существующей группе, которую мы создали заранее (используя groupadd)
• добавляет последний аргумент к имени пользователя, которого мы хотим создать, в сочетании с группой, которую мы создали

Node.js и образов alpine, они уже включают в себя универсального пользователя, называемого node. Вот пример Node.js, использующий универсального пользователя node:

FROM node:10-alpine 
RUN mkdir /app
COPY . /app
RUN chown -R node:node /app
USER node
CMD [“node”, “index.js”]

Если вы разрабатываете Node.js приложения, вы можете обратиться к официальным практическим рекомендациям Docker и Node.js.

3. Подписывайте и проверяйте образы, чтобы избегать MITM атаки

Аутентичность образов Docker является проблемой. Мы полагаемся на эти образы, поскольку буквально используем их в качестве контейнера, который запускает наш код в продакшене. Поэтому важно убедиться, что образ, который мы используем, является именно тем, который поставляет издатель, и что ни одна из сторон не изменила его. Подделка может происходить по проводной связи, между клиентом Docker и реестром, или путем взлома реестра учетной записи владельца, чтобы подменить образ.

Проверка образа Docker

Настройки Docker по умолчанию позволяют извлекать образы Docker без проверки их подлинности, что потенциально может привести к использованию образов Docker, происхождение и автор которых не проверены.

Рекомендуется всегда проверять образы перед их использованием, независимо от политики. Чтобы поэкспериментировать с проверкой, временно включите Docker Content Trust с помощью следующей команды:

export DOCKER_CONTENT_TRUST=1

Теперь попытайтесь подтянуть образ, про который вы знаете, что он не подписан — запрос будет отклонен, а образ не получен.

Подпись образов Docker

Предпочитайте сертифицированные Docker образы, полученные от проверенных партнеров, которые были проверены и курированы Docker Hub, вместо образов, происхождение и подлинность которых вы не можете проверить.

Docker позволяет подписывать образы и тем самым обеспечивает еще один уровень защиты. Для подписи образов используйте Docker Notary. Notary проверяет подпись образа для вас и блокирует запуск образа, если подпись образа недействительна.

Когда Docker Content Trust включено, как мы показали выше, сборка образа Docker подписывает образ. Когда образ подписывается впервые, Docker создает и сохраняет приватный ключ в ~/docker/trust для вашего пользователя. Затем этот приватный ключ используется для подписи любых дополнительных образов по мере их создания.

Подробные инструкции по настройке подписанных изображений смотрите в официальной документации Docker.

4. Находите, исправляйте и отслеживайте уязвимости в компонентах с открытым исходным кодом

Когда мы выбираем базовый образ для нашего Docker контейнера, мы косвенно берем на себя риск всех проблем безопасности, с которыми связан базовый образ. Это могут быть плохо сконфигурированные настройки по умолчанию, которые не способствуют безопасности операционной системы, а также системные библиотеки, которые связаны с выбранным нами базовым образом.

Хорошим первым шагом является использование минимального базового образа, насколько это возможно для запуска приложения без проблем. Это помогает уменьшить пространство для атаки, ограничивая уязвимость; с другой стороны, он не проводит никаких собственных проверок и не защищает вас от будущих уязвимостей, которые могут быть выявлены для используемой версии базового образа.

Поэтому одним из способов защиты от уязвимостей в программном обеспечении с открытым исходным кодом является использование таких инструментов, как Snyk, для добавления непрерывного сканирования и отслеживания уязвимостей, которые могут существовать во всех используемых слоях образов Docker.



Сканирование образа Docker на наличие известных уязвимостей производится с помощью этих команд:

# fetch the image to be tested so it exists locally
$ docker pull node:10
# scan the image with snyk
$ snyk test --docker node:10 --file=path/to/Dockerfile

Мониторинг образа Docker на наличие известных уязвимостей, чтобы после обнаружения новых уязвимостей в образе Snyk мог уведомить и предоставить рекомендации по исправлению, производится следующим образом:

$ snyk monitor --docker node:10

На основе сканирования, выполненного пользователями Snyk, мы обнаружили, что 44% сканирований образов Docker выявили известные уязвимости и для которых были доступны более новые и более безопасные базовые образы. Эта консультация по исправлению, в соответствии с которой разработчики могут предпринимать соответствующие действия и обновлять свои образы Docker, уникальна для Snyk.

Snyk также обнаружил, что для 20% всех сканирований образов Docker достаточно только перестроить образ Docker, чтобы уменьшить количество уязвимостей. Узнайте больше о количестве открытых отчетов о безопасности 2019 года в блоге Snyk.

Конец первой части.

Продолжение во второй части, а сейчас приглашаем всех на бесплатный вебинар по теме: «Уязвимости Docker. Побег из контейнера в хост с эскалацией привилегий».