Анализ событий кластера с InfraSight

Всем привет!

InfraSight – observability платформа, которая использует eBPF для «захвата» низкоуровневых системных событий с целью последующего анализа.

Состоит она из 4-х элементов:
🍭 Controller. Управляет eBPF-агентами в кластере
🍭 Agent. Анализирует события с использованием eBPF-программ
🍭 Server. Обрабатывает данные, полученные от Agent для последующего сохранения в базе данных
🍭 ClickHouse. Высокопроизводительная база данных, в которой хранятся события, полученные от InfraSight

На текущий момент решение позволяет отслеживать следующие системные вызовы: execve, open, chmod, connect и accept.

Больше информации – архитектура, способы установки, настройка, схема БД и т.д. – можно найти в документации на проект.

Кстати, там же есть небольшое видео, в котором описан процесс работы с InfraSight и результаты, которые можно получить.

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

The Kubernetes Networking Guide

Всем привет!

Если не знаете, что почитать на выходных, то рекомендуем обратить внимание на Kubernetes Networking Guide.

На этом ресурсе собрано очень много информации о том, как устроено сетевое взаимодействие в кластере.

На сайте можно найти информацию о:
🍭 Network Model
🍭 CNI
🍭 Services
🍭 Ingress & Egress
🍭 Network Policies
🍭 DNS и не только

Многие разделы содержат подразделы. Так, например, в блоке про CNI есть дополнительная информация о Flannel, Weave, Calico, Cilium.

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

То, что надо, чтобы лучше понять устройство сети в Kubernetes и как с ней работать!

P.S. Некоторые разделы все еще находятся «Under Construction». Если вы хотите чем-либо дополнить материал, то можно сделать PR вот в этот repo.

Dependency Management Report

Всем привет!

В приложении можно скачать отчет (~ 46 страниц), подготовленный Endor Labs и посвященный вопросу управления зависимостями и их уязвимостями.

Отчет содержит несколько частей:
🍭 Identifying Dependencies & Their Vulnerabilities. Раздел содержит сведения о нюансах, связанных с корректным определением зависимостей: достижимость, «фантомные зависимости» и т.д.
🍭 Discrepancies and Shortcomings of Vulnerability Databases. «Тонкости работы» с базами данных об уязвимостях и почему использование только NVD далеко не всегда является достаточным
🍭 Why Remediating Known Vulnerabilities Is Hard. Почему нельзя «просто взять и обновить зависимости»
🍭 Software Composition Analysis and its role in dependency management. Рассуждения о функционале SCA-решений, который может помочь в решении описанных в отчете проблем

Для каждого раздела приводятся примеры, статистика, ссылки на полезные материалы по теме.

Отчет приятно читать, он содержателен и в нем практически нет маркетинга и «воды»

OWASP: Business Logic Abuse

Всем привет!

Еще один Top 10 от OWASP, на этот раз посвященный вопросам бизнес-логики: OWASP Top 10 for Business Logic Abuse (кстати, получилось довольно забавное сокращение – BLA 😊)

Он включает в себя:
🍭 Lifecycle & Orphaned Transitions Flaws
🍭 Logic Bomb, Loops and Halting Issues
🍭 Data Type Smuggling
🍭 Sequential State Bypass
🍭 Data Oracle Exposure и не только

Как обычно, описание и примеры доступны на сайте OWASP.

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

Kubewall: интерактивный UI для Kubernetes

Всем привет!

Kubewall – еще один проект, цель которого – упростить взаимодействие пользователя с кластерами Kubernetes за счет предоставления графического интерфейса.

Он позволяет:
🍭 Централизованно работать с множеством кластеров
🍭 Просматривать ресурсы, созданные в кластере (конфигурация, события, логи)
🍭 Редактировать ресурсы за счет встроенного YAML-editor
🍭 Получать информацию об изменениях в кластере в режиме реального времени и не только
Устанавливается просто, не требует значительной конфигурации и практически сразу «готов к работе».

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

P.S. Конечно же, главный функционал в наличии! Можно менять темы на «светлую/темную» ☺️

