Обзор Luntry. Платформа для обнаружения аномалий в реальном времени для Kubernetes + разбор 5 кейсов использования

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

Luntry относится к классу Observability решений. Под Observability подразумевается показатель того, насколько эффективно можно определить внутреннее состояние системы по ее выходным данным. 

Основная цель Luntry заключается в повышении видимости происходящего в приложениях, запущенных в кластере Kubernetes. Благодаря предоставляемой информации появляется возможность отслеживать бесперебойную работу своих сервисов и управлять их безопасностью, не замедляя производственный цикл.

С технической точки зрения, Luntry представляет собой набор контейнеров, оформленных в Kubernetes-ресурсы. Решение представляет из себя систему сенсоров, поставляемых в виде DaemonSet, которые работают на нодах кластера, собирают информацию и передают ее на бэкенд.

Сенсор не может навредить системе — Luntry является read-only системой. Это означает, что платформа не записывает, не создает и не вносит какие-либо изменения в конфигурацию кластера. Благодаря технологии eBPF платформа способна быстро и без вреда для системы снимать системные вызовы с нод и использовать их для обучения и формирования модели поведения внутри контейнера.

Установка Luntry

Установить Luntry можно несколькими способами:

1. При помощи helm репозитория;

2. Установить локально. Данный способ используется в случае, если невозможно использовать удаленный helm репозиторий.

В официальной документации описан каждый способ установки с необходимыми параметрами. Далее будет рассмотрен способ установки при помощи helm репозитория и использования внутренней СУБД PostgreSQL. Если установка планируется на production среду, то необходимо использовать внешнюю СУБД. 

Для начала необходимо подключить helm репозиторий. Команда для подключения репозитория Luntry выглядит следующим образом:

helm repo add luntry --username %USER% --password @PASSWORD@
https://registry.luntry.com/chartrepo/luntry/

%USER% — пользователь для доступа к репозиторию. 
%PASSWORD% — пароль пользователя для доступа к репозиторию.

Пользователь и пароль от репозитория предоставляет вендор.

После того как репозиторий будет подключен можно приступать к установке Luntry. Для этого используется следующая команда:

helm install luntry luntry/luntry -n luntry-new --create-namespace \
    --set database.enabled=true \
    --set admin.user="luntry" \
    --set admin.password="luntry_pass"

-n luntry-new – luntry будет установлен в namespace с названием luntry-new.

--set database.enabled – данный параметр со значением true означает что будет использоваться внутренняя СУБД.

--set admin.user="luntry" – данный параметр задает имя пользователя, которое будет использоваться для входа в веб-интерфейс. В данном случае имя пользователя будет задано как luntry.

--set admin.password="luntry_pass" – данный параметр задает пароль пользователю, который будет использоваться для входа в веб-интерфейс. В данном случае имя пользователя будет задано как luntry.

После того как у всех компонентов системы появится статус ready (в среднем данная процедура занимает от 2-3 минут до 7 минут) можно перейти в веб-интерфейс Luntry. 

Отслеживать статус подов можно при помощи команды:

kubectl get po -n luntry-new

Для доступа к веб-интерфейсу необходимо получить IP-адрес компонента luntry-visualizer (компонент веб-интерфейса) при помощи команды:

kubectl get svc luntry-visualizer -n luntry-new

Далее перейти по адресу и порту, указанному в выводе. В данном случае веб-интерфейс luntry расположен по адресу 10.107.214.110 и слушает порт 32235.

При первом входе отобразится главная страница с аутентификацией. Логин и пароль от веб-интерфейса необходимо использовать те, которые были заданы в момент установки при помощи helm чарта (параметры set admin.user и set admin.password):

Обзор программы

Luntry позволяет работать с системой в следующих режимах: 

Cluster Mode — работа с системой на уровне кластера; 
Microservice Mode — работа с системой на уровне микросервисов.

При входе в программу открывается главный раздел – Dashboard, который отображает основную информацию о кластере, а также информацию о политиках кластера и аномалиях (подробнее о том, что такое аномалия будет описано далее). В разделе System отображается количество кластеров, нод, установленных сенсоров, количество namespace, workloads и количество образов. 

Далее рассмотрим основные разделы Luntry:

• Policies

• Anomalies

• Infrastructure

• Kubernetes Map

• Kubernetes network

• Runtime Policy

• Anomalies

• RBAC

Policies отображает количество политик, которые в данный момент проходят обучение, количество активных, неактивных и архивированных политик.

Anomalies отображает матрицу аномалий. 

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

Аномалия — это действие, которое контейнер на совершал во время обучения\валидации политики. 

Матрица аномалий показывает количество аномалий каждого типа:

Process — аномалии, связанные с процессами; 
File — аномалии, связанные с файловыми операциями; 
Network — аномалии, связанные с сетевым взаимодействием.

