Просто о сложном: зачем нужны Kube-Audit логи и как с ними подружиться05.12.2024 12:00

Популярность облачных платформ и контейнеров растет с каждым днем. Вместе с этим появляется необходимость в активном контроле и защите используемых решений.

Есть много инструментов, которые могут сделать работу в K8s безопасной, а процессы — прозрачными и эффективными. Но в статье поговорим о самом недооцененном, но тем не менее актуальном способе для анализа безопасности в Kubernetes: о сборе Kube-Audit логов.

Уровни логирования в Kubernetes

Зачем вообще нужны логи? Это записи событий и оповещений, созданные системой. В них содержится информация о том, что происходит внутри приложений: все ошибки, действия или предупреждения.

Всего существует несколько типов:

• Системные логи. Содержат информацию об ОС и службах, работающих на уровне системы. К ним относятся логи, создаваемые службами Kubernetes, такими как Kubelet, API, server, scheduler, etcd и так далее. Также в список входят логи, обладающие общей информацией о событиях — например, о запуске или остановке подов, изменении в конфигурации.

• Audit-логи. Регистрируют события внутри API-сервера и помогают отслеживать последовательность действий в системе и результаты.

• Прикладные логи. Записываются приложениями, работающими в контейнерах, и содержат любую информацию, которую разработчик посчитает необходимой. Например, записи о сбоях, информацию для отладки или аудит транзакций.

• Логи подов. Дают информацию о конкретных подах и их работе, включая сообщения об ошибках или предупреждения.

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

• Метрики. Содержат информацию о производительности системы Kubernetes и запущенных приложений, в том числе об использовании ресурсов.

Kube-Audit логи: да или нет?

При мониторинге состояния системы большинство пользователей забывают о нативных инструментах аудита. Возможно, многим специалистам не совсем понятно, как их использовать, и насколько они реально могут помочь в эксплуатации Kubernetes.

Все запросы внутри кластера проходят через API-сервер, в то время как Audit-логи позволяют регистрировать запросы к API-серверу. Это возможно благодаря размещению конфигурационного файла непосредственно на Master-узлах кластеров. Такой файл называется политикой аудита (Audit Policy).

Схема обращения компонентов кластера к API-серверу

Если мы имеем небольшой кластер с одним Master-узлом, то все запросы будут проходить через его API-сервер. Если Master-узлов несколько, то запросы будут маршрутизированы между разными API-серверами. Нельзя обеспечить строгое перенаправление запросов разных типов на конкретные API-серверы, а значит на всех Master-узлах должна быть размещена одинаковая политика аудита.

Вопросы, на которые отвечает Audit Policy

В большинстве статей авторы пишут, что политика аудита помогает ответить на следующие вопросы:

• Что случилось?

• Когда это произошло?

• Кто это инициировал?

• Где это наблюдалось?

• Откуда это было инициировано?

Давайте копнем чуть глубже и посмотрим, так ли это и как это происходит в реальности.

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

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

С помощью Audit Policy вы получаете возможность оперативно отреагировать и обнаружить причину некорректного поведения — неверную конфигурацию, отработку дефолтного значения, стороннее вмешательство.

Лог пишется в формате JSON, но также поддерживает строковую запись. Давайте посмотрим на примере Audit-лога, как именно он может ответить на заявленные вопросы.

{
  "_index": "kube-audit-shturval-kir- secured-2024.11.13",
  "_id": "9FF5A5E6-D5C2-0395-74AE-79AFCD496435",
  "_version": 1,
  "_score": null,
  "_source": {
    "@timestamp": "2024-11-13T13:28:19.954Z",
    "kind": "Event",
    "stageTimestamp": "2024-11-13T13:28:19.953446Z",
    "requestReceivedTimestamp": "2024-11-13T13:28:19.948513Z",
    "responseStatus": {
      "code": 200,
      "metadata": {}
    },
    "auditID": "08b10265-1ec7-4de2-8376-abec7701ae98",
    "userAgent": "sh-backend-api/v0.0.0 (linux/amd64) kubernetes/$Format",
    "stage": "ResponseComplete",
    "objectRef": {
      "resource": "secrets",
      "apiVersion": "v1",
      "name": "sh.helm.release.v1.shturval-cert-manager.v1",
      "namespace": "cert-manager"
    },
    "requestURI": "/api/v1/namespaces/cert-manager/secrets/sh.helm.release.v1.shturval-cert-manager.v1?timeout=1m0s",
    "sourceIPs": [
      "10.XX.XXX.214"
    ],
    "apiVersion": "audit.k8s.io/v1",
    "verb": "get",
    "username": "shturval:a.kirichenko"
    },
    "level": "Metadata"
  },
  "fields": {
    "requestReceivedTimestamp": [
      "2024-11-13T13:28:19.948Z"
    ],
    "stageTimestamp": [
      "2024-11-13T13:28:19.953Z"
    ],
    "@timestamp": [
      "2024-11-13T13:28:19.954Z"
    ]
} 

