Модуль operator-trivy: карта приложений и сети по runtime-поведению

Помимо статического сканирования (уязвимости образов, аудит конфигурации, CIS) модуль может наблюдать, что каждая нагрузка делает в runtime, и превращать эти наблюдения в карту по каждому ворклоаду.

Что содержит карта

При включении на каждом узле работает лёгкий агент, который наблюдает за поведением каждого контейнера с помощью eBPF — без каких-либо изменений в ваших нагрузках. Наблюдения агрегируются по ворклоадам (Deployment, DaemonSet, StatefulSet, …) в два объекта:

• ApplicationProfile — отпечаток приложения: какие процессы запускает нагрузка, какие файлы открывает, какие Linux capabilities и системные вызовы использует.
• NetworkNeighborhood — карта сети: входящие и исходящие соединения нагрузки по узлам-соседям и портам.

Вместе они отвечают на вопрос «что эта нагрузка на самом деле делает и с кем общается?» — на основе данных, наблюдаемых в работающем кластере, а не предполагаемых по манифестам.

Требования

• Ядра узлов должны быть Linux 5.4 или новее и предоставлять BTF в /sys/kernel/btf/vmlinux (стандартно для актуальных образов ОС узлов DKP).
• Агент работает привилегированно с доступом к host PID. По умолчанию он запускается на всех узлах; ограничьте его параметром nodeAgent.nodeSelector, если часть узлов не удовлетворяет требованию к ядру.

Включение

apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
  name: operator-trivy
spec:
  settings:
    nodeAgent:
      enabled: true
      learningPeriod: "1h"
  version: 1

learningPeriod задаёт, сколько времени нагрузка наблюдается, прежде чем её профиль считается завершённым. В течение этого окна карта продолжает вбирать вновь увиденное поведение; после — профиль фиксируется. Для нагрузок, поведение которых меняется в течение суток, используйте большее значение (например, 24h).

Просмотр карты

Объекты карты — неймспейсные, рядом с нагрузками, которые они описывают:

# Отпечатки приложений по всему кластеру
kubectl get applicationprofiles -A

# Карты сети по всему кластеру
kubectl get networkneighborhoods -A

# Полный отпечаток для одной нагрузки
kubectl get applicationprofile -n my-namespace <name> -o yaml

Записанные детали (процессы, файлы, capabilities, соединения) возвращает только пообъектный get … -o yaml. Списочный get applicationprofiles -A перечисляет объекты, но опускает эти поля ради производительности, поэтому он всегда выглядит «пустым» — для просмотра самой карты используйте именованный -o yaml.

Данные начинают появляться в течение пары минут после старта контейнера; профиль продолжает расти и помечается завершённым по истечении периода обучения. Дайте только что включённой нагрузке хотя бы learningPeriod, прежде чем ожидать полную карту.

Генерация least-privilege политик

Когда карта нагрузки построена, модуль может превратить её в least-privilege политики. Включите одно или оба:

spec:
  settings:
    nodeAgent:
      enabled: true
      generatePolicies:
        networkPolicy: true
        seccomp: true
  version: 1

Сетевые политики

При networkPolicy: true из наблюдаемого NetworkNeighborhood каждой нагрузки вычисляется GeneratedNetworkPolicy — готовая к проверке Kubernetes NetworkPolicy, описывающая ровно тот трафик, который у нагрузки наблюдался.

kubectl get generatednetworkpolicies -A
kubectl get generatednetworkpolicy -n my-namespace <name> -o yaml

Объект содержит стандартную NetworkPolicy в .spec. Проверьте её, затем извлеките и примените, чтобы обеспечить least privilege:

kubectl get generatednetworkpolicy -n my-namespace <name> \
  -o json | jq '.spec' | kubectl apply -f -

Seccomp-профили

При seccomp: true из наблюдаемых системных вызовов каждой нагрузки генерируется SeccompProfile.

kubectl get seccompprofiles -A
kubectl get seccompprofile -n my-namespace <name> -o yaml

Сохраните профиль в каталог seccomp kubelet на каждом узле (например, с помощью Security Profiles Operator), затем сошлитесь на него из пода:

spec:
  securityContext:
    seccompProfile:
      type: Localhost
      localhostProfile: operator-trivy/<name>.json