Управление секретами с Kloak

Всем привет!

Самым распространенным способом управления секретами является использованием Secret Management решений. Ярким представителем которых является HashiCorp Vault.

Концепт такой что все секреты помещаются в единое надежное хранилище и выдаются на основании логики работы Vault’a.

А что если хочется чего-то иного? Например, подстановки самого значения секрета в момент установки соединения за счёт использования eBPF?

Как раз эту задачу и реализует Kloak.

Работает он примерно так:
🍭 Создаётся секрет в Kubernetes
Kloak автоматически создаёт shadow secret, в котором указывается placeholder
🍭 Настраивается взаимосвязь pod с Kloak через аннотации
🍭 Webhook мутирует pod заменяя значение оригинального секрета на shadow secret, созданный Kloak
🍭 В момент запуска pod и установки соединения указывается настоящее значение секрета, полученное из связки shadow secret – оригинальный секрет

Такая связка позволяет реализовать процесс, в котором приложение не владеет данными о том, какой именно секрет (значение) используется.

Однако сам секрет всё равно «материализован» в кластере Kubernetes.

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

Warden: управление доступом AI-агентов

Всем привет!

Использование агентов крайне удобно. Особенно когда надо получить быстрый результат для понятной рутинной задачи.

Но как быть с доступом, которым они обладают? Ведь, как правило, им дают доступ к системам, где хранятся «боевые» данные (или хотя бы не очень синтетические).

Ответом на этот вопрос может стать Warden – open-source утилита, которая представляет из себя некий «шлюз», через который проходят запросы агентов.

Это реализуется следующим образом:
🍭 В конфигурации Warden указываются URL, к которым происходят обращения
🍭 Настраиваются данные для аутентификации
🍭 Для каждой конфигурации определяются роли и их возможности
🍭 Создаётся набор skills, в которых описаны возможности ролей и их базовые действия
🍭 Далее все взаимодействие осуществляется через Warden. Например, «use the warden mcp server to list the roles I can assume»

Он сам подставит нужные данные для аутентификации и выполнит запрос с использованием требуемой роли, вернёт результат.

На текущий момент в качестве «целевых систем» Warden поддерживает MCP-серверы, LLM, VCS (GitHub, GitLab и т.д.), Observability (Grafana, Prometheus и т.д.) и не только.

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

Защита CI/CD: опыт Cilium

Всем привет!

Защита цепочки поставки и окружения сборки/доставки максимально актуальна в настоящее время.

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

Поэтому они достаточно серьёзно подошли к вопросу. И, заодно, поделились своим опытом со всеми желающими.

В статье затрагиваются темы:
🍭 Кто может запускать сборки, где они осуществляются
🍭 Использование CODEOWNERS для контроля изменений
🍭 Работа с зависимостями (pinning, обновления и т.д.)
🍭 Статический анализ
🍭 Работа с учётными данными и не только

Если нет времени читать всю статью, то вначале есть очень ёмкий tl;dr. Он описывает (в общем) подходы и практики, которые применяет Cilium.

Многое «завязано» на возможности GitHub Actions, однако это можно повторить и в других CI-решениях, если сам подход вам понравился.

AI агенты для SRE-операций

Всем привет!

Эксплуатация чего бы то ни было задача непростая, особенно когда возникают инциденты и их приходится решать. Особенно ночью. Или в выходные.

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

И проблема далеко не всегда в сложности задачи или отсутствии данных для анализа. Скорее наоборот – данных слишком много и тратится много времени на поиск ответов.

Это приводит к мысли об автоматизации. Хотя бы в части понимания причины и возможных действий по её устранению.

Именно этому и посвящена статья.

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

Для этого предлагается 5-и уровневая архитектура:
🍭 Layer 1. Данные. Журналы, метрики, события и т.д.
🍭 Layer 2. Инструменты. Системы мониторинга, логирования, непрерывной сборки, оркестрации контейнеров и т.д.
🍭 Layer 3. «Специалисты». Агенты для работы с инструментами
🍭 Layer 4. Оркестрация. Управление работой агентов
🍭 Layer 5. Люди. Принятие решений, аналитика, отчётность

С использованием этой архитектуры Автор реализовал 8 шагов, который автоматизируют процесс работы с инцидентами.

Помимо этого, в статье можно найти примеры того, как это работает и перечень технологий, которые позволили реализовать концепт.

Qwen 2.5 7B: «тонкая» настройка для ответов на ИБ-вопросы

Всем привет!

Автор статьи работает над собственным решением – Valqore. Его задача состоит в сканировании Kubernetes, Terraform и облачных ресурсов для поиска ошибок различного рода: от ИБ до несоответствия требованиям.

В качестве основы используется «движок» с детерминированным набором правил: он не галлюцинирует и даёт идемпотентный результат.

Для удобства пользователя Автор захотел добавить ИИ, который смог бы объяснить просто и понятно: «Что не так и как это исправить?».