Согласно записи лога мы видим, что пользователь (username) a.kirichenko запросил (verb) просмотр (get) секрета (objectRef.resource) в неймспейсе (objectRef.namespace) cert-manager. Код ответа (responseStatus) 200, значит пользователь получил данные успешно. Запрос обработан в 13:28 13 ноября 2024 года (@timestamp).

Каждая запись лога имеет идентификатор события, указывает на стадию обработки запроса в системе, содержит сведения о пути, по которому был запрошен объект (requestURI), и уровень лога (request). Также она передает информацию о пользователе (user) и его действиях (verb), времени осуществления запроса и его результате.

Структура Audit Policy

Структура лога обусловлена правилами политики аудита, которые записываются в одном файле. Каждое из них описывает:

• К чему мы смотрим запрос?

• В какой API-группе смотрим ресурс?

• Какой набор ресурсов рассматриваем?

• Есть ли какие-то ограничения?

Сама политика представляет собой YAML-манифест и входит в группу так называемых неопубликованных API K8s наряду с kubeconfig (v1), ImagePolicy API и другими ресурсами.

Если политика не содержит правил, то Kube-API-сервер будет считать ее невалидной, и она не будет смонтирована:

E0427 11:18:56.916457 1 run.go:74] "command failed" err="loading audit policy file:
loaded illegalpolicy with 0 rules: from file /etc/kubernetes/audit_policy.yaml"

Ошибки валидации YAML приведут к остановке API-сервера.

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

• Request Received. Это начальная стадия процесса аудита, как только получен запрос. На ней лог записывает информацию, например, об источнике и времени. Система еще не знает о результатах выполнения запроса.

• Response Started. Предназначена для длительных запросов (watch), когда хэдеры уже отправлены, а тело ответа еще нет.

• Response Complete. Начинается, когда тело ответа отправлено полностью. Может быть полезна при использовании мутационных Webhook.

• Panic. Становится актуальной, когда Kube-Audit сталкивается с неожиданной ошибкой, которая вызывает его аварийное завершение. В этом случае он создает лог паники с деталями ошибки. Например, это может произойти, если в ходе аудита Kube-Audit обнаруживает, что он не имеет соответствующих разрешений для выполнения задачи в Kubernetes или не может подключиться к API-серверу Kubernetes.

Стадия «Паника» не является типичной для выполнения работы и обычно указывает на серьезные проблемы. Чтобы устранить их, следует обратиться к содержанию записи в логе. Сам Kube-Audit также может предложить возможные шаги для устранения проблемы.

Хотя эти стадии обычно проходят последовательно, в случае сбоя часть из них может быть пропущена. Например, если происходит аварийное завершение на Response Started, то стадия Response Complete может быть пропущена, так как процесс переходит непосредственно к стадии Panic. Для выбора стадии нужно указать, какие этапы требуется пропустить с помощью параметра omitStages.

Конфигурация правил разбивается по API-группам и включает в себя:

• Группу — API-группа, в которую входит ресурс, запросы к которому требуется аудировать;

• Level — уровень записи данных:

  → None — значение по умолчанию. Зачем указывать в явном виде, если можно просто не записывать такое правило? Чтобы сделать исключительный фильтр из общего правила;

  → Metadata — запись основной информации: user, verb, resource, в каком скоупе, какой результат (без тела запроса). Обратите внимание на такой уровень: он может быть особенно полезным, если в логе раскрыта чувствительная информация;

  → Request — то же, что и Metadata + тело запроса. Может быть полезно в случае запросов на создание и изменение ресурса;

  → RequestResponse — полная фиксация, включающая тела запроса и ответа.