Infrastructure отображает более подробную информацию о кластере Kubernetes и нодах кластера:

Kubernetes Map отображает сетевое взаимодействие между Workloads компонентами.

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

• All — все типы связей;

• Internet — связи с сущностями в сети Internet;

• Aliases — связи с сущностями, заданными в системе администратором;

• Namespaces — связи с сущностями из других namespaces, не выбранных в фильтре;

• Localhost — взаимодействие по localhost;

Kubernetes network отображает сетевое взаимодействие между различными компонентами кластера. 

Каждый компонент оформлен соответствующим образом. Прямоугольные блоки — это Namespaces. Каждый узел — это определённый Kubernetes ресурс со своей соответствующей иконкой. При этом показывается родитель Pod’ов, а не они сами (Pods может быть 10-100). 

Связи между узлами — это либо фактическое хождение трафика (сплошная линия), либо логическая связь между ресурсами (пунктирная линия).

Runtime Policy отображает список политик для образов контейнеров в соответствующих Kubernetes ресурсах с учетом их разновидности.

Anomalies отображает список аномалий, обнаруженных в кластере.

Если открыть аномалию, то отобразится вся подробная информация о выбранной аномалии, включая ее график, на котором отображаются действия, выполненные на хосте (набор команд), а также дата и время выполнения действий, которые привели к созданию аномалии:

В разделе RBAC (расшифровывается как Role-based access control и представляет собой систему распределения прав доступа к различным объектам в кластере Kubernetes) происходит работа с субъектами (Service Accounts, Users, Groups), правами и ролями RBAC.

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

Переключатель Only Used Images позволяет отображать в списке только активные образы (образы, которые сейчас используются тем или иным контейнером).

5 реальных кейсов использования Luntry в production среде

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

Сценарий 1. Runtime security – проверка аномалий и работы с runtime политиками

1. Обучить политику для микросервиса;

1.1 Для обучения политики необходимо перейти в раздел Policies далее выбрать политику из списка.

1.2 В столбце Actions нажать на кнопку Activate. По умолчанию политика обучается в течение 300 секунд. В течение этого времени политика «запоминает» текущее состояние кластера или его компонента, далее при возникновении подозрительного действия (которого не было при обучении политики) появляется аномалия.

2. Зайти на данный микросервис при помощи kubectl exec (для создания интерактивной оболочки);

3. Должна быть создана аномалия для данной политики. В зависимости от настроек и действий: процессные, файловые или сетевые.

4. Эти аномалии можно отметить как incident или как improve anomaly. Во втором случае они добавятся в политику и больше возникать не будут.

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

Пример реализации

Перейти в веб-интерфейс luntry, далее выбрать раздел Policies. Выбрать нужный namespace. Отобразятся политики. Справа нажать на кнопку Start training. Остановить политику. Перейти на хост и «провалиться» внутрь необходимого контейнера при помощи команды:

kubectl exec -it <имя_пода> <любая_команда> -n имя_namespace

После выполнения каких-либо действий внутри контейнера, вернутся в веб-интерфейс и перейти в раздел Anomalies. Выбрать необходимый namespace. Отобразятся отчеты. Перейти в нужный. Внутри будет полное описание действий и схема.

Сценарий 2. Network security – генерация ресурсов NetworkPolicy и влияние на микросервисы

1. В окне NetworkMap в фильтрах выбрать какой-нибудь namespace.

2. Можно обратиться к какому-нибудь сервису на его открытый порт через: kubectl exec <pod-name-1> curl ip:port – убедится, что сетевой коннект возможен.

3. Нажать на иконку “+” в верхнем правом углу namespace и в диалоговом окне выбрать, для кого хотим сгенерировать NetworkPolicy.

4. Генерируем, скачиваем и применяем NetworkPolicy ресурсы в Kubernetes.

5. С помощью kubectl exec <pod-name-1> curl ip:port убеждаемся, что данный коннект продолжает работать верно.

6. С помощью kubectl exec <pod-name-2> curl ip:port обращаемся к каком-нибудь другому Pod в другом namespace, куда ранее обращений не было. 

7. В итоге должна быть создана аномалия и также соединение не должно быть установлено благодаря NetworkPolicy.

Стоит отметить важную особенность: несмотря на то, что Luntry позиционирует себя как read-only систему (система, которая не вносит каких-либо изменений в кластер Kubernetes) данное правило не распространяется на функциональность, связанную с сетевыми политиками, так как присутствует возможность ограничивать сетевое соединение между объектами в кластере Kubernetes.

Пример реализации

1. Заходим через kubetcl exec в под visualizer, добавляем пакет curl при помощи команды apk add curl, проверяем, что можем установить связь с подом data-provider curl data-provider.luntry:80, коннект проходит.

2. Генерируем сетевую политику из интерфейса luntry и применяем ее. 