Что такое CNI и как он работает

Всем привет!

Организация сетевого взаимодействия одна из самых важнейших задач. В настоящее время трудно представить системы, которые бы не «общались между собой».

В Kubernetes за это отвечает CNI – Container Network Interface – и его реализации (plugin’ы). О том, как это работает можно прочитать в статье.

В ней Автор описывает:
🍭 Из каких «компонентов» состоит CNI plugin, какие его основные задачи
🍭 Как pod «подключается» к сети
🍭 Логика работы CNI plugin’a «под капотом» (создание Virtual Ethernet Pair, назначение IP pod и т.д.)
🍭 Обеспечение сетевой связности между узлами кластера и не только

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

В завершении статьи есть ссылка на GitHub Repo, в котором представлен минималистичный CNI plugin для того, чтобы можно было изучить вопрос более детально.

Отличная статья, которая дает общее понимание того, что из себя представляет CNI и как он работает «изнутри».

Kube Composer

Всем привет!

Нет, это не то, о чем вы подумали! ☺️ Это не утилита, которая превращает compose-файлы в Kubernetes-манифесты.

Kube Composer – это интуитивно понятный YAML-генератор ресурсов кластера, которые вы хотите создать.

Представляет он из себя небольшое web-приложение, которое можно развернуть «у себя», так и воспользоваться playground’ом.

Он позволяет:
🍭 Описывать требуемые ресурсы и их параметры непосредственно в UI
🍭 Работает с Deployments, Services, Volumes, Ingress и не только
🍭 Наглядно показывает связность между разными Kubernetes
🍭 И, конечно же, генерирует YAML-файлы, которые потребуются для создания ресурсов

Не зря говорят, что лучше один раз увидеть, чем сто раз услышать. Поэтому предлагаем вам посмотреть на его возможности воочию.

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

P.S. А еще там можно посмотреть специально подготовленное demo

Как работают Validating Admission Policy?

Всем привет!

Еще одна статья, в которой описывается «как оно работает под капотом?». На этот раз речь пойдет про Validating Admission Policy и их реализацию в Kubernetes.

Вкратце этот механизм позволяет анализировать создаваемые в кластере ресурсы на соответствие предъявленным требованиям.

После небольшой вводной Автор переходит к описанию того, что это такое из чего оно состоит в Kubernetes. Рассматривается «собственный механизм», а не сторонние (Kyverno, Gatekeeper и т.д.).

В статье рассказано о:
🍭 API Definition. Из каких API состоит Validating Admission Policy
🍭 Controller Reconciliation. Из чего она состоит, какие задачи выполняются
🍭 Resource Admission. Как осуществляется проверка создаваемых в кластере ресурсов
🍭 Expression Cost Analysis. Контроль того, что Kubernetes API Server’у не станет «плохо» от проверок

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

Завершает статью немного примеров анализа манифестов и как можно реализовать мониторинг Validating Admission Policy с использованием Prometheus.

Управление доступом: SSH ключи или сертификаты?

Всем привет!

Управление доступом через SSH ключи повсеместно используется. Генерируем ключевую пару, помещаем открытый ключ на рабочую станцию и все работает.

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

А что, если попробовать использовать не SSH ключи, но SSH-сертификаты? В теории это может решить проблемы, описанные выше. Именно этому посвящена статья.

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

Больше деталей о том, как это работает и что именно предлагает Автор можно найти в статье.

В этом сценарии получаем централизованное решение, которое позволит точечно управлять доступом и не беспокоиться о том, что «что-то забыли удалить».

А что вы думаете? Имеет ли такой механизм место быть или лучше использовать «привычные» подходы?

Обновление Jet Container Security Framework (JCSF)

Всем привет!

Свершилось долгожданное: мы учли пожелания всех заинтересованных и обновили JCSF!

Основные изменения:
🦴 Появился маппинг JCSF на CIS Benchmark for Docker
🦴 Появился маппинг JCSF на CIS Benchmark for Kubernetes
🦴 Появился маппинг JCSF на 118 Приказ ФСТЭК России
🦴 Актуализированы (дополнены, изменен текст) некоторые практики JCSF, а также частично перемещены в другие домены
🦴 Появился домен по безопасности Docker и Docker Swarm
🦴 Улучшилось визуальное оформление, исправлены опечатки и ошибки, добавлены новые