• users;

• userGroups;

• namespaces;

• verbs (create, update, patch, delete, watch, get);

• nonResourceURLs (/metrics, /healthz*);

• resources.

Указание значений является фильтром. Если вы не укажете глаголы, то будут логироваться все действия, связанные с ресурсами. Аналогично — если не указать ресурсы, то будут логироваться вызовы ко всем ресурсам, входящим в API-группу.

Также имеет значение очередность записи данных в политике. Например, если вы сначала укажете, что все обращения к секретам должны быть записаны, а затем уточните, что для некоторых сервис-аккаунтов это неактуально, то последнее правило не будет учитываться.

Кроме того, по умолчанию Kubernetes добавляет системные поля в managed fields, из-за которых объем лога разрастается. Эту проблему можно нивелировать с помощью фильтра при сборе данных или параметра omitManagedFields: true.

Пример политики

Развернуть пример политики

apiVersion: audit.k8s.io/v1 # This is required.
kind: Policy
# Don't generate audit events for all requests in RequestReceived stage.
omitStages:
  - "RequestReceived"
rules:
  # Log pod changes at RequestResponse level
  - level: RequestResponse
    resources:
    - group: ""
      # Resource "pods" doesn't match requests to any subresource of pods,
      # which is consistent with the RBAC policy.
      resources: ["pods"]
  # Log "pods/log", "pods/status" at Metadata level
  - level: Metadata
    resources:
    - group: ""
      resources: ["pods/log", "pods/status"]

  # Don't log requests to a configmap called "controller-leader"
  - level: None
    resources:
    - group: ""
      resources: ["configmaps"]
      resourceNames: ["controller-leader"]

  # Don't log watch requests by the "system:kube-proxy" on endpoints or services
  - level: None
    users: ["system:kube-proxy"]
    verbs: ["watch"]
    resources:
    - group: "" # core API group
      resources: ["endpoints", "services"]

  # Don't log authenticated requests to certain non-resource URL paths.
  - level: None
    userGroups: ["system:authenticated"]
    nonResourceURLs:
    - "/api*" # Wildcard matching.
    - "/version"

  # Log the request body of configmap changes in kube-system.
  - level: Request
    resources:
    - group: "" # core API group
      resources: ["configmaps"]
    # This rule only applies to resources in the "kube-system" namespace.
    # The empty string "" can be used to select non-namespaced resources.
    namespaces: ["kube-system"]

  # Log configmap and secret changes in all other namespaces at the Metadata level.
  - level: Metadata
    resources:
    - group: "" # core API group
      resources: ["secrets", "configmaps"]

  # Log all other resources in core and extensions at the Request level.
  - level: Request
    resources:
    - group: "" # core API group
    - group: "extensions" # Version of group should NOT be included.

  # A catch-all rule to log all other requests at the Metadata level.
  - level: Metadata
    # Long-running requests like watches that fall under this rule will not
    # generate an audit event in RequestReceived.
    omitStages:
      - "RequestReceived"

В публичной документации платформы контейнеризации «Штурвал» мы рекомендуем базовую политику аудита. Можно скачать бесплатную community-версию платформы по ссылке и посмотреть, как это работает. При установке кластера с расширенными настройками ИБ политика монтируется автоматически.

Куда разместить логи, чтобы не выстрелить в ногу

Audit-логи не пишутся по умолчанию. Для включения этой опции необходимо разместить манифест политики на всех Master-узлах вашего кластера, а также указать, куда должны быть записаны логи. Вы можете разместить только одну политику в одном кластере.

Хранить и записывать логи можно внутри кластера. Второй предлагаемый разработчиками Kubernetes вариант — отправка логов во внешнюю систему, включающая настройку Webhook. Эти параметры конфигурируются в манифесте Kube-API-сервера.

Давайте рассмотрим все подходы, а затем сравним преимущества и недостатки.

Для тонкой настройки записи или перенаправления логов в Kube-API на сервере есть 34 флага. Значение и необходимость настройки каждого флага нужно рассматривать индивидуально.

