Безопасный Docker в продакшене

В новом переводе от команды Spring АйО вы узнаете, как минимизировать риски и обеспечить безопасность Docker-контейнеров с помощью CIS Benchmark рекомендаций и автоматизированных инструментов вроде Docker Bench for Security.

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

1. CIS Benchmark

Стандартная конфигурация Docker недостаточно защищена для продакшн-окружений. Это касается и большинства Dockerfile’ов, доступных в сети. Даже некоторые примеры из наших прошлых статей могут не соответствовать требованиям безопасности. Как же в таком случае узнать, как запустить безопасный Docker-контейнер? Чтобы понять, как защитить контейнеры, можно воспользоваться рекомендациями Центра интернет-безопасности (CIS). CIS предоставляет лучшие практики по тому, как можно обезопасить IT системы и данные от атак извне. Эти практики признаны и проверены сообществом опытных IT экспертов. Нам сегодня поможет страница CIS Benchmarks. Здесь мы найдем множество эталонных решений для операционных систем, устройств и программ. В этом списке мы также можем найти CIS Benchmark for Docker Community Edition 1.1.0 (эталонное решение для Docker Community Edition, версия 1.0.0). Оно доступно для бесплатного скачивания, но вам придется указать свои контакты, после чего ссылка для скачивания будет отправлена на ваш адрес электронной почты. Помимо этого вам также предоставят доступ к другим решениям от CIS.

CIS Benchmark предоставляет вам рекомендации, сгрупированные по:

Конфигурации хоста;
Конфигурации Docker daemon;
Файлам конфигурации Docker daemon;
Образам контейнера и файлу сборки;
Рантайму контейнера;
Операциям безопасности Docker;
Конфигурации Docker Swarm.

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

2. Docker Bench for Security

Проверка рекомендаций вручную может занять много времени, но есть инструмент, который поможет — Docker Bench for Security. Этот скрипт автоматически проверяет настройки Docker по рекомендациям CIS и генерирует отчёт о проблемах, требующих внимания.

3. На практике

Давайте посмотрим, как это работает. Мы будем использовать следующую конфигурацию:

Ubuntu 18.04
Чистая сборка Docker

Docker-образ, который мы будем использовать, взят из предыдущей статьи и доступен на Docker Hub. Этот образ основан на openjdk 10 и содержит простое Spring Boot Web MVC приложение с одним HTTP-эндпоинтом: http://ipaddress:8080/hello. Этот эндпоинт возвращает приветственное сообщение «Hello Kubernetes».

Dockerfile:

FROM openjdk:10-jdk  VOLUME /tmp  ARG JAR_FILE  ADD ${JAR_FILE} app.jar  ENTRYPOINT ["java","-Djava.security.egd=file:/dev/./urandom","-jar","/app.jar"]

Первым делом необходимо запустить контейнер:

$ docker run --name=mykubernetesplanet mydeveloperplanet/mykubernetesplanet:0.0.2-SNAPSHOT

После успешного запуска проверьте, можете ли вы получить доступ к указанному URL. IP-адрес вашего Docker-контейнера можно узнать с помощью команды:

$ docker inspect mykubernetesplanet

В разделе «Networks» можно найти IP-адрес Docker-контейнера.

3.1 Запуск Docker Bench for Security

Самый простой способ запустить Docker Bench for Security — это использовать готовый контейнер:

$ docker run -it --net host --pid host --userns host --cap-add audit_control \      -e DOCKER_CONTENT_TRUST=$DOCKER_CONTENT_TRUST \      -v /var/lib:/var/lib \      -v /var/run/docker.sock:/var/run/docker.sock \      -v /usr/lib/systemd:/usr/lib/systemd \      -v /etc:/etc --label docker_bench_security \      docker/docker-bench-security

Отчет, который будет сгенерирован:

# ------------------------------------------------------------------------------  # Docker Bench for Security v1.3.4  #  # Docker, Inc. (c) 2015-  #  # Checks for dozens of common best-practices around deploying Docker containers in production.  # Inspired by the CIS Docker Community Edition Benchmark v1.1.0.  # ------------------------------------------------------------------------------  Initializing Mon Dec 24 11:20:27 UTC 2018  ...  [INFO] 4 - Container Images and Build File  [WARN] 4.1  - Ensure a user for the container has been created  [WARN]      * Running as root: quizzical_noether  [WARN]      * Running as root: mykubernetesplanet  [NOTE] 4.2  - Ensure that containers use trusted base images  [NOTE] 4.3  - Ensure unnecessary packages are not installed in the container  [NOTE] 4.4  - Ensure images are scanned and rebuilt to include security patches  [WARN] 4.5  - Ensure Content trust for Docker is Enabled  [WARN] 4.6  - Ensure HEALTHCHECK instructions have been added to the container image  [WARN]      * No Healthcheck found: [mydeveloperplanet/mykubernetesplanet:0.0.2-SNAPSHOT]  [INFO] 4.7  - Ensure update instructions are not use alone in the Dockerfile  [INFO]      * Update instruction found: [mydeveloperplanet/mykubernetesplanet:0.0.2-SNAPSHOT]  [NOTE] 4.8  - Ensure setuid and setgid permissions are removed in the images  [INFO] 4.9  - Ensure COPY is used instead of ADD in Dockerfile  [INFO]      * ADD in image history: [docker/docker-bench-security:latest]  [INFO]      * ADD in image history: [mydeveloperplanet/mykubernetesplanet:0.0.2-SNAPSHOT]  [NOTE] 4.10  - Ensure secrets are not stored in Dockerfiles  [NOTE] 4.11  - Ensure verified packages are only Installed  ...  [INFO] Checks: 105  [INFO] Score: 5

