Инженерия детекции в Kubernetes: почему скоуп важнее объема при ловле атак

Инженерия детекции в Kubernetes: почему скоуп важнее объема при ловле атак

Публичные кластеры Kubernetes начинают подвергаться сканированию в первые 18 минут после развертывания. Полноценная видимость происходящего в кластере жизненно необходима, однако сбор абсолютно всех генерируемых логов в централизованные системы анализа (SIEM — системы управления событиями информационной безопасности) приводит к колоссальным затратам на хранение и тонет в шуме. Решением становится отказ от простых пороговых детекторов по объему трафика в пользу статистического анализа области доступа (скоупинга).

Большинство атак в облачной инфраструктуре строится на методике Living off the Land: злоумышленники не внедряют посторонние бинарные файлы, а используют штатные утилиты и легитимные сервисные учетные записи. Такие действия не создают аномальных всплесков сетевого трафика. Единственный надежный способ выявления таких вторжений — построение поведенческого бейслайна аудитных событий API-сервера.

Ландшафт телеметрии Kubernetes: где искать сигнал

Кластер Kubernetes генерирует данные на нескольких уровнях, каждый из которых решает свои задачи:

1. Контрольный уровень (Control Plane):
   • Аудитные логи API-сервера: основной источник данных для детекции безопасности. Фиксируют каждого субъекта, выполняемое действие (verb), целевой ресурс, пространство имен (namespace) и решение авторизации.
   • Логи планировщика (Scheduler) и контроллеров: служат для отладки размещения подов и циклов синхронизации, но практически бесполезны для поиска вторжений.
2. Уровень рабочих узлов (Node Level):
   • Логи Kubelet и контейнерного рантайма: отслеживают жизненный цикл контейнеров на конкретном сервере.
3. Уровень приложений и сети:
   • Логи подов (stdout/stderr): предназначены для разработчиков, искать в них следы атак крайне сложно из-за отсутствия единой структуры.
   • Сетевые логи (Flow Logs): требуют обогащения метаданными CNI-плагина, так как динамические IP-адреса подов постоянно меняются.

Попытка агрегировать все эти слои без разбора создает проблему «write-only memory» — терабайты нечитаемых записей, за которые компания платит провайдеру, но не может использовать для своевременного обнаружения инцидентов.

Архитектура Audit Policy: баланс между видимостью и производительностью

Аудитные события API-сервера оцениваются политикой сверху вниз до первого совпадения. Стандарт определяет четыре уровня детализации:

• None — событие полностью игнорируется (необходимо для системных служебных аккаунтов вроде kube-proxy).
• Metadata — сохраняются автор запроса, время, ресурс, метод и статус ответа без тел запроса и ответа.
• Request — метаданные плюс тело входящего запроса (что отправил пользователь).
• RequestResponse — полные тела запроса и ответа сервера.

!WARNING Использование уровня RequestResponse для секретов (secrets) категорически недопустимо: это приводит к записи чувствительных паролей и токенов в открытом виде в журнал аудита. Для секретов должен применяться исключительно уровень Metadata.

Пример безопасной и производительной политики аудита audit-policy.yaml:

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  # Исключаем системный шум контроллеров и статусных обновлений
  - level: None
    resources:
      - group: ""
        resources: ["events", "endpoints", "nodes/status", "pods/status"]
      - group: "coordination.k8s.io"
        resources: ["leases"]
  - level: None
    users: ["system:kube-proxy", "system:kube-controller-manager", "system:kube-scheduler"]
    verbs: ["get", "list", "watch"]

  # Фиксируем тела запросов для критичных изменений прав доступа RBAC
  - level: Request
    verbs: ["create", "update", "patch", "delete"]
    resources:
      - group: "rbac.authorization.k8s.io"
        resources: ["clusterrolebindings", "rolebindings", "clusterroles", "roles"]

  # Метаданные для интерактивных сессий и чтения секретов
  - level: Metadata
    resources:
      - group: ""
        resources: ["pods/exec", "pods/portforward", "serviceaccounts/token", "secrets"]

  # Базовый уровень для всех остальных ресурсов
  - level: Request

