Привет, коллеги. Я DevSecOps-инженер, и Wolfee-Watcher в первую очередь сделал для себя — чтобы решить знакомую боль. Для нормального security-мониторинга Kubernetes обычно приходится разворачивать целый зоопарк: один инструмент проверяет конфигурацию, другой следит за runtime, третий сканирует образы, отдельные решения нужны для алертов и форензики. Всё это надо развернуть, связать, обновлять и поддерживать, а данные всё равно остаются разбросаны по разным дашбордам.

Wolfee-Watcher объединяет Kubernetes posture management, runtime security, container forensics и vulnerability scanning в одном self-hosted инструменте. Раз уж проект получился, я решил выпустить его в open source. Это первый инструмент под зонтиком Wolfee-Security — инициативы, в рамках которой я хочу закрывать реальные боли существующих open-source security-продуктов.

Зачем это приложение нужно? Кластер может выглядеть защищённым и при этом оставаться слепой зоной. RBAC, NetworkPolicy, admission-контроллеры и сканеры манифестов хорошо показывают, как кластер сконфигурирован, но не отвечают на вопрос, что реально происходит внутри контейнера в runtime. • Какой процесс внезапно запустился? • Кто открыл исходящее соединение? • Какой файл изменился? • Появился ли неизвестный бинарь? • Загружался ли kernel-модуль? Именно в runtime проявляются последствия компрометации: reverse shell, майнеры, lateral movement, запуск посторонних бинарей и неожиданные сетевые соединения. А после удаления pod расследование часто заканчивается фразой: «контейнера уже нет — смотреть нечего».

Что умеет Wolfee-Watcher? • Kubernetes Security Posture / CIS Benchmark — следит за K8s API и выявляет privileged-контейнеры, hostPID/hostIPC/hostNetwork, опасные capabilities, cluster-admin и wildcard-RBAC, секреты в env, отсутствие NetworkPolicy и другие misconfig’и. • Runtime Security через eBPF / Tracee — системные вызовы, процессы, файловые и сетевые операции, tracepoints, LSM- и BPF-события, загрузка kernel-модулей. ➡ И да — операции через io_uring мы видим тоже. • Сетевой мониторинг — видно, какой pod/process, куда и на какой порт устанавливает соединение. Неожиданный outbound traffic можно использовать как отдельный security-сигнал. • Container Forensics — история изменения файлов, runtime-события, логи и экспорт в TAR. Данные сохраняются даже после удаления pod, поэтому расследование можно проводить уже после инцидента. • Vulnerability Management — сканирование образов через Grype с дополнительным маппингом CVE на ФСТЭК БДУ. • Alerts — уведомления о подозрительных syscalls, tracepoints, сетевых соединениях и anomalies с доставкой в Discord и Mattermost. • Honeypots — приманки для обнаружения активности там, где её в нормальном сценарии вообще быть не должно.

Baseline и anomaly detection Одна из ключевых возможностей — обучение нормальному поведению приложения. Wolfee-Watcher за настраиваемое окно наблюдения (по умолчанию 10 дней) строит baseline для пода: Система запоминает: • какие бинарники обычно запускаются; • какие syscall используются; • куда workload обычно ходит по сети; • какие порты и направления являются нормальными. После фиксации baseline новое поведение сравнивается с эталоном. ¿ Если приложение обычно запускает только nginx и php-fpm, а затем внезапно появляется bash, nc, curl или неизвестный бинарь — это anomaly. ¿ То же самое с сетью: новый IP, порт или направление, которых раньше у workload не было, становятся отдельным сигналом. То есть detection строится не только на статичных правилах, но и на реальном поведении именно вашего приложения. Runtime-события собираются через eBPF / Tracee, работающий DaemonSet’ом на каждой ноде. Идея Wolfee-Watcher простая: вместо десятка разрозненных security-инструментов дать инженеру одно место, где можно увидеть конфигурационные риски, runtime-активность, уязвимости, аномалии и данные для расследования