Стадия жизненного цикла модуля: General Availability

У модуля есть требования для установки

Как собирать события?

Поды runtime-audit-engine выводят все события в стандартный вывод. Далее агенты log-shipper могут собирать их и отправлять в хранилище логов.

Пример конфигурации ClusterLoggingConfig для модуля log-shipper:

apiVersion: deckhouse.io/v1alpha2
kind: ClusterLoggingConfig
metadata:
  name: falco-events
spec:
  destinationRefs:
  - xxxx
  kubernetesPods:
    namespaceSelector:
      labelSelector:
        matchExpressions:
        - key: "kubernetes.io/metadata.name"
          operator: In
          values: [d8-runtime-audit-engine]
  labelFilter:
  - operator: Regex
    values: ["\\{.*"] # Для сбора логов только в формате JSON.
    field: "message"
  type: KubernetesPods

Как оповещать о критических событиях?

Оповещения о критических событиях настраиваются двумя способами: через модуль security-events-manager либо через собственное правило Prometheus.

Основной способ — модуль security-events-manager. Он собирает события Falco из логов, приводит их к единому формату и вычисляет по ним правила оповещения, поэтому правило описывается в терминах событий безопасности, а не метрик.

Интеграция поставляется вместе с модулем runtime-audit-engine: для встроенных правил Falco создаются ресурсы SecurityEventDefinition и PodSecurityEventShipper, поэтому события попадают в конвейер обработки сразу после включения обоих модулей. Настройка правил оповещения описана в разделе «Алертинг по событиям безопасности».

Второй способ — правило Prometheus по метрикам, которые модуль экспортирует автоматически. Он не требует дополнительных модулей, но оперирует счётчиками событий, а не их содержимым.

Чтобы включить оповещения, добавьте в кластер правило CustomPrometheusRule.

Пример настройки такого правила:

apiVersion: deckhouse.io/v1
kind: CustomPrometheusRules
metadata:
  name: falco-critical-alerts
spec:
  groups:
  - name: falco-critical-alerts
    rules:
    - alert: FalcoCriticalAlertsAreFiring
      for: 1m
      annotations:
        description: |
          There is a suspicious activity on a node {{ $labels.node }}. 
          Check you events journal for more details.
        summary: Falco detects a critical security incident
      expr: |
        sum by (node) (rate(falcosecurity_falcosidekick_falco_events_total{priority_raw="critical"}[5m]) > 0)

В метрике falcosecurity_falcosidekick_falco_events_total уровень важности события передаётся двумя лейблами: priority содержит числовое значение, а priority_raw — название уровня строчными буквами. Фильтруйте события по лейблу priority_raw; соответствие числовых и текстовых значений приведено в разделе «Просмотр метрик».

Пример выше охватывает только уровни от emergency до debug. У события, пришедшего без приоритета, лейбл priority_raw пустой, и ни один селектор по priority_raw его не выбирает — если такие события нужно учитывать, добавьте в алерт условие по priority.

Алерты лучше всего работают в комбинации с хранилищами событий, такими как Elasticsearch или Loki. Их задача — оповестить пользователя о подозрительном поведении на узле. После получения алерта рекомендуется обратиться к хранилищу и посмотреть на события, которые его вызвали.

Как применить правила для Falco, найденные в интернете?

Структура правил Falco отличается от схемы CRD. Это связано со сложностями при проверке правильности ресурсов в Kubernetes.

Скрипт для конвертации правил Falco в ресурсы FalcoAuditRules встроен в функционал утилиты d8.
С его помощью можно применять правила Falco в Deckhouse:

d8 tools far-converter /path/to/falco/rule_example.yaml > ./my-rules-cr.yaml

Пример результата работы скрипта:

# /path/to/falco/rule_example.yaml
- macro: spawned_process
  condition: (evt.type in (execve, execveat) and evt.dir=<)

- rule: Linux Cgroup Container Escape Vulnerability (CVE-2022-0492)
  desc: "This rule detects an attempt to exploit a container escape vulnerability in the Linux Kernel."
  condition: container.id != "" and proc.name = "unshare" and spawned_process and evt.args contains "mount" and evt.args contains "-o rdma" and evt.args contains "/release_agent"
  output: "Detect Linux Cgroup Container Escape Vulnerability (CVE-2022-0492) (user=%user.loginname uid=%user.loginuid command=%proc.cmdline args=%proc.args)"
  priority: CRITICAL
  tags: [process, mitre_privilege_escalation]
# ./my-rules-cr.yaml
apiVersion: deckhouse.io/v1alpha1
kind: FalcoAuditRules
metadata:
  name: rule-example
spec:
  rules:
    - macro:
        name: spawned_process
        condition: (evt.type in (execve, execveat) and evt.dir=<)
    - rule:
        name: Linux Cgroup Container Escape Vulnerability (CVE-2022-0492)
        condition: container.id != "" and proc.name = "unshare" and spawned_process and evt.args contains "mount" and evt.args contains "-o rdma" and evt.args contains "/release_agent"
        desc: This rule detects an attempt to exploit a container escape vulnerability in the Linux Kernel.
        output: Detect Linux Cgroup Container Escape Vulnerability (CVE-2022-0492) (user=%user.loginname uid=%user.loginuid command=%proc.cmdline args=%proc.args)
        priority: Critical
        tags:
          - process
          - mitre_privilege_escalation

Как настраивать ресурсы для DaemonSet?

Модуль runtime-audit-engine позволяет гибко настраивать запросы ресурсов для своего DaemonSet. Это особенно полезно в гетерогенных кластерах, где узлы имеют разную производительность.

Режимы управления ресурсами

Вы можете выбрать один из двух режимов управления запросами ресурсов с помощью параметра resourcesRequests.mode:

  • Static: вы явно указываете ресурсы для подов. См. resourcesRequests.static.
  • VPA: ресурсы управляются автоматически с помощью Vertical Pod Autoscaler. См. resourcesRequests.vpa.

Пример статической конфигурации:

spec:
  settings: 
    resourcesRequests:
      mode: Static
      static:
        cpu: "100m"
        memory: "256Mi"

Разделение рекомендаций VPA (Scoping)

VPA Scoping — это механизм, который позволяет Vertical Pod Autoscaler генерировать независимые рекомендации по ресурсам для разных групп подов внутри одного DaemonSet. Это критически важно для кластеров с гетерогенными узлами, где одна и та же нагрузка (например, Falco) может потреблять существенно разное количество ресурсов в зависимости от характеристик узла.

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

По умолчанию в Deckhouse версии 1.76 и выше модуль использует параметр resourcesRequests.vpa.scopeLabel со стандартным значением node.deckhouse.io/group.

VPA отслеживает указанную метку на узлах и автоматически разделяет поды DaemonSet на подгруппы:

  • __absent__: узлы, на которых указанный ключ метки отсутствует.
  • "" (пустая строка): узлы, на которых ключ метки существует, но не имеет значения.
  • Конкретные значения: для каждого уникального значения метки создается отдельная группа рекомендаций (например, worker, system, gpu).

Когда требуется изменение метки области видимости

Вам может потребоваться изменить scopeLabel, если потребление ресурсов зависит от факторов, отличных от стандартных групп узлов Deckhouse. Например, в Yandex Cloud вы можете захотеть сгруппировать рекомендации по физическому размеру (flavor) инстанса или по кастомным маркерам оборудования.

Пример: группировка по типу инстанса Yandex Cloud с использованием метки node.kubernetes.io/instance-type:

apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
  name: runtime-audit-engine
spec:
  version: 1
  enabled: true
  settings:
    resourcesRequests:
      mode: VPA
      vpa:
        mode: Auto
        scopeLabel: "node.kubernetes.io/instance-type"

При такой конфигурации под, запущенный на инстансе c3-m8, получит от VPA рекомендацию, отличную от пода на инстансе s2-m2, что обеспечит оптимальное распределение ресурсов во всей вашей облачной инфраструктуре.

Взаимодействие LimitRange и VPA

LimitRange опционален и по умолчанию не используется.

Используйте resourcesRequests.limitRange так:

  • false — явно не создавать LimitRange;
  • объект — создать LimitRange с указанными ограничениями.

Важно: при использовании VPA значения LimitRange действуют как жесткие границы. Рекомендации VPA будут ограничены значениями max и дополнены значениями min, определенными в LimitRange.

Минимальные требования к ресурсам

Чтобы гарантировать запуск и корректную работу подов, необходимо убедиться, что значения LimitRange не ниже статических ресурсов, определенных для контейнеров.

Модуль использует следующие статические ресурсы для своих компонентов:

  • Falco: 50m CPU, 64Mi Memory.
  • Falcosidekick: 5m CPU, 10Mi Memory.
  • Rules Loader: 10m CPU, 25Mi Memory.

Если вы установите containerMin или containerDefaultRequest в LimitRange выше этих значений, поды не смогут запуститься.

Рекомендуемые минимальные значения для LimitRange:

  • Память: не менее 64Mi для containerMin и containerDefaultRequest, чтобы обеспечить работу Falco.
  • CPU: не менее 50m.

Пример безопасной конфигурации:

apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
  name: runtime-audit-engine
spec:
  version: 1
  enabled: true
  settings:
    resourcesRequests:
      limitRange:
        containerMax:
          memory: "1Gi" # Значение по умолчанию
        containerMin:
          memory: "64Mi"
        containerDefaultRequest:
          memory: "64Mi"