Главная идея проекта: кластер нужно наблюдать через панель, а изменять — через Git, pull request и привычный CI/CD-процесс. Поэтому в Klarity нет универсального редактора ресурсов, позволяющего незаметно изменить YAML в обход GitOps.

Возможности:
— автоматически обнаруживать более 60 типов Kubernetes-ресурсов и установленные CRD;
— показывать Pods, Deployments, StatefulSets, Services, Ingress, PVC, RBAC, события и другие объекты;
— выводить CPU и память узлов, Pod и отдельных контейнеров через metrics-server;
— ранжировать основные потребители ресурсов;
— транслировать логи контейнеров через WebSocket;
— открывать веб-терминал в контейнере через kubectl exec;
— организовывать port forwarding прямо из браузера;
— искать ресурсы сразу по нескольким категориям;
— формировать HTML-отчёт о состоянии кластера.

Отдельно приятна автоматическая интеграция с Argo CD и Flux. Klarity обнаруживает их CRD и показывает состояние Applications, ApplicationSets, Kustomizations, HelmReleases и Git-репозиториев без дополнительной настройки.

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

Backend написан на Go, frontend — на React и TypeScript. Интерфейс встраивается в один исполняемый файл. Развернуть приложение можно через Helm или Kustomize.

Klarity — это скорее альтернатива Headlamp, Lens или веб-вариант k9s, а не полноценная observability-платформа. Здесь нет долговременного хранения метрик, централизованного хранилища логов и трассировки. Метрики берутся из metrics-server, логи транслируются напрямую, а журнал аудита хранится в ограниченном буфере памяти.

Примонтировать ~/.ssh в контейнер с флагом :ro — и вроде как позаботился о безопасности. Только приватный ключ при этом всё ещё можно прочитать и утащить. От этого read-only не спасает.

В этом разборе на Хабре рассказывают о том, как дать rootless-контейнеру SSH-доступ через ssh-agent, оставив сам ключ на хосте. Пригодится для автоматизации, работы с приватными репозиториями и ИИ-агентов, которым нужен Git.

Rootless Docker имеет свои нюансы: UID пользователя внутри контейнера преобразуется в другой UID на хосте, поэтому просто пробросить сокет агента недостаточно.

Оказывается, доступ к сокету всё ещё позволяет пользоваться загруженным ключом. Если контейнер взломали, злоумышленник сможет выполнять доступные этой SSH-идентичности операции, пока имеет доступ к агенту. Сам приватный ключ через штатный протокол агента при этом не выдаётся.

Он построен на BPF LSM хуках и состоит из модульных детекторов, которые отслеживают процессы, файловые и сетевые операции, а также взаимодействие с eBPF-подсистемой ядра.

Самое интересное здесь — rule engine, который целиком работает внутри eBPF в отличие от Falco, где правила вычисляются в user mode части агента. Правила пишутся в YAML с булевыми предикатами (AND/OR/NOT, in, CIDR для IPv4/IPv6, списки и макросы). Каждое правило компилируется как программа: парсер строит AST,оптимизационные проходы его упрощают, а на выходе получается байткод в обратной польской записи. Байткод загружается в eBPF-мапы и исполняется прямо в ядре собственным RPN-интерпретатором. Поэтому фильтрация происходит до отправки событий в userspace, и накладные расходы минимальны. Для правил есть sandbox-режим в вариантах allow-list и deny-list, в отличие от Tetragon, где реализован только deny-list способ.

Отдельно стоит отметить детектор SysEnumMon, аналогов нет ни в Falco, ни в Tetragon. Обычно в eBPF-агентах одно срабатывание хука даёт одно событие. SysEnumMon работает иначе: он собирает наблюдения с нескольких хуков (запуск бинарей и открытие файлов), коррелирует их внутри дерева процессов в скользящем временном окне и принимает решение прямо в eBPF. Так он ловит сканеры вроде LinPEAS и LinEnum, хотя каждое их действие по отдельности (id, uname, чтение /etc/passwd) выглядит легитимно.