Модуль runtime-audit-engine

Описание

Модуль предназначен для поиска угроз безопасности.

Модуль собирает события ядра Linux и итоги аудита API Kubernetes (с помощью плагина k8saudit), обогащает их метаданными о подах Kubernetes и генерирует события аудита безопасности по установленным правилам.

Модуль runtime-audit-engine:

• Находит угрозы в окружениях, анализируя приложения и контейнеры.
• Помогает обнаружить попытки применения уязвимостей из базы CVE и запуска криптовалютных майнеров.
• Повышает безопасность Kubernetes, выявляя:
  • оболочки командной строки, запущенные в контейнерах или подах в Kubernetes;
  • контейнеры, работающие в привилегированном режиме; монтирование небезопасных путей (например, /proc) в контейнеры;
  • попытки чтения секретных данных из, например, /etc/shadow.

Требования

Операционная система

Модуль использует драйвер eBPF для Falco при сборке событий ядра операционной системы. Этот драйвер особенно полезен в окружениях, в которых невозможна сборка модуля ядра (например, GKE, EKS и другие решения Managed Kubernetes). У драйвера eBPF есть следующие требования:

• Версия ядра Linux >= 5.8 с поддержкой eBPF.
• Поддержка формата метаданных BPF Type Format (BTF). Проверить можно следующими способами:
  • выполнить команду ls -lah /sys/kernel/btf/vmlinux — наличие файла подтверждает поддержку BTF;
  • выполнить команду grep -E "CONFIG_DEBUG_INFO_BTF=(y|m)" /boot/config-* — если параметр включён, BTF поддерживается.

На некоторых системах пробы (probe) eBPF могут не работать.

Процессор и память

Агенты Falco работают на каждом узле. Поды агентов потребляют ресурсы в зависимости от количества применяемых правил или собираемых событий.

Включение модуля

Чтобы включить модуль runtime-audit-engine с настройками по умолчанию, примените следующий ресурс ModuleConfig:

d8 k apply -f - <<EOF
apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
  name: runtime-audit-engine
spec:
  version: 1
  enabled: true
EOF

Kubernetes audit webhook

Режим Webhook audit mode должен быть настроен на получение событий аудита от kube-apiserver. Если модуль control-plane-manager включен, настройки автоматически применятся при включении модуля runtime-audit-engine.

В кластерах Kubernetes, в которых control plane не управляется Deckhouse, webhook необходимо настроить вручную. Для этого:

1. Создайте файл kubeconfig для webhook с адресом https://127.0.0.1:9765/k8s-audit и CA (ca.crt) из секрета d8-runtime-audit-engine/runtime-audit-engine-webhook-tls.

   Пример:

   apiVersion: v1
   kind: Config
   clusters:
   - name: webhook
     cluster:
       certificate-authority-data: BASE64_CA
       server: "https://127.0.0.1:9765/k8s-audit"
   users:
   - name: webhook
   contexts:
   - context:
      cluster: webhook
      user: webhook
     name: webhook
   current-context: webhook
   

2. Добавьте к kube-apiserver флаг --audit-webhook-config-file, который будет указывать на файл, созданный на предыдущем шаге.

Архитектура

Ядро модуля основано на системе обнаружения угроз Falco. Deckhouse запускает агенты Falco (объединены в DaemonSet) на каждом узле, после чего те приступают к сбору событий ядра и данных, полученных в ходе аудита Kubernetes.

Один под Falco состоит из четырех контейнеров:

1. falco — собирает события, обогащает их метаданными и отправляет их в stdout.
2. rules-loader — собирает кастомные ресурсы (FalcoAuditRules) из Kubernetes и сохраняет их в общую папку.
3. falcosidekick — принимает события от Falco и перенаправляет их разными способами. По умолчанию экспортирует события как метрики, по которым потом можно настроить алерты. За подробной информацией обратитесь к исходному коду Falcosidekick.
4. kube-rbac-proxy — защищает эндпоинт метрик falcosidekick (запрещает неавторизованный доступ).

Правила аудита

Сборка событий сама по себе не дает ничего, поскольку объем данных, собираемый с ядра Linux, слишком велик для анализа человеком. Правила позволяют решить эту проблему: события отбираются по определенным условиям. Условия настраиваются на выявление любой подозрительной активности.

В основе каждого правила лежит выражение, содержащее определенное условие, написанное в соответствии с синтаксисом условий.

Встроенные правила

Существует набор встроенных правил, который нельзя отключить. Он помогает выявить проблемы с безопасностью Deckhouse и с самим модулем runtime-audit-engine. Это правила для аудита Kubernetes, статично размещённые в контейнере falco по пути /etc/falco/k8s_audit_rules.yaml.

Также существуют дополнительный набор встроенных правил:

• правила, размещённые в формате кастомного ресурса FalcoAuditRules, fstec — правила аудита, удовлетворяющие требованиям приказа ФСТЭК России №118 от 4 июля 2022 г. («Требования по безопасности информации к средствам контейнеризации»).

Чтобы вывести список всех правил аудита falco, выполните:

d8 k -n d8-runtime-audit-engine exec -it daemonsets/runtime-audit-engine -c falco -- falco -L

Настроить список встроенных правил можно с помощью параметра settings.builtInRulesList.

Пользовательские правила

Добавить пользовательские правила можно с помощью кастомного ресурса FalcoAuditRules. У каждого агента Falco есть sidecar-контейнер с экземпляром shell-operator. Этот экземпляр считывает правила из кастомных ресурсов Kubernetes, конвертирует их в правила Falco и сохраняет правила Falco в директорию /etc/falco/rules.d/ пода. При добавлении нового правила Falco автоматически обновляет конфигурацию.

Такая схема позволяет использовать подход «Инфраструктура как код» при работе с правилами Falco.

Алерты

Если несколько подов runtime-audit-engine не назначены на узлы планировщиком, будет сгенерирован алерт D8RuntimeAuditEngineNotScheduledInCluster.