Для краткости приведен только раздел, касающийся образов контейнеров и файла сборки, так как мы будем использовать его в следующих абзацах. Как видно, у нас есть несколько предупреждений и заметок. Предупреждения (warnings) — это рекомендации с оценочным статусом, а заметки (notes) — это рекомендации без оценочного статуса. В конце виден наш общий оценочный статус, который не очень высокий. Все запущенные контейнеры проанализированы, включая контейнер Docker Bench for Security.

3.2 Исправления по некоторым рекомендациям

На основе вывода мы можем легко исправить некоторые проблемы, которые есть в нашем Dockerfile. Как упоминалось ранее, рекомендации CIS Benchmark содержат способы исправления предупреждений, и мы используем их для решения проблем.

Мы увеличиваем версию в нашем файле pom и вносим изменения в ветке feature/dockerbenchsecurity. Источники можно найти на GitHub.

3.2.1 Убедитесь в том, что создали пользователя для контейнера

Поскольку мы не создали пользователя для нашего контейнера, наше приложение сейчас запускается от имени root. Мы не хотим этого, потому что у root много привилегий, а для нашего приложения это не требуется. Добавим пользователя appuser в наш Dockerfile, чтобы исправить это предупреждение:

RUN useradd -d /home/appuser -m -s /bin/bash appuser  USER appuser

3.2.2 Убедитесь, что в образ контейнера добавлена команда HEALTHCHECK

Команда health check позволяет Docker engine отслеживать состояние контейнера. Docker engine может перезапустить контейнер или запустить новые инстансы при необходимости. Мы используем Spring Boot и также добавили Spring Actuator в наш pom файл. Spring Actuator содержит URL для проверки состояния, который мы можем использовать в данном случае. Определим health check в нашем Dockerfile:

HEALTHCHECK --interval=5m --timeout=3s CMD  curl -f http://localhost:8080/actuator/health/ || exit 1

3.2.3 Убедитесь, что используется COPY вместо ADD в Dockerfile

Последнее, что мы исправим, — использовать COPY вместо ADD. Оба почти одинаковы, но COPY более точный. Строка с командой ADD:

ADD ${JAR_FILE} app.jar

Меняем ее на:

COPY ${JAR_FILE} app.jar

3.3 Повторный запуск анализа

Пересоберем приложение, чтобы сгенерировать новый Docker image, с помощью mvn clean install. Затем остановим запущенный контейнер и удалим его.

$ docker stop mykubernetesplanet  $ docker rm mykubernetesplanet

Запустим новый контейнер, используя новый Docker image:

$ docker run --name=mykubernetesplanet mydeveloperplanet/mykubernetesplanet:0.0.3-SNAPSHOT  Теперь запустим Docker Bench for Security:  [INFO] 4 - Container Images and Build File  [PASS] 4.1 - Ensure a user for the container has been created  [NOTE] 4.2 - Ensure that containers use trusted base images  [NOTE] 4.3 - Ensure unnecessary packages are not installed in the container  [NOTE] 4.4 - Ensure images are scanned and rebuilt to include security patches  [WARN] 4.5 - Ensure Content trust for Docker is Enabled  [WARN] 4.6 - Ensure HEALTHCHECK instructions have been added to the container image  [WARN] * No Healthcheck found: [openjdk:10-jdk]  [WARN] * No Healthcheck found: [mydeveloperplanet/mykubernetesplanet:0.0.2-SNAPSHOT]  [INFO] 4.7 - Ensure update instructions are not use alone in the Dockerfile  [INFO] * Update instruction found: [mydeveloperplanet/mykubernetesplanet:0.0.3-SNAPSHOT]  [INFO] * Update instruction found: [openjdk:10-jdk]  [INFO] * Update instruction found: [mydeveloperplanet/mykubernetesplanet:0.0.2-SNAPSHOT]  [NOTE] 4.8 - Ensure setuid and setgid permissions are removed in the images  [INFO] 4.9 - Ensure COPY is used instead of ADD in Dockerfile  [INFO] * ADD in image history: [mydeveloperplanet/mykubernetesplanet:0.0.3-SNAPSHOT]  [INFO] * ADD in image history: [docker/docker-bench-security:latest]  [INFO] * ADD in image history: [openjdk:10-jdk]  [INFO] * ADD in image history: [mydeveloperplanet/mykubernetesplanet:0.0.2-SNAPSHOT]  [NOTE] 4.10 - Ensure secrets are not stored in Dockerfiles  [NOTE] 4.11 - Ensure verified packages are only Installed

Предупреждение, касающееся пользователя, изменилось на PASS, и наша версия образа 0.0.3-SNAPSHOT больше не вызывает предупреждений по поводу health check. У нас всё ещё есть INFO о команде COPY, но это связано с тем, что она всё ещё присутствует в истории нашего образа. Однако, мы знаем, что мы исправили эту проблему, а значит, можем оставить все, как есть. Наш общий рейтинг повысился до 20, что уже несколько лучше, чем 5 ?.

4. Заключение

В этой статье мы рассмотрели CIS Benchmark for Docker и как автоматически проверить его, используя Docker Bench for Security. Прежде чем запускать Docker контейнеры в продакшен, мы советуем внимательнее присмотреться к рекомендациям. Это даст вам больше уверенности при использовании Docker в продакшене.

Присоединяйтесь к русскоязычному сообществу разработчиков на Spring Boot в телеграм — Spring АйО, чтобы быть в курсе последних новостей из мира разработки на Spring Boot и всего, что с ним связано.

Ждем всех, присоединяйтесь

ссылка на оригинал статьи https://habr.com/ru/articles/851604/