Для предотвращения деградации API-сервера в высоконагруженных кластерах аудит настраивается в пакетном режиме: --audit-log-mode=batch. Здоровье подсистемы аудита отслеживается через метрики Prometheus: apiserver_audit_event_total, apiserver_audit_error_total и apiserver_audit_requests_rejected_total.

Почему объемные детекторы терпят крах

Классические правила мониторинга безопасности настроены на пороги объемов: например, отправка алерта, если пользователь сделал более 100 запросов в минуту. В облачных средах эта логика перестает работать.

Рассмотрим типичный четырехфазный сценарий атаки (по модели операций SCARLETEEL):

1. Внешняя разведка: анонимный перебор эндпоинтов API снаружи кластера, генерирующий ошибки доступа HTTP 403.
2. Первичный доступ: компрометация пользовательской сессии (например, веб-интерфейса Jupyter Notebook). Событие происходит на уровне приложения и не видно в API Kubernetes.
3. Обнаружение (Discovery): атакующий выполняет kubectl get pods от имени скомпрометированного сотрудника в продуктовых пространствах имен, куда этот сотрудник никогда раньше не заходил.
4. Смена контекста (Pivot): получение токена смонтированной сервисной учетной записи notebook-sa и массовое чтение секретов соседних команд.

В процессе атаки генерируется всего 4–5 запросов в час, что полностью укладывается в нормальный дневной диапазон активности инженера (от 1 до 12 запросов). Объемный детектор не сработает. Однако область доступа (скоуп) кардинально изменилась: пользователь обратился к ресурсам, с которыми никогда не взаимодействовал.

Статистический скоупинг: методология построения бейслайна

Статистический скоупинг строится на анализе нормального профиля поведения пользователей и сервисных аккаунтов за скользящий период в 21–30 дней:

• Проблема разреженности данных: стандартное распределение Пуассона неприменимо для анализа запросов в Kubernetes из-за избытка нулевых интервалов (zero-inflation) и высокой дисперсии.
• Использование межквартильного размаха (IQR): расчет верхней границы нормы через квантили ранговой статистики позволяет надежно оценивать всплески без строгих допущений о виде распределения.
• Категориальное расширение периметра: составление множеств known_namespaces и known_resources для каждой учетной записи. Любое обращение к новому пространству имен мгновенно генерирует сигнал высокой точности.

Сравнение двух подходов к детекции:

Пять правил надежной детекции и чеклист харденинга

Эффективная система защиты строится на композитных правилах, объединяющих несколько независимых сигналов:

1. Всплеск запретов (403 Spray): фиксация 5 и более ответов HTTP 403 за 10 минут от одного источника (признак сканирования прав).
2. Категориальное расширение: обращение учетной записи к пространству имен вне ее 30-дневного бейслайна.
3. Аномальное чтение секретов: превышение 95-го перцентиля (P95) часового обращения к объектам secrets.
4. Прямое изменение RBAC: создание или модификация ClusterRoleBinding не через утвержденный инструмент GitOps (ArgoCD/Flux).
5. Композитный коррелятор: срабатывание двух и более независимых эвристик по одному субъекту в рамках часового окна.

Чеклист снижения рисков (Hardening):

• Вынести тестовые и исследовательские окружения (sandbox) в отдельные физические кластеры, исключив совместное размещение с продакшеном.
• Ограничить права сервисных учетных записей: заменить широкие ClusterRoleBinding на узкие пространства имен RoleBinding.
• Запретить анонимный доступ к API-серверу (--anonymous-auth=false).
• Внедрить admission-контроллеры (Kyverno, Gatekeeper) для блокировки запуска контейнеров от пользователя root и монтирования hostPath.
• Настроить аудит в батч-режиме и выставить алерты на рост счетчика сброшенных логов apiserver_audit_error_total.