Webhook backend

Настройка отправки логов с помощью Webhook доступна в официальной документации K8s. Я с таким подходом не работала, так как он может быть использован только в случае необходимости отправки логов без записи во внутреннее хранилище. Отправка данных происходит по HTTP.

Для отправки необходимо иметь доступный HTTP-сервер (например, в одном из контейнеров кластера) и конфигурацию для Webhook. При этом Webhook может быть написан на любом языке программирования, который поддерживает HTTP. Указание на адрес HTTP-сервера необходимо прописать непосредственно в политику.

Плюсы: освобождается место в локальном хранилище, а etcd не конкурирует за возможность запросов на запись.

Минусы: повышается риск потери данных из-за недоступности сервиса, который их принимает, и увеличивается нагрузка на API-­сервер. Кроме того, при изменении нагрузки внутри кластера и увеличении количества логов требуется регулярная донастройка параметров*, чтобы логи не терялись при превышении значения буфера.

*Что необходимо для донастройки параметров

Log backend

Логи записываются в локальное хранилище кластера. Есть возможность настроить параметры записи и ротации журнала лога.

Плюсы: данные не теряются из-за переполнения буфера или недоступности внешнего сервиса, а запись и доступ к ним реализуется в моменте.

Минусы: данные записываются на постоянный том (hostpath) в локальное хранилище на Master-узлах, а объем логов остается внушительным. Если использовать только в таком виде, то данные будут доступны очень непродолжительный период времени.

Так как логи пишутся и хранятся распределенно на разных узлах, то в случае недоступности узла или отсутствия доступа к PV данные могут быть утеряны.

Альтернативный подход (log backend +)

Другое решение — запись данных в ФХ (log backend) с высокой частотой ротации, их сбор при помощи дополнительного сервиса и отправка во внешние сервисы (например, OpenSearch). Такой подход позволяет минимизировать возможность сбоя доступа к логам благодаря одновременному хранению данных в двух местах, а также снизить нагрузку на локальное хранилище и API-сервер.

Давайте рассмотрим реализацию на примере сбора логов с помощью Fluentbit Operator или Vector. Он позволяет перенаправлять логи в разные сервисы для анализа.

При единоразовой конфигурации сборщика логов мы получаем стабильную систему, включающую в себя плюсы двух подходов к записи и хранению логов. В ней можно собирать логи и события разных уровней и исследовать их в одном месте. К примеру, можно собирать kubernetes events, Kyverno events, а также другие события K8s, забирая эти данные единым сборщиком логов. Размещение сборщика логов в контуре Kubernetes также позволяет решить вопрос с масштабированием решения.

Плюсы: Получаем удобный доступ ко всем логам со всех Master-узлов. Сможем видеть лог как внутри кластера, так и во внешнем хранилище. Имеем возможность длительного хранения лога без перегрузки локального хранилища. Исключаем потерю данных при передаче через внешний API-сервер.

Минусы: Внешние сервисы, как, например, Fluentbit Operator зачастую содержат уязвимости высокого уровня критичности: CVE-2024–26461, CVE-2023–2953, CVE-2024–0567, CVE-2024–26458, CVE-2024–26461, CVE-2024–26458, CVE-2024–26461, CVE-2024–26458, CVE-2024–26461, CVE-2024–26458, CVE-2021–33560. Важно, чтобы при попытке обезопасить решение мы не принесли в контур дополнительные угрозы. Так что такой подход требует наличия хорошего безопасника в штате или готового решения вендора. Например, в платформу «Штурвал» сервисы попадают только после их очистки от подобных уязвимостей.

Сравнение подходов

Куда собирать логи

Для детального анализа логов лучше всего подходят SIEM-системы. Так как мы имеем лог в формате строки или JSON, с отправкой в SIEM нет никаких проблем. Также есть возможность настроить фильтры, сокращающие объем лога.

Однако больше внимания хочется уделить ELK, в частности OpenSearch. Он, на мой взгляд, также недооценен, как и Audit Policy, так как может стать отличным решением, и вот почему:

1. Не требует дорогостоящей системы;

2. Простой во внедрении и настройке;

3. Может быть использован как администраторами кластеров, так и сотрудниками ИБ.

