Kelos - AI-агенты как нативные ресурсы Kubernetes

Все привыкли запускать кодинг-агентов локально: открыл терминал, набрал claude или codex, посидел рядом, посмотрел. Проект Kelos предлагает другой взгляд: а что, если агенты — это не одноразовые локальные команды, а декларативные ресурсы в кластере, как Deployment или CronJob?

Kelos добавляет в K8s набор CRD, которые превращают работу AI-агентов в часть control plane:
- Task — одиночный запуск агента с промптом (выполняется в эфемерном поде);
- Session — долгоживущий диалог на StatefulSet, к которому можно подключаться из веба или терминала;
- TaskSpawner — автоматическое порождение задач из GitHub Issues и PR, вебхуков, Jira или по расписанию;
- Workspace — описание git-репозитория с аутентификацией;
- AgentConfig — переиспользуемые наборы инструкций, плагинов и MCP-серверов.

Под капотом поддерживаются Claude Code, OpenAI Codex, Gemini, OpenCode, Cursor и произвольные контейнерные образы. Задачи можно связывать в цепочки через dependsOn с передачей результатов между этапами — получается полноценная оркестрация: один агент скаффолдит сервис, второй пишет тесты, третий готовит PR.

Что это даёт на практике:
1. GitOps для агентов. Промпты, конфигурации и workflow версионируются в git и раскатываются через kubectl/Helm — как любая другая инфраструктура.
2. Изоляция. Каждый агент живёт в своём поде без доступа к хосту и соседям, с RBAC, лимитами maxConcurrency и activeDeadlineSeconds.
3. Автономные пайплайны. Классический пример из README: TaskSpawner ловит issues с меткой bug и автоматически поднимает агента на исправление.

Недавно мы задались вопросом: Сколько CVE из официального Kubernetes feeds можно закрыть политиками PolicyEngine (Kyverno/Gatekeeper)?

И после нехитрого исследования получили следующие цифры.

1. Митигируется политиками (32 CVE)
1.1. Инъекции конфигурации ingress-nginx через объект Ingress (16 CVE)
1.2. Вектор — поля Pod/PV/Service/EndpointSlice спеки (16 CVE)

2. Частично митигируется (21 CVE)
Политика снижает вероятность/последствия, но не закрывает уязвимость: либо режет только часть векторов, либо требует хрупкой кастомной эвристики, либо «лечит» ценой отключения легитимной функциональности.

3. Не митигируется admission-политиками (38 CVE)
3.1. Баг в обработке запроса apiserver — срабатывает до/вне admission (8 CVE)
3.2. Протокольные/сетевые баги kubelet, kube-proxy, apiserver-прокси (7 CVE)
3.3. Уязвим сам admission-вебхук ingress-nginx (3 CVE)
3.4. Утечки секретов/токенов в логи control-plane (6 CVE)
3.5. Клиентские инструменты и библиотеки (4 CVE)
3.6. Инфраструктура вне кластера: Image Builder, ОС нод, сторонние UI (6 CVE)
3.7. Поведение рантайма/контроллеров, не выражаемое в admission-объектах (4 CVE)

PolicyEngine — не патч-менеджмент, а срез одного слоя. Но этот слой закрывает треть фида «малой кровью». Остальное — только обновления, RBAC, NetworkPolicy и контроль логов.

BTV K8s Sandbox — Kubernetes полигон для Blue Team

Blue Team Village к DEF CON 34 (Project Obsidian) выкатили self-contained Kubernetes-песочницу для CTF: поднимаешь локально, без общей инфраструктуры, и тренируешь defensive-скиллы на реальной малвари — но в изолированной инертной среде.

Под капотом:
- Minikube — кластер
- Tetragon — eBPF-телеметрия ядра
- Cilium — сеть и network policies
- Kyverno — admission control

Челленджи — два класса:
1) Standalone — форензика реальной Linux-малвари (21 шт.)
Малварь уже «подорвана», ты разбираешь следы в /forensics/tetragon-events.json и опознаёшь семейство по kernel-повадкам.
2) Converged Frontier — investigation-сценарии (10 × 2 трека)
Многоэтапные расследования с вводной и евиденсами в /challenge/. Каждый в двух уровнях: beginner и pro.

По сути — мини-SOC с kernel-level телеметрией, чтобы разбирать TTP атак форензик-методами, а не на проде ;)
Работает через Docker/colima (macOS) или Docker Desktop + WSL2.

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

Попытка ответа — CNAB, Cloud-Native Autonomous-attack Benchmark: полностью офлайновый детерминированный бенчмарк для оценки агентов на задачах chaining'а мисконфигураций (и на защите от них). Идея простая: любой может развернуть у себя ту же среду одной командой, подключить свою модель/своего агента (Claude, OpenAI, Gemini или локальные через LM Studio) и получить сравнимые цифры.

