Каковы наилучшие и всеобъемлющие методы, которые следует учитывать при запуске Docker в производстве?

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

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

Отказ от ответственности: я знаю, что есть политика SE, чтобы избежать «больших бесконечных списков», но я думаю, что этот контрольный список не может быть очень большим ... и в настоящее время бесконечным.

Итак - что это за строительные блоки?

1. Если он еще не развернут, рассмотрите возможность запуска хост-системы Linux с расширенными настройками безопасности - усиленным ядром, SELinux и т. Д.
2. Подумайте об использовании крошечного базового образа Docker, такого как alpine, busybox или даже нуля, например, начните с пустого базового образа
3. Используйте настройки USER, отличные от root
4. Тщательно оцените, чтобы еще больше сократить уже сжатый набор возможностей ядра, предоставленных контейнеру.
5. Для запуска процесса рекомендуется иметь только один исполняемый двоичный файл на контейнер, в идеале статически связанный
6. Те, кто хочет сломать вашу систему, чтобы получить доступ к оболочке, могут задаться вопросом, обнаружили ли они, что в вашем контейнере отключены все оболочки
7. Монтируйте тома только для чтения там, где это возможно

Вопрос: что еще?

Хост, на котором работают контейнеры

Запустите скамью безопасности докера на каждом узле, на котором запускаются докерские контейнеры https://github.com/docker/docker-bench-security

Выполнение следующей команды на узле, который запускает контейнеры Docker:

docker run -it --net host --pid 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

возвращает список проверок:

[INFO] 1 - Host Configuration

[WARN] 1.1  - Ensure a separate partition for containers has been created

[NOTE] 4.2  - Ensure that containers use trusted base images

[PASS] 4.6  - Ensure HEALTHCHECK instructions have been added to the container image

Цитата из репозитория README:

Docker Bench for Security - это скрипт, который проверяет десятки распространенных рекомендаций по развертыванию контейнеров Docker в производстве. Все тесты автоматизированы и основаны на тесте CIS Docker Community Edition Benchmark v1.1.0 .

Некоторые из проблем, о которых сообщает стенд безопасности, можно решить, прочитав официальную статью о безопасности докера и сравнив ее с маркерами, определенными в вопросе, также важны следующие вещи:

• защитить сокет docker daemon, внедрив ssl
• Доверие к контенту с использованием нотариуса и DOCKER_CONTENT_TRUSTпеременной

Докер все еще находится в разработке.

Как и в случае любых других программных ошибок в dev, могут быть добавлены небезопасные функции, могут быть недостатки архитектуры, которые ведут к нарушениям безопасности. Не стоит недооценивать это! Ваша система сегодня может быть полностью безопасной, но с патчем со следующей недели кто-то находит ошибку, пишет эксплойт, и вдруг ваша система становится широко открытой.

Если не требуется, не обновляйте до последней версии. Вместо этого используйте последнюю проверенную версию.

Докер это не виртуализация

Если кто-то сбегает из контейнера Docker, этот злоумышленник немедленно оказывается на реальной машине. Нет второго выхода, подобного виртуализации, который предотвратит нарушение.

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

Докер не имеет защиты

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

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

Докер изображения сам

Дополнительным вариантом является использование Clair .

Clair - это проект с открытым исходным кодом для статического анализа уязвимостей в контейнерах приложений (в настоящее время включает appc и docker).

Клер регулярно получает метаданные об уязвимостях из настроенного набора источников и сохраняет их в базе данных.

Клиенты используют Clair API для индексирования изображений своих контейнеров; это создает список функций, присутствующих на изображении, и сохраняет их в базе данных.

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

Когда происходят обновления метаданных об уязвимостях, в системы оповещения может быть отправлено уведомление о том, что произошло изменение.

Наша цель - обеспечить более прозрачное представление о безопасности контейнерной инфраструктуры. Таким образом, проект получил название Клер в честь французского термина, который переводится как ясный, яркий, прозрачный.

В дополнение к пунктам в этой теме; Следующее было бы моей рекомендацией:

• Получите контроль над Docker PID1 с помощью dumb-init
  • ссылка: PID1 и зомби пожинают проблемы
• Не запускайте Docker в производстве без системы оркестровки контейнеров.
  • Выберите из Кубернетеса, Месоса, Роя и т. Д.
• Используйте gosu для контроля пользователя внутри образа докера
• Следуйте парадигме 12-факторного приложения: если вы запускаете приложения с состоянием в контейнерах, измените их.
  • Если вам действительно нужно запускать приложения с отслеживанием состояния (mysql, zookeeper ,asticsearch) в контейнерах, используйте парадигмы оркестровщиков, такие как Kubernetes Statefulsets
• Надежное управление секретом / конфигурацией с помощью таких инструментов, как hashicorp vault / консул
• Поставьте тот же контейнер, созданный разработчиками, для прохождения через CI-конвейер, который тщательно проходит этапные и интеграционные тесты.
• Создавайте уведомления вокруг CVE и патчей, запускайте сборки на patch-notify
• Обширная регистрация, чтобы получить представление о работающем контейнере, вы не хотите предоставлять devs SSH доступ к хосту или контейнерам.
  • рекомендация: свободно
• Иметь метрики как контейнера, так и хоста
  • рекомендация: прометей + узел-экспортер

Если вы заполняете свою точку входа в докер sedкомандами, рассмотрите эту практику:

• Используйте инструмент, такой как confd, для управления вашими файлами конфигурации образов докера и обновления их

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

Можно использовать A2D, чтобы превратить приложение в образ докера, принимая во внимание определенные вещи, например, не-root, разрешения, местоположение приложения:

docker run -v $PWD:/projectName utrecht/a2d:1.0.0 \
       -projectName someProjectName -dockerfile /projectName/Dockerfile

возвращает:

FROM golang:1.12.4-alpine as builder
COPY . ./someProjectName/
WORKDIR someProjectName
RUN adduser -D -g '' someProjectName && \
    apk add git && \
    CGO_ENABLED=0 go build && \
    cp someProjectName /someProjectName && \
    chmod 100 /someProjectName

FROM scratch
COPY --from=builder /etc/group /etc/group
COPY --from=builder /etc/passwd /etc/passwd
COPY --from=builder --chown=someProjectName:someProjectName /someProjectName /usr/local/someProjectName
COPY --from=builder /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/
USER someProjectName
ENTRYPOINT ["/usr/local/someProjectName"]