cnitch

cnitch (snitch или container snitch) — это простая среда и инструмент командной строки для мониторинга Docker-контейнеров с целью выявления процессов, работающих от имени root.

Почему это плохо? Если вы ещё не были на can I haz non-privileged containers? от mhausenblas, то рекомендую сразу перейти туда, чтобы получить всю информацию.

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

FROM alpine

RUN adduser -h /home/cnitch -D cnitch cnitch

COPY ./cmd/cnitch /home/cnitch/
RUN chmod +x /home/cnitch/cnitch

#USER cnitch

ENTRYPOINT ["/home/cnitch/cnitch"]

Когда я тестировал контейнер приложения, чтобы разобраться с проблемой прав доступа к Docker-сокету, я, должно быть, закомментировал команду USER. Весьма мета, cnitch помог найти проблему в cnitch; это определённо попадёт в интеграционные тесты.

Как это работает

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

2017/07/29 16:04:27 Starting Cnitch: Monitoring Docker Processes at: tcp://172.16.255.128:2376
2017/07/29 16:04:27 Checking for root processes every: 10s
2017/07/29 16:05:08 Checking image: ubuntu, id: 7bd489560a310343c39186500daa680290289c27f7a730524a31355a3aaf0430
2017/07/29 16:05:08 >> WARNING: found process running as root: tail -f /dev/null pid: 365

Модули отчётов

В настоящее время cnitch умеет отчитываться в StatsD и StdOut. Бэкенды для отчётов являются расширяемыми, что позволяет легко поддерживать любой бэкенд; например, создание бэкенда для log stash или другого инструмента агрегации логов — довольно тривиальная задача.

StatsD

Исключения отправляются в endpoint statsD как счётчик с метрикой cnitch.exception.root_process. Метрики также помечаются тегами: имя хоста host экземпляра cnitch и имя контейнера container.

StdOut

Логгер StdOut — это простой логгер вывода, который отправляет зафиксированные исключения в StdOut.

Как запустить

Запускаете ли вы cnitch в Docker-контейнере или как бинарный файл, ему необходим доступ к API Docker. Для этого задайте URL сервера или путь к сокету с помощью переменной окружения DOCKER_HOST.

Флаги

• --hostname=[hostname] — имя или IP-адрес, используемый для агрегации метрик
• --statsd-server=[hostname:port] — URI statsd-коллектора; если опущен, отчёты в statsd будут отключены
• --check=[duration например, 10s (10 секунд), 1m (1 минута)] — частота проверки, с которой snitch будет сканировать корневые процессы

Командная строка

Установите переменную окружения DOCKER_HOST на ваш API Docker Engine, затем запустите snitch с необходимыми флагами.

$ cnitch --hostname=myhost --statsd-server=127.0.0.1:8125 --check=10s

Docker

cnitch работает в непривилегированном контейнере, и если вы хотите использовать Docker-сокет для доступа к API, вам нужно добавить пользователя cnitch в группу docker. Это можно сделать с помощью флага --group-add, установив его в идентификатор группы docker.
Например:

--group-add=$(stat -f "%g" /var/run/docker.sock)

Пример использования файла Docker-сокета для доступа к API

$ docker run -i -t --rm \
  -v /var/run/docker.sock:/var/run/docker.sock \
  --group-add=$(stat -f "%g" /var/run/docker.sock) \
  -e "DOCKER_HOST:unix:///var/run/docker.sock" \
  quay.io/nicholasjackson/cnitch [options]

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

Пример

В папке ./example находится пример Docker Compose стека, который показывает, как cnitch экспортирует данные в statsd. Чтобы запустить этот пример:

$ cd ./example
$ docker-compose up

После того, как всё запустится, откройте в браузере http://[docker host ip]:3000, и вы увидите экран входа в Grafana.

Войдите в Grafana, используя следующие учётные данные:

• пользователь: admin
• пароль: admin

Затем выберите панель мониторинга cnitch. Эта панель показывает текущие запущенные корневые процессы.

Если вы не используете /var/run/docker.sock для связи с вашим Docker-хостом, вам потребуется изменить некоторые настройки в файле ./example/docker-compose.yml в соответствии с вашими настройками.

План развития

Реализовать функции из сценария безопасности Docker Bench Security https://github.com/docker/docker-bench-security

[ ] 1.1 Обеспечить создание отдельного раздела для контейнеров
[ ] 1.2 Обеспечить усиление защиты хоста контейнеров
[ ] 1.3 Обеспечить актуальность Docker
[ ] 1.4 Обеспечить, чтобы только доверенные пользователи могли управлять демоном Docker
[ ] 1.5 Обеспечить настройку аудита для демона Docker
[ ] 1.6 Обеспечить настройку аудита для файлов и каталогов Docker - /var/lib/docker
[ ] 1.7 Обеспечить настройку аудита для файлов и каталогов Docker - /etc/docker
[ ] 1.8 Обеспечить настройку аудита для файлов и каталогов Docker - docker.service
[ ] 1.9 Обеспечить настройку аудита для файлов и каталогов Docker - docker.socket
[ ] 1.10 Обеспечить настройку аудита для файлов и каталогов Docker - /etc/default/docker
[ ] 1.11 Обеспечить настройку аудита для файлов и каталогов Docker - /etc/docker/daemon.json
[ ] 1.12 Обеспечить настройку аудита для файлов и каталогов Docker - /usr/bin/docker-containerd
[ ] 1.13 Обеспечить настройку аудита для файлов и каталогов Docker - /usr/bin/docker-runc

[ ] 2.1 Обеспечить ограничение сетевого трафика между контейнерами на мосту по умолчанию
[ ] 2.2 Установить уровень логирования на 'info'
[ ] 2.3 Разрешить Docker вносить изменения в iptables
[ ] 2.4 Не использовать небезопасные реестры
[ ] 2.5 Не использовать драйвер хранения aufs
[ ] 2.6 Настроить аутентификацию TLS для демона Docker
[ ] 2.7 Настроить ulimit по умолчанию соответствующим образом
[ ] 2.8 Включить поддержку пространства имён пользователя
[ ] 2.9 Подтвердить использование cgroup по умолчанию
[ ] 2.10 Не изменять размер базового устройства до необходимости
[ ] 2.11 Включить авторизацию для команд клиента Docker
[ ] 2.12 Настроить централизованное и удалённое логирование
[ ] 2.13 Запретить операции с устаревшим реестром (v1)
[ ] 2.14 Включить live restore
[ ] 2.15 Отключить Userland Proxy
[ ] 2.16 Применить общедемонный профиль seccomp, если необходимо
[ ] 2.17 Избегать экспериментальных функций в производственной среде
[ ] 2.18 Запретить контейнерам получать новые привилегии

[ ] 3.x ...

[x] 4.1 Создать пользователя для контейнера
[ ] 4.2 Использовать доверенные базовые образы для контейнеров
[ ] 4.3 Не устанавливать ненужные пакеты в контейнере
[ ] 4.4 Сканировать образы и пересобирать их с учётом исправлений безопасности
[ ] 4.5 Включить Content Trust для Docker
[ ] 4.6 Добавить инструкции HEALTHCHECK в образ контейнера
[ ] 4.7 Не использовать инструкции обновления отдельно в Dockerfile
[ ] 4.8 Удалить права setuid и setgid в образах
[ ] 4.9 Использовать COPY вместо ADD в Dockerfile
[ ] 4.10 Не хранить секреты в Dockerfile
[ ] 4.11 Устанавливать только проверенные пакеты

[ ] 5.x ...

[ ] 6.x ...

[ ] 7.x ...