Внутри — 16 сценариев по Kubernetes (RBAC, NetworkPolicy), serverless (Lambda) и облачному IAM (AWS/Azure/GCP): от plaintext-кредов и IMDS/SSRF до оверпермишенов, с таксономией «фаза × домен × тип мисконфига» и уровнями сложности L1–L4.

Проект совсем свежий и пока безвестный, но направление правильное: рынок «агентных пентестеров» растет быстрее, чем способность заказчика проверить их маркетинговые заявления. И обратите внимание, что тут же встроена оценка синтеза защит — то есть бенчмарк одинаково полезен и тем, кто атакует, и тем, кто потом закрывает дыры =)

В официальном блоге Kubernetes есть статья «The Invisible Rewrite of the Kubernetes Image Promoter», и это отличный повод поговорить про безопасность цепочки поставок с непривычной стороны.

Все любят обсуждать её на уровне cosign и SLSA, но мало кто задумывается, через какой именно код физически проходит каждый официальный образ k8s. А проходит он через kpromo — image promoter, который тащит образы из staging в registry.k8s.io, подписывает их через cosign, раскатывает подписи по 20+ региональным зеркалам и генерит SLSA -provenance. Если он падает — не выходит ни один релиз Kubernetes. То есть это буквально корень доверия для всего дистрибутива образов.

И вот эту критичную штуку по-тихому переписали. За плечами у promo-tools 7 лет наслоений: монолитная логика промоушена, дубли, боль с тестами, регулярные rate limit-падения и 30+ минут на прод-джобу.

Как итог: −20% кода, заметное ускорение, и всё это с нулевым даунтаймом — никто ничего не заметил =) Отдельно приятно, что тут же живут SBOM и vulnerability scanning, то есть весь supply-chain обвес.

3 года назад мы уже писали про бесплатную open-source платформу, которая помогает готовится к экзаменам CKA, CKAD и CKS или просто освоить Kubernetes.

И есть отличная новость - проект живой и развивается. На пример, его команда недавно добавила курс по Istio и лабы к нему! Это будет максимально полезно если готовитесь (или просто смотрите в сторону) к Istio Certified Associate (ICA).

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

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

В CRI-O обнаружили новую уязвимость CVE-2026-15809, которая оказалась обходом исправления четырехлетней давности для CVE-2022-4318. Из-за ошибки в реализации защита никогда не работала так, как предполагалось: код искал строку `\n` вместо реального символа перевода строки.

Злоумышленник, способный задать переменные окружения контейнера, может внедрить перевод строки в переменную HOME и тем самым добавить произвольные записи в /etc/passwd. Это открывает путь к повышению привилегий внутри контейнера и показывает, насколько опасными могут быть ошибки в механизмах, отвечающих за создание контейнеров.

Особенно примечательно, что проблема существовала с декабря 2022 года, несмотря на наличие официального исправления.

Прод встал колом по CPU, а перезапускать поды нельзя — знакомая история. Обычно дальше начинается танец с ephemeral containers и пересборкой образа с профайлером внутри.

Google выложил app-toolbox — кастомную сборку штатного COS Toolbox образа для хостов на Container-Optimized OS (ноды GKE, обычные GCE VM), которая снимает профили с живых контейнеров, ничего не перезапуская:
- Java — JFR через jattach, zero-copy, работает даже с read-only ФС контейнера
- Python — py-spy с --nonblocking и --idle
- Golang — on-CPU профилирование через bpftrace
- Node.js — off-CPU профилирование на eBPF
- системная диагностика: biolatency, tcpretrans, offcputime в CO-RE варианте, то есть без kernel headers

Всё это заворачивается интерактивным скриптом app-collector, результат складывается в .tar.xz с SHA-256.

Идеи и бинари можно переиспользовать для собственной реализации в рамках своего окружения ;)

Istio представил новый API TrafficExtension, который объединяет настройку расширений Envoy на базе WebAssembly (Wasm) и Lua в едином интерфейсе. Раньше для Wasm использовался WasmPlugin, а Lua-скрипты приходилось подключать через низкоуровневый EnvoyFilter, который был сложен и подвержен ошибкам.

Новый API работает с сайдкарами, ingress/egress-шлюзами и waypoint-прокси, а также поддерживает как классический sidecar-режим, так и Ambient Mode. Это позволяет использовать единый способ расширения трафика независимо от архитектуры сервиса и упрощает миграцию между режимами работы Istio.

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

Usernetes разворачивает Kubernetes без root на хосте (писали о нем еще в 2020) — чтобы побег из контейнера никуда не вёл. На днях проект перешёл с Gen2 на Gen3.

