У вашего мониторинга могут быть права на RCE. И вы сами их выдали

Залез читать изменения Kubernetes 1.36 и наткнулся на прекрасное.

У ServiceAccount вашего Prometheus, log collector или monitoring agent может быть такое правило:

resources: ["nodes/proxy"]
verbs: ["get"]

Выглядит безобидно.
Ну get же. Read-only. Просто почитать метрики и разойтись.

На деле этого права может хватить, чтобы выполнить команду в любом контейнере на доступной ноде.
Да, get.
Да, RCE.
Ага, Kubernetes moment.

Как мы вообще сюда пришли

У kubelet есть HTTPS API, обычно на порту 10250. Через него можно получать метрики, статистику, логи, список Pod — и делать exec в контейнеры.

Исторически почти все эти endpoint’ы авторизовывались через один широкий ресурс — nodes/proxy.

То есть monitoring agent, которому нужно было только сходить в /metrics, получал то же право, через которое можно добраться до /exec.
Но становится ещё веселее.

Для установки WebSocket-соединения используется HTTP GET. Kubelet сопоставлял этот запрос с RBAC-глаголом get и не выполнял дополнительную проверку на create перед началом интерактивной операции.

В результате ServiceAccount с get nodes/proxy и сетевым доступом к kubelet API мог открыть /exec и выполнять команды внутри контейнеров.
Kubernetes SIG Auth и SIG Node прямо называют nodes/proxy возможностью уровня node superuser.

Важная оговорка
Это не означает, что любой установленный Prometheus автоматически уязвим.
Должны совпасть два условия:
— у ServiceAccount есть get на nodes/proxy;
— из workload можно достучаться до kubelet API на ноде.
Но для агентов, которые собирают данные напрямую с kubelet, второй пункт вполне может быть частью архитектуры.
И если такой агент или его токен скомпрометируют, blast radius будет немного больше, чем «сломался один дашборд».

Но ведь Kubernetes 1.36 это исправил?
И да, и нет. :)

В 1.36 KubeletFineGrainedAuthz стал GA и всегда включён. Вместо широкого nodes/proxy теперь можно выдавать точечные права:
— nodes/metrics для /metrics/*;
— nodes/stats для /stats/*;
— nodes/log для /logs/*;
— nodes/pods для списка Pod.
Например:

resources: ["nodes/metrics", "nodes/stats"]
verbs: ["get"]

Но апгрейд не удаляет старые разрешения.
Для обратной совместимости kubelet продолжает принимать nodes/proxy. Поэтому кластер может быть на свежей версии, все Pod зелёные, а старый blast radius никуда не делся.
Совместимость бережно сохранила не только ваши интеграции, но и лишние права. Очень заботливо.

Что я бы проверил прямо сейчас
1. Найти все ClusterRole с nodes/proxy:

kubectl get clusterroles -o json | jq -r '
.items[]
| select(any(.rules[]?;
    (.resources // []) | index("nodes/proxy")))
| .metadata.name'

2. Посмотреть, к каким ServiceAccount они привязаны. Особенно внимательно — monitoring, logging, security и разные node-level DaemonSet.

3. Проверить конкретный ServiceAccount

kubectl auth can-i get nodes/proxy \
  --as=system:serviceaccount:<namespace>:<serviceaccount>

4. Понять, какие kubelet endpoint’ы агент реально использует, и заменить nodes/proxy на минимальный набор nodes/metrics, nodes/stats, nodes/log или nodes/pods.
Не выдавайте весь набор «на всякий случай». Мы именно так сюда и приехали.
5. Проверить scrape и сбор логов на canary, удалить старое право и запретить новые workload-binding’и с nodes/proxy через admission policy. Доступ к 10250 тоже стоит ограничить на сетевом уровне.
Только не удаляйте разрешение вслепую из системных ролей: оно легитимно нужно некоторым компонентам Kubernetes. Нас интересуют обычные workload’ы, которым его выдали ради observability.

Главный вывод тут даже не про kubelet.
get — это название операции, а не гарантия безопасности.
Если ресурс называется proxy, вы разрешаете не чтение объекта. Вы открываете туннель к чужому API.
А что можно сделать внутри этого туннеля — RBAC-глагол вам уже не расскажет.

А у вас monitoring ServiceAccount всё ещё живут с nodes/proxy или вы уже перешли на fine-grained RBAC?
#kubernetes #security #sre

Встречаемся на ПерфКонф #12? ДА!

Вы, возможно, знаете, а может, и нет, но я очень люблю участвовать в программных комитетах разных конф. И вот уже второй год подряд я вхожу в ПК ПерфКонф.)))

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

В этом году поговорим о нагрузочном тестировании, оптимизации производительности, DevOps и CI/CD, SRE и Observability, применении ИИ, хаос-инжиниринге и других актуальных задачах.

📍 Москва, Loft Hall на Автозаводской
💻 Также можно участвовать онлайн
🗓 9 сентября 2026 года

А для тех, кто покупает билет как физлицо, есть промокод pk20 — укажите его при оформлении.

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

До встречи на ПерфКонф #12! 🚀

#ПерфКонф #Performance #SRE #DevOps #НагрузочноеТестирование

Самый опасный деплой 2026 года - тот, который никто не считал деплоем

Залез перечитывать большие постмортемы этого года. Пока мы спорим, пускать ли AI-агента в on-call, три самых громких аутэджа года говорят совсем о другом.

Cloudflare, 20 февраля. Azure, 23 июля. Google Cloud, 20 августа. Три компании, три стека, одна причина: плановая, рутинная, «безопасная» операция, которую выполняла автоматика. Никто не катил релиз. Никто не лез в прод руками. Всё по регламенту.

1. Cloudflare: cleanup с пустым параметром
Задача чистила BYOIP-префиксы, помеченные на удаление. Параметр pending_delete ушёл в API без значения - и сервер вернул вообще все префиксы. Система честно начала удалять их вместе с зависимыми объектами. Из BGP ушли ~1 100 из 4 306 префиксов, четверть. 6 часов 7 минут. Код отработал правильно. Просто вопрос был задан неправильно. Знакомо?
2. Azure West US: blast radius посчитали не так
Рутинный break-fix на сети. Система анализа blast radius из-за дефекта расширила scope на все оптические устройства датацентра. Safety validation тоже отработала и сказала «безопасно»: она проверяла устройства по одному, а не эффект от изоляции всех сразу. Маршруты между ДЦ и WAN исчезли, около 5 часов. Алерты сработали через минуту, а вот связать аномалию с maintenance-триггером смогли только через 2,5 часа. Откат - руками.
3. Google Cloud us-west1: failover не сделал failover
Плановые работы на оптике между ДЦ. Ёмкость просела сильнее ожидаемого, automated rerouting «failed to properly redistribute traffic». Деградация трёх десятков продуктов. 2 часа 22 минуты. В remediation Google обещает «stricter safety checks and circuit redundancy requirements prior to routine maintenance». У Google. Если казалось, что только у вас так - нет.

Что общего
Uptime Institute в Annual Outage Analysis 2026: 92% считают человеческий фактор хотя бы частичной причиной последнего серьёзного сбоя, самая частая форма - failure to follow procedures (59%). 87% говорят, что аутэдж можно было избежать.
Но заметьте: во всех трёх кейсах процедуры были. И им следовали. Проблема в том, что плановые работы и «служебная» автоматика живут вне контура безопасности, который мы построили для деплоев. У релиза есть canary, progressive rollout, откат по SLO, feature flag. У «чистим префиксы» и «изолируем железку» - тикет и окно. Ну и надежда.

Что стоит проверить в любой инфраструктуре
1. Инвентаризация «не-деплоев». Cleanup-джобы, cron по удалению ресурсов, вывод нод из ротации, работы на сети и СХД, миграции DNS. Всё, что меняет прод, - это change. Даже bash по расписанию.
2. Blast radius до, а не после. Cleanup обычно удаляет 5 объектов, а собрался 25% всего? Это должно остановить задачу, а не попасть в постмортем. Cloudflare ровно это и внедряет.
3. Safety-check на совокупность, а не поштучно. Если pre-flight проверяет элементы независимо, у вас нет pre-flight.
4. Failover тестируется до maintenance. Автоматический rerouting - тоже код. Плановое окно - не время узнавать, что запасной путь не тянет.
5. Связь «что делали» и «что сломалось». Плановые работы и запуски автоматики должны быть annotation'ами на дашбордах и событиями в timeline, как деплои.
6. Ручной откат отрепетирован. Во всех трёх кейсах автоматика не откатила себя сама. Я такое гонял на Wheel of Misfortune: сценарий «плановые работы пошли не по плану» отлично ложится в формат, в моей платформе собирается за вечер. Отрезвляет, когда на словах все знают, где кнопка «стоп», а на игре её ищут пять минут.

Мы научились не бояться деплоев: сделали их частыми, маленькими и обратимыми. Плановые работы пока живут в 2015 году: редкие, большие и «там всё проверено».
Ломает прод не то, что вы считаете рискованным. А то, что перестали считать изменением.

Вопрос к вам: у ваших плановых работ и cleanup-джобов есть хоть что-то из того, что есть у деплоя? Или тоже тикет, окно и надежда?

#sre #incidentresponse #changemanagement #postmortem #wheelofmisfortune

Агенту разрешают расследовать, но не разрешают чинить. Почему граница именно здесь????

В ноябре я писал про SRE Agent от PagerDuty: начинайте с read-only. Прошло десять месяцев, и спор сместился: уже не «заменит ли AI дежурного», а «где проходит граница». 24 августа в r/sre инженер после полугода on-call заметил одно и то же во всех обзорах AI SRE-инструментов: расследовать агенту дают одному, чинить - никто. Это навсегда?

Что говорят цифры
ORCA-bench, 30 июля, Cornell Tech, Columbia и Traversal (последние продают AI SRE-агента, держите в уме). Стенд: 19 микросервисов на OpenTelemetry, шесть дней телеметрии в Prometheus, Jaeger и OpenSearch, доступ к коду, 1 079 задач на root cause, пять фронтирных моделей. Лучшая точность RCA на задачах средней сложности (реалистичный ввод) - 25,3%, на сложных - 10,0%, разрыв сохраняется даже с Claude Fable 5. Слабейшая модель выдумывает неправдоподобную причину в 40% отчётов. Типичная ошибка: хватается за заметный симптом ниже по потоку вместо причины выше. Авторы называют это нижней границей: прод больше и грязнее стенда.

Комментатор в треде сформулировал точно: плохой анализ в худшем случае тратит ваше время, запись в прод без человека - катастрофа. Граница проходит по цене ошибки.

NeatContext в июле выключили автономного агента с доступом к логам: таймаут платёжного шлюза он связал со всплеском коннектов к БД двенадцатью часами раньше, через RAG унаследовал устаревший runbook и не умел сказать «не знаю». «Получили уверенный генератор галлюцинаций». Они продают свой инструмент, но симптомы знакомые.

Как границу строят руками
1. Read-only, который действительно read-only. HyperProbe (Launch HN, 5 августа) даёт агентам ставить виртуальные пробы в работающий процесс. Главный вопрос треда: чем «только чтение» гарантия, а не договорённость? В Python чтение атрибута может дёрнуть @property с ленивой загрузкой из БД, в Java геттер - взять лок.
Ответ: условия без вызовов методов и доступа к свойствам (order.total > 5 нельзя, total > 50 можно) плюс бюджеты.
2. Вето вне агента. В r/kubernetes: LLM предлагает scale, rollback, cordon, drain, а детерминированный Safety Engine без LLM проверяет действие по живому состоянию API.
Комментарии: вето должно жить там, где агент не может исполнять код (отдельный процесс, admission webhook), иначе «вы построили второе мнение, а не вето»; оно должно быть stateful (бюджет blast radius, cooldown, проверка результата) и перепроверять состояние прямо перед мутацией.
3. Обратимость как критерий. Security patching автоматизировали, потому что у каждого действия известен откат. Rollback, scale, restart - митигации, а не фиксы. Команды на GitOps уже пускают агентов открывать PR («большинство RCA были верными»), но мержить и катить - человек. Mezmo выложили в open source AURA : их SRE-команда упёрлась в переполнение контекста, галлюцинации и approval fatigue и «провела жёсткую черту: права в проде не ослабляем».
Инструменты проверяются вне контекста агента, approval через webhook, по таймауту - fail-closed.

Другой полюс
Boris Tane (ex-Baselime и Cloudflare, теперь строит Polylane: «никто не должен дежурить в 2026») 21 августа опубликовал On-Call Is Now Theatre: дежурство - признание поражения, если пейджить агента бесплатно, алертов нужно радикально больше, а единственный валидный результат расследования - diff.
Он продаёт это будущее. Но даже его рецепт на первую неделю - дать агенту read-доступ к телеметрии на самом шумном алерте и две недели сравнивать его triage с людьми. То есть read-only.

Что я из этого я бы точно себе забрал?
Граница - не вопрос доверия, а отсутствие того, что в треде назвали bounded authority: система должна знать, что ей можно, при каких доказательствах и когда нужен второй approve. Без базы из ноябрьского поста (SLO, связная телеметрия, живые runbook'и) агент просто быстрее ошибается. И измеряйте: прогоните агента по своим постмортемам и посчитайте долю неверных вердиктов.

Вопрос к вам: что вашему агенту уже разрешено делать в проде без человека? И кто это разрешил - policy или привычка?

#sre #oncall #ai #incidentresponse #observability

Wheel of Misfortune, но с настоящим прод‑инцидентом внутри
Полгода назад я писал, зачем SRE нужна Wheel of Misfortune: ролевая игра про инцидент, где ведущий рассказывает, что видит дежурный, а дежурный говорит, что бы он сделал.
Полезно, дёшево, но есть одна честная проблема: это разговор. Никто ничего не чинит. «Я бы посмотрел describe pod» звучит одинаково у того, кто делал это сто раз, и у того, кто ни разу.

И тут я подгорел и сделал платформу, где инцидент настоящий, тк инцидентное мышление тренируется руками, а не словами.

Вашему вниманию - тренажёр инцидентов с живыми окружениями.

WoM Platform

Заходишь, выбираешь сценарий (или крутишь колесо), и через пару секунд для Linux‑хоста или через минуту для Kubernetes у тебя в браузере терминал в изолированный стенд, который уже сломан.
Nginx отдаёт 502, диск базы забит бинлогами, rollout завис на квоте, HPA пилит сам себя, cert-manager не может продлить сертификат.
Чинишь как на настоящем дежурстве (как будто бл* на работе мне этого не хватает, ага): логи, ss, df, kubectl describe, kubectl edit.
Жмёшь «Проверить» - грейдер смотрит на результат, а не на способ: любой честный путь засчитывается, «убрать пробу» или «поднять лимит памяти» - нет.
После решения открывается разбор: что было сломано, как диагностируется, эталонное решение, ловушки, что почитать.

Что уже готово
22 живых сценария от Junior до Senior.
Для джунов - учебные копии. У каждого junior‑кейса две версии: обычная и учебная с панелью «Нужна помощь?», которая открывает этапы диагностики по одному и объясняет, зачем нужна каждая команда. Не «вот ответ», а «вот куда смотреть и почему». Плюс шпаргалка и что почитать заранее.
Стенды настоящие. Каждый сценарий проходит регресс: свежий стенд не решён, эталонное решение решает, ловушки не проходят.

Ограничения, чтобы не было сюрпризов
Одновременно живут до 6 Kubernetes‑стендов и до 20 сессий всего, а поднимаются они по два за раз: если увидите «ждём свободный слот» или «занято», это не поломка, подождите пару минут.
Неиспользуемые 7 дней учётки отключаются автоматически. Почты пока нет, так что если не пускает или еще какие то проблемы - напишите мне, пожалуйста.
Тяжёлые стенды (cert-manager, Prometheus, ingress) поднимаются 2–3 минуты, на странице видно, что именно сейчас происходит.

Что планирую дальше?
Заопенсорсить, что бы вы могли кидать свои кейсы сами и разворачивать это у себя. Ну или смотреть как это сделано у меня и сделать лучше для себя и под себя.
Прикрутить почту, что бы была нормальная регистрация по email. Ну и конечно же, больше и больше кейсов.

И еще пару слов
Бекенд писал сам, старался и мучался как мог что бы работало классно и интересно. Кейсы тоже из своей практики. Но вот UI пришлось допиливать через openai. Ну не умею я во фронт так хорошо что бы было не больно.

Вопрос к вам: какой инцидент из вашей практики вы бы превратили в сценарий первым? Присылайте пост‑мортемы, самые интересные сделаю и опубликую с указанием автора.

#SRE #WheelOfMisfortune #oncall #kubernetes #incident_response