3. Заходим в под visualizer через kubectl exec, проверяем, что коннект до пода data-provider все еще доступен curl data-provider.luntry:80

4. Проверяем, что мы не можем подключится к другим подам, например, curl postgres.luntry:5432 

5. Проверяем, что не можем подключиться к интернету curl google.com:443

6. Удаляем сетевую политику, снова делаем проверки из пункта 4 – коннекты проходят.

Сценарий 3. RBAC – контроль прав пользователей и ролей

1. В окне RBAC на вкладке Permissions необходимо выбрать интересующее разрешение.

2. Выбрать API Group, которой принадлежит интересующий Kubernetes ресурс. Например, Core API.

3. Выбрать Resource, который интересует. Например, pods/exec.

4. Выбирать Verbs, которое должен иметь пользователем над выбранным ранее Kubernetes ресурсом. Например, create.

5. Выбрать, в каком namespace. Например, возьмем ALL.

6. На появившемся графе отобразятся все роли и субъекты, соответствующие выбранным критериям. В нашем примере, это будут все, кто могут выполнять команду внутри Pods через exec. В выводе как минимум должен быть Group system:masters 

Сценарий 4. Kubernetes resource security – контроль ресурсов, используемых в Kubernetes 

Для обеспечения данного аспекта безопасности Kubernetes используются сторонние компоненты класса PolicyEngine. На текущий момент поддерживаются и интегрируются два самых популярных решения: Kyverno и OPA Gatekeeper. Если они уже стоят и используются в кластере, то делать ничего не надо. В ином случае необходимо установить один или второй (можно использовать и их два одновременно). 

Установка Kyverno: kubectl create -f https://raw.githubusercontent.com/kyverno/kyverno/main/config/release/install.yaml 

Установка OPA Gatekeeper: kubectl apply -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper/release-3.7/deploy/gatekeeper.yaml

Далее если раньше PolicyEngine не использовали, то также необходимо создать политики для них.
Политики для Kyverno можно взять отсюда https://kyverno.io/policies/ 
Политики для OPA Gatekeeper взять отсюда https://github.com/open-policy-agent/gatekeeper-library/tree/master/library 

Пример реализации

1. В окне Kubernetes Resources на вкладке Watched Resources в разделе Custom Resources выбрать API Group – https://wgpolicyk8s.io/ и там подписаться на ресурсы PolicyReport, ClusterPolicyReport. Также для API Group https://kyverno.io/ ресурсы ClusterPolicy и Policy.

2. Создадим политику “Require Labels” (https://kyverno.io/policies/best-practices/require_labels/require_labels/) , которая проверяет обязательное наличие label “ https://app.kubernetes.io/name ” у ресурсов типа Pod.

3. Создаем в нашем тестовом namespace какой-нибудь микросервис.

4. В окне Kubernetes Resources в нужном нам namespace мы должны посмотреть ресурс PolicyReport, где у одного микросервиса будет написано, что проверка прошла, а другого не прошла.

Сценарий 5. Compliance – анализ по Kubernetes benchmarks

Для обеспечения данного аспекта безопасности Kubernetes используются сторонние компоненты класса Security benchmarks. Можно проверить на CIS Kubernetes Benchmark, NSA Hardening Guide и на Best practice.
Рассмотрим сценарий на примере Starboard operator.
Первоначально его нужно установить. Установка производится следующим образом:

helm repo add aqua https://aquasecurity.github.io/helm-charts/
helm repo update
helm install starboard-operator aqua/starboard-operator -n starboard-operator --create-namespace --set="targetNamespaces=test_namespace"

Пример реализации.

1. В окне Kubernetes Resources на вкладке Watched Resources в разделе Custom Resources выбрать API Group – aquasecurity.github.io и там подписаться на ресурсы CISKubeBenchReport, ClusterComplianceReport, ConfigAuditReport, ClusterComplianceDetailReport. 

2. В окне Kubernetes Resources в фильтрах выставить Non-namespaced и выбрать Api Group aquasecurity.github.io. В рабочей зоне будут отчеты CISKubeBenchReport, ClusterComplianceReport, ClusterComplianceDetailReport. А если зайти в тестовый namespaces, то там будет еще отчет ConfigAuditReport.

Подводя итоги, можно сказать что Luntry отлично подойдет в качестве решения для обеспечения безопасности кластеров Kubernetes, а также микросервисов. Благодаря обширному набору функций, Luntry также можно использовать как систему мониторинга за кластером Kubernetes. Кроме того, одним из главных преимуществ Luntry является отечественная разработка, что важно в текущих реалиях импортозамещения.

НЛО прилетело и оставило здесь промокод для читателей нашего блога:

— 15% на все тарифы VDS (кроме тарифа Прогрев) — HABRFIRSTVDS.