В последнее время OpenSearch далеко шагнул в сторону анализа логов и теперь позволяет анализировать лог и выявлять аномалии, а также отправлять алерты при срабатывании триггера.

В разделе Notification вы можете выбрать канал получения данных (Webhook, Slack, Email и др.), а в Alerting настроить монитор, который будет отслеживать срабатывание триггера в указанном индексе и отправлять событие в нужный канал.

Кроме того, OpenSearch Operator позволяет настроить связь с кластером по SSO и пробрасывать сведения о пользователях с сохранением данных о соответствующих им ролях для защиты их чувствительной информации.

Сайзинг индекса Kube-Audit логов в OpenSearch

Допустим, мы доставили логи в OpenSearch, создали индекс kube-audit-myclustername и имеем индекс-паттерн, по которому доступны Audit-логи со всех Master-узлов кластера. Но расслабляться рано, работа еще не завершена.

В зависимости от того, как вы настроили политику, какие данные для вас принципиальны, вы получите огромный поток записей, которые необходимо хранить. Если говорить о политике, фиксирующей основные данные, связанные с узлами, нагрузками, секретами, конфигмапами, сетевыми политиками на уровне Metadata, то в живом продуктивном кластере с 350 подами за день набегает 4 ГБ логов.

Если объем памяти переполнен, то логи не будут доступны в OpenSearch. Для решения этой проблемы необходимо настроить политику ротации логов.

Чем дольше хранятся индексы, тем больше места на диске они занимают. Если у вас уже есть существующие индексы, к которым вы хотите применить политику, перейдите в Index Management. Политика будет автоматически применяться к новым создаваемым индексам.

Особенности

Запись данных сервис-аккаунтов

Все записи логов можно условно поделить на три части по актору:

• выполнено пользователем;

• выполнено сервис-аккаунтом;

• не определено (anonymous).

Записи с неопределенным актором мы можем получить, если кто-то неавторизованный смог отправить запрос к ресурсу, а также если выполняется healthcheck API-сервера самим кубом.

С действиями пользователей вроде как тоже все прозаично. Однако львиная доля записей в Kube-Audit логах приходится на сервис-аккаунты. Нужно решить, что важнее — объем данных или безопасность. При этом политика не позволяет отфильтровать все записи сервис-аккаунтов по группе, так как помимо группы service-accounts мы имеем еще и группу system: authenticated. Здесь возможно несколько путей развития:

1. Не исключать записи сервис-аккаунтов. Механизмы OpenSearch, SIEM и многие другие сервисы позволяют определить ожидаемое поведение действий для каждого сервис-аккаунта и отлавливать аномалии, что может помочь если не в предотвращении, то хотя бы в оперативном реагировании на инциденты безопасности;

2. Реализовать контроллер, который будет отлавливать создаваемые сервис-аккаунты и добавлять их в Audit Policy по заданному расписанию, например раз в сутки. Здесь нужно не забыть про риски потерянных данных, а также необходимость ребута Kube-API-сервера;

3. Не логировать запросы от сервис-аккаунтов системных сервисов, которые инсталлируются вместе с клиентским кластером, но записывать обращения всех кастомных сервис-аккаунтов.

Размещение и внесение изменений

• Audit Policy не прощает ошибок. Например, если вы копируете конфигурацию с NotePad++, в которой все казалось идеальным, в манифест могут пробраться пробелы, превращенные в табуляцию, что приведет к падению Kube-API-сервера.

• Размещение политики требует перезапуска Kube-API-сервера.

Перезапуск может быть произведен при изменении параметров Kube-API-сервера или же автоматически с помощью контроллера, который отслеживает наличие изменений, валидирует манифест политики и перезагружает Kube-API-сервер. Подробнее о решении, которое позволяет размещать и поддерживать консистентность политики на Master-узлах, можно прочитать в статье моего коллеги.

Фиксация модификаций объектов

Если у вас в кластере есть сервисы, позволяющие модифицировать объекты перед запуском, то сведения о наличии модификации могут быть записаны в лог. Например, Mutation Webhook от Kyberno будет записан в качестве аннотации:

annotations.mutation.webhook.admission.k8s.io/round_0_index_3
{"configuration":"kyverno-verify-mutating-webhook-cfg","webhook":"monitor-
webhooks.kyverno.svc","mutated":true}

Данные могут быть потеряны при перенаправлении

Некоторые кубовые системные поля (вложенные объекты) ломают записи при перенаправлении в OpenSearch. Небольшая кастомизация в виде фильтров сборщика логов позволяет отсекать эти поля перед отправкой, что позволит получать все данные.

Node/proxy не логируются

Прямой запрос, выполненный на узел, не будет записан в Audit-логи. Это приведет к получению вредоносных событий, о которых никто не узнает. Чтобы минимизировать риски запросов node/proxy от неизвестных пользователей, рекомендую:

• настроить строгие политики ролевого доступа (ClusterRoles), а также политику определения доступов пользователей (например, OPA), позволяющую минимизировать количество пользователей с правами к node/proxy;

• изолировать на сетевом уровне кластеры, чтобы ограничить возможность подключения к узлу напрямую;

• использовать в кластере сертификат, например ACME или Vault, для минимизации риска получения доступа к данным.

Аутентификация пользователя не логируется

В Audit-логи не может попасть аутентификация пользователя, так как она происходит за пределами кластера. Однако это можно решить с помощью логирования сервиса аутентификации. Еще можно собирать и отображать логи сервиса аутентификации в OpenSearch, что повышает прозрачность действий пользователей внутри системы.

Достоверность информации

Логи можно подделать (поля SourceIP и auditID), если в запросы добавлять заголовки — например, X-Forwarded-For и X-Real-IP. Если злоумышленник знает, что в кластере собираются логи, но в то же время хочет оставаться незамеченным, ко всем его запросам к Kube-API достаточно добавить эти заголовки, чтобы мимикрировать под реальные сервисы.

Пример запроса, в котором можно задать искусственный AuditID:

curl -H 'Audit-ID: Lorem' http://127.0.0.1:8001/api/v1/pods/

В таком случае запись искусственного лога будет иметь вид:

{"kind":"Event","apiVersion":"audit.k8s.io/v1","level":"Metadata","auditID":"Lorem",
"stage":"RequestReceived","requestURI":"/api/v1/pods/","verb":"list","user":
{"username":"kubernetes-admin","groups":["system:masters","system:authenticated"]},
"sourceIPs":["127.0.0.1","172.18.0.1"],"userAgent":"curl/7.81.0","objectRef":
{"resource":"pods","apiVersion":"v1"},"requestReceivedTimestamp":
"2023-10-01T09:25:13.742237Z","stageTimestamp":"2023-10-01T09:25:13.742237Z"}

Также в команду можно добавить заголовок, содержащий данные IP:

curl -H 'Audit-ID: Lorem' -H 'X-Forwarded-For: 8.8.8.8' http://127.0.0.1:8001/api/v1/pods/

И это также попадает в лог:

{"kind":"Event","apiVersion":"audit.k8s.io/v1","level":"Metadata","auditID":"Lorem",
"stage":"ResponseComplete","requestURI":"/api/v1/pods/","verb":"list","user":
{"username":"kubernetes-admin","groups":["system:masters","system:authenticated"]},
"sourceIPs":["8.8.8.8","127.0.0.1","172.18.0.1"],"userAgent":"curl/7.81.0","objectRef":
{"resource":"pods","apiVersion":"v1"},"responseStatus":{"metadata":{},"code":200},
"requestReceivedTimestamp":"2023-10-01T09:28:15.307641Z","stageTimestamp":
"2023-10-01T09:28:15.313353Z","annotations":{"authorization.k8s.io/decision":
"allow","authorization.k8s.io/reason":""}}

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

Подведем итоги

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

Резюмируя, использование Kube-Audit-логов обеспечивает:

• регистрацию вызовов с успешным и неуспешным результатом на нужном уровне детализации, а также возможность детального прописывания правил;

• конфигурацию с помощью YAML-манифеста;

• обработку логов в любых системах с помощью формата JSON;

• полезность для широкого профиля специалистов, включая безопасников, разработчиков и аналитиков.

Алиса Кириченко

Заместитель владельца платформы «Штурвал»

© Habrahabr.ru