Качайте, анализируйте документ и вашу контейнерную инфраструктуру!
Присоединяйтесь к совершенствованию JCSF и становитесь контрибьютором (мы открыты к любым предложениям и отзывам)!

Kingfisher: анализ секретов от…

Всем привет!

… MongoDB! Да, все так! История о том, как pet-проект превратился в один из основных компонентов анализа наработок компании.

Автор использовал разные open source сканеры для поиска секретов. И во всех из них его «что-то не устраивало»: скорость анализа, количество false positive, ограниченная возможность настройки и т.д.

Решение очевидно – сделать свое! Так и родился Kingfisher.

Из ключевых особенностей можно отметить:
🍭 Высокая скорость работы
🍭 Анализ Git Repo (Remote/Local), истории commit’ов, файловых систем
🍭 Функциональность валидации секретов (например, через отправку API запросов)
🍭Локальная установка и использование, данные «никуда не передаются»
🍭 «Внутри» используются разные типы анализа: pattern matching, энтропия, поддержка некоторых языков программирования для обогащения/уточнения результатов

Больше информации об утилите можно найти в статье. Там также присутствует статистика по скорости работы Kingfisher в сравнении с Trufflehog и GitLeaks.

А если вам ближе подход «зачем читать, если можно позапускать», то repo проекта можно найти тут.

Может ли LLM генерировать безопасный код?

Всем привет!

Этот вопрос можно часто встретить на просторах сети. Многие считают, что «нет» и за LLM надо следить и направлять в нужное русло.

Но что делать, когда хочется некоторой статистики, примеров, аналитики? В этом случае рекомендуем обратить внимание на BaxBench!

Benchmark, в котором авторы исследуют рассматриваемый вопрос. Авторы выбрали 392 задачи, которые описывают 28 сценариев с использованием 14 популярных фреймворков на 6 языках программирования. Далее они «попросили» LLM выполнить эти «задания» и проанализировали результаты.

Получилось следующее:
🍭 62% решений были либо некорректны, либо содержали уязвимости
🍭 Примерно 50% корректных решений не были безопасны
🍭 Получить «работающий и безопасный» вариант оказалось не так просто и требовало дополнительных усилий

Результаты от ChatGPT, DeepSeek, Qwen, Grok и не только представлены на сайте.

Для самостоятельного повтора эксперимента можно воспользоваться наработками из repo.

И, что самое приятное, Авторы выложили dataset, который использовался при тестировании, чтобы вы могли попробовать его на своих моделях.

А что вы думаете по этому поводу? Насколько LLM хороши в написании безопасного кода исходя из вашего опыта?

Создание Kubernetes Audit Log Policy

Всем привет!

Kubernetes предоставляет достаточно сильный инструмент для сбора событий, описывающих происходящее в кластере – Audit Policy.

По умолчанию она «отключена»: ее сперва надо написать и настроить несколько параметров для kube-apiserver.

Нюанс состоит в том, что сперва может быть не очень понятно, а что надо записывать? Ответу на этот вопрос и посвящена статья.

В ней Автор описывает Audit Policy, которая больше всего ему подходит. Начинается все с основ – из чего она состоит, почему не надо «журналировать все», как можно записать конкретное действие и т.д.

После чего Автор приводит политику, которая (по его мнению) является оптимальной и описывает почему это так.

Кроме этого в статье приводятся Audit Policy от Amazon и Google (но они будут генерировать много событий, к этому надо быть готовым) на случай, если политика Автора вам не нравится и нужно что-то еще.

"Всё не так и всё не то" - хочу создать свою! Тогда, для ускорения процесса, можно воспользоваться «помощником»: Генератором политик аудита, разработанного командой Штурвала, о котором мы писали тут.

А для вдохновения использовать множество наработок от команды Luntry, посвященных вопросам журналирования Kubernetes и не только.