И тут возникла проблема: ответы AI могли быть корректными, но общими. Она хорошо «подсказывала» в вопросах, связанных с облаками. Однако, ответы резко становились хуже, если вопросы были именно про Valqore.

Решением стало обучение Qwen 2.5 7B:
🍭 Создание набора данных о правилах (что проверяет, в чём проблема, как исправить и т.д.)
🍭 Создание набора данных о «доменах» (Kubernetes, Terraform, CIS Benchmarks и т.д.)
🍭 Тренировка

В результате Автору получилось добиться желаемого результата. Примеры «до» и «после» можно найти в статье.

Кроме того, там перечислены его «ошибки» и «гипотезы, которые не сработали».

А в завершение статьи представлена общая статистика обучения: от количества тестовых данных до времени обучения.

JWT: уязвимости, атаки и ИБ-практики

Всем привет!

Сейчас сложно представить веб-приложение, которое не использует JSON Web Token (JWT). Например, для аутентификации.

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

Ответы на эти вопросы можно найти в статье.

В ней Автор рассматривает:
🍭 Что такое JWT, его структура
🍭 Преимущества и недостатки использования JWT
🍭 Наиболее часто встречающиеся уязвимости JWT
🍭 Способы повышения безопасности при работе с JWT

Статья написана очень доступным и простым языком. Много примеров, диаграмм и пояснений.

Отлично подойдёт как для начала изучения вопроса, так и для систематизации знаний.

AegisBPF: runtime-защита Linux и Kubernetes

Всем привет!

AegisBPF – open-source инструмент, который позволяет отслеживать и блокировать несанкционированные действия с файловой системой и/или попытки установления сетевых соединений.

Для этого он использует возможности BPF и Linux Security Modules (LSM).

Из ключевых возможностей можно выделить:
🍭 Использование BPF LSM для блокировки открытия файлов
🍭 Контроль разрешенных IP-адресов, CIDR, портов и т.д.
🍭 Возможность работы в режиме «мониторинга»
🍭 Выгрузка метрик в Prometheus (количество блокировок, статистика)
🍭 Полноценное журналирование активности и не только

Возможна установка как на «обычную» Linux-машину, так и в кластер Kubernetes (для этого есть готовый Helm Chart).

Для визуализации информации (общие метрики, информация по политикам) можно использовать WebUI AegisBPF.

Больше информации, включая данные о потреблении ресурсов в сравнении с Tetragon и Falco, можно найти в GitHub-репозитории проекта.

The Definitive Guide to AI for DevOps / Agentic DevOps

Всем привет!

В приложении можно найти whitepaper (~ 43 страницы): The Definitive Guide to AI for DevOps / Agentic DevOps.

Материал подготовлен небезызвестным специалистом в мире Kubernetes и DevOps – Mumshad Mannambeth совместно с Jennifer Riggins.

Согласно материалу, в 2026 году из-за массового внедрения ИИ в «основную жизнь» «основной вопрос» изменился с «Насколько быстро мы можем писать код?» на «Как мы можем безопасно доставлять его в промышленное окружение?».

Но ИИ – таже самая технология, помощник. И всё очень сильно зависит от того, как с ним работать.

Бездумное использование принесёт больше проблем. Продуманное – может помочь. Но как быть и что делать?

Именно этому и посвящён whitepaper.

Он содержит разделы:
🍭 Where we are today. Нюансы, порождаемые повсеместным использованием ИИ
🍭 Where we need now. Использование guardrails, использование мульти-агентских систем, безопасность и observability
🍭 Measurement that matter. О том, какие метрики можно использовать для оценки эффективности использования ИИ в DevOps

Явных ответов и детальных планов, содержащих пошаговые инструкции не представлено.

Однако, внутри много интересных мыслей, которые помогут сориентироваться в том, что делать.

P.S. Поблагодарить Mumshad Mannambeth и команду, которая делала whitepaper можно вот тут! ☺️

MCP Configuration Poisoning

Всем привет!

Ёмкая статья от Checkmarx, посвященная тому, как можно выполнять произвольный код на рабочей станции жертвы через воздействие на конфигурационные MCP-файлы.

Эти файлы содержат информацию о возможных для использования MCP-серверах: наименование, выполняемая команда, аргументы, переменные окружения и т.д.

Сама атака состоит в том, чтобы подменить «выполняемую команду» на ту, что нужна атакующему и с большой вероятностью она выполнится.

Из плохого – запуск в большинстве случаев может произойти автоматически, без запроса подтверждения пользователем. В некоторых сценариях даже Human-In-The-Loop (HITL) можно обойти.

Из хорошего – реализовать это может быть не так просто, т.к. потребует некоторого доступа к данным проекта.

В качестве примера реализации Автор приводит Snyk, snyk-agent-scan которых как раз мог «реализовать» MCP Configuration Poisoning(кстати, Snyk сперва не согласился с тем, что это недостаток ☺️).

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

Поэтому в качестве рекомендации Автор предлагает использование «песочниц», мониторинг и контроль выполняемых программ и подтверждение действий пользователем.