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