Gen2 умел ровно один режим: Kubernetes-in-Docker поверх Rootless Docker/Podman/nerdctl — как rootless kind, только с поддержкой нескольких хостов.

Gen3 — надмножество: этот режим остался дефолтным, а сверху приехал Kubernetes-in-Kubernetes, где внутренний кластер живёт во внешнем в виде подов с hostUsers: false (KEP-127, UserNamespaces GA в 1.36).

Что тут важно для c точки зрения ИБ:
- node-поды не используют privileged: true. Вместо него — все namespaced capabilities, procMount: Unmasked и unconfined seccomp/AppArmor, а изоляцию держит user namespace. Тот же приём применён к kube-proxy внутреннего кластера: privileged выкинут в пользу NET_ADMIN и NET_RAW
- при этом namespace обязан разрешать профиль privileged в Pod Security admission — снаружи картина максимально пугающая, хотя это ровно тот случай, ради которого userns и создавали
- kubelet выдаёт каждому userns-поду свой диапазон в 65536 UID/GID, причём /etc/subuid хостов не участвует вообще — тенанты не пересекаются по UID даже на одной ноде

Цена вопроса: containerd >= 2.1 с отдельным runtime handler и cgroup_writable = true (включать его на дефолтном runc авторы прямо не советуют — заденет все непривилегированные поды), ядро >= 6.3 ради idmapped mounts для tmpfs, и сам режим помечен как экспериментальный. Зато отлично видно, до чего доросли user namespaces: целый кластер с kubelet, containerd и etcd уезжает внутрь пода — и без privileged =)

ControlPlane опубликовала Kyverno End User Threat Model — открытую модель угроз для пользователей Kyverno. Она помогает понять, какие активы защищает Kyverno, какие существуют доверительные границы, кто может быть атакующим и через какие сценарии возможна компрометация.

Модель охватывает такие компоненты, как Admission Controller, Background Controller, Policy Reports, вебхуки, Kubernetes API и взаимодействие с внешними системами. Для каждого сценария описаны возможные последствия и существующие механизмы защиты.

Это полезный материал не только для пользователей Kyverno, но и для всех, кто внедряет policy-as-code в Kubernetes. Вместо разрозненных рекомендаций можно увидеть систему целиком и понять, какие риски действительно стоит учитывать при эксплуатации платформы.

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

Показательный случай — CVE-2025-46599 в K3s. В ветке 1.32 конфигурацию kubelet перевели с устаревших CLI-флагов на структуру v1beta1.KubeletConfiguration с генерацией YAML drop-in. А у поля ReadOnlyPort в апстримной go-структуре стоит omitempty — и значение 0 просто выпало при маршалинге. kubelet подставил свой дефолт и поднял 10255: неаутентифицированный доступ к /pods со со спецификациями Pod’ов, включая потенциально чувствительные значения в env, аргументах запуска и других полях; в отдельных конфигурациях это могло приводить к раскрытию токенов и credentials. Разбор — в issue #12164, починили только в 1.32.4-rc1+k3s1, то есть проблема присутствовала в нескольких последовательных релизах ветки 1.32.

А теперь самое интересное. Всё это время CIS self-assessment guide в пункте 4.2.4 писал ровно обратное: «By default, K3s sets the --read-only-port to 0». И сама проверка сформулирована так: Expected Result: '--read-only-port' is equal to '0' OR '--read-only-port' is not present. После рефакторинга флага в командной строке kubelet не стало — то есть автоматический аудит по этому пункту честно рапортовал PASS, пока порт слушал. Один и тот же коммит и открыл дыру, и ослепил проверку.

Вывод простой и невесёлый: все всегда стоит перепроверять и подвергать сомнению =)

В Kubernetes постепенно появляются z-pages — специальные диагностические endpoint'ы (statusz, flagz, configz), которые помогают понять реальное состояние компонентов кластера. На практике именно configz наиболее полезен для аудита безопасности, так как показывает итоговую конфигурацию с учётом файлов конфигурации, а не только параметров командной строки.

Автор статьи Show us Zee Pages, Rory McCune показывает, почему полагаться только на flagz опасно. Если компонент использует конфигурационные файлы, информация может быть неполной или даже вводить в заблуждение. При этом доступ к configz неодинаков для разных компонентов Kubernetes, а для некоторых из них требуются дополнительные права и сетевой доступ.

Чтобы упростить анализ, автор разработал утилиту zeedumper, которая собирает данные из statusz, flagz и configz, а также пытается восстановить отсутствующие значения по умолчанию. Это может заметно облегчить аудит и проверку конфигурации Kubernetes-кластеров.