k8s (in)security

Напоминаем, что идет прием заявок на доклады БеКон 2026 и до его закрытия осталось чуть меньше месяца! Единственная конференция по безопасности контейнерных технологий ждет ваших заявок ;)

Есть 2 трека со строгим логическим разделением.

1 трек - Ингредиенты

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

2 трек - Рецепты

Данный трек посвящен людям, командам и процессам связанным с безопасностью контейнеров и Kubernetes. Он для С-level, Leads, которые продумывают и выстраивают все в компании.

Также есть возможность ЗАКАЗАТЬ доклад ;)

P.S. Как всегда будем рады обсудить и помочь сформировать заявку если у вас есть мысль/идея, но вы не уверены в ней.

P.S.S. Будем признательны за репост!

Cilium 1.19 вышел с рядом заметных улучшений сетевого стека и безопасности, отмечая 10-летие проекта с почти 3 000 коммитов от более 1 000 контрибуторов. Основные новшества касаются прозрачного шифрования трафика: теперь можно включать Ztunnel в бета-режиме, чтобы обеспечить автоматическое шифрование и аутентификацию TCP-соединений между рабочими нагрузками без прокси сайдкаров. Также добавлены строгие режимы для IPsec и WireGuard, которые требуют, чтобы весь трафик между узлами был зашифрован.

Сетевые политики стали более выразительными и удобными в отладке, появились расширенные DNS паттерны и более безопасные значения по умолчанию для многоузловых кластеров. Multi Pool IPAM переведён в стабильный статус и теперь работает с IPsec и прямой маршрутизацией, что полезно для распределённых и сегментированных адресных пространств.

Наблюдаемость через Hubble улучшена: можно трассировать пакеты с учётом параметров шифрования и получать информацию о том, какая политика вызвала отбрасывание трафика. Всё это делает Cilium 1.19 интересным обновлением для крупных Kubernetes инсталяций с высокими требованиями к безопасности и сложным сетевым окружением.

Guardon — это расширение для Chrome, которое проверяет YAML файлы K8s на соответствие политикам и при этом не требует настройки инфраструктуры или изменений в ваших пайплайнах.

Вы просто устанавливаете его и открываете любой YAML-файл в веб-интерфейсе GitHub или GitLab. Проверка запускается в один клик.

Guardon меняет правила игры, перенося безопасность прямо в браузер (Весь анализ происходит локально в вашем браузере - никакой утечки информации). Это Shift Left в чистом виде: вы ловите ошибки в тот момент, когда смотрите код, сокращая время выхода продукта на рынок за счет мгновенного фидбека.

Найти ошибку — это только 50% дела. Guardon экономит время, предлагая функцию Smart fix suggestions. Патчи в двух видах Preview patch и Copy snippet.

При этом под капотом у инструмента всем хорошо знакомые движки: Open Policy Agent (OPA) (rego правила) и Kyverno политики. Политики от Kyverno он еще позволяет легко импортировать!

Из статьи «Google Cloud Shell Container Escape» можно узнать, как исследователь разобрал архитектуру Google Cloud Shell и показал, что среда работает внутри привилегированного контейнера, а не изолированной VM. Ценность материала — в детальном реверсе окружения и пошаговой эксплуатации через механизмы ядра вроде core_pattern и hotplug.

Автору удалось добиться container escape и получить root доступ на хосте Kubernetes ноды, что фактически ломает модель изоляции Cloud Shell. При этом он всё же остался внутри инфраструктуры Google Compute Engine, то есть речь не о компрометации всей платформы, а о выходе из пользовательского контейнера.

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

Наверно одним из самых странных или неправильных на мой взгляд (в моем топе) запросов за время консультирования по вопросам безопасности и построения систем защиты в Kubernetes был: "Нам нужно чтобы у ИТ не было возможности это видеть/понимать/контролировать/участвовать/... в процессе обеспечения безопасности в Kubernetes". Кому-то тут может быть смешно, но такое доводилось слышать не 1 раз...

При этом вспоминаем, что DevSecOps это процесс и коммуникация между разными департаментами. Также открываем CNCF Cloud Native Security Whitepaper и читаем, там что обеспечении безопасности в Cloud Native это кросс командная вещь и в ней участвуют и разработчики, и оперейшен команду, и команды безопасности.

Запомните, что очень важно чтобы все участники процесса разговаривали на одном языке, видели единую картину происходящего! Иначе это несогласованность, неполадки, задержки, аварии и конфликты. И в таком случае вы действительно никакой пользы, выигрыша от использования контейнеров и Kubernetes не получите ...

А вы встречались с таким запросом/ситуацией?

Всем, привет!

Мы рады сообщить, что мы запустили старт продаж билетов на нашу конференцию по безопасности контейнеры и Kubernetes - БеКон 2026!

В этом году как мы писали будет ряд нововведений! Самое важное, что максимально полезно и практично как для начинающих специалистов, так и для опытных спецов, а также как для технарей, так и для C-level!


Билеты можно купить тут!

Capacitor — это UI для FluxCD. Инструмент подключается к кластеру через kubeconfig и дает удобный обзор приложений, Helm релизов и всех связанных ресурсов в одном месте.

Поддерживает мультикластерность, RBAC и сравнение желаемого и фактического состояния ресурсов. Можно быстро понять, что именно задеплоено, где есть дрейф и какие изменения пришли из Git.

Хороший вариант для команд, которые используют FluxCD, но хотят больше прозрачности и контроля без перехода на другой стек.

Вышла новая версия Kyverno 1.17!

0) Сильно обновили и прокачали библиотеку политик - более 600!
1) Добавлены неймспейсные политики для мутации и генерации (NamespacedMutatingPolicy, NamespacedGeneratingPolicy) - ранее были только кластерные
2) Новые CEL политики достигли версии v1 (GA). Благодаря этому переходу команды разработчиков платформы могут уверенно перейти от политик на основе JMESPath к CEL, чтобы воспользоваться преимуществами значительно улучшенной производительности и лучшей согласованности с вышестоящими нативными политиками Kubernetes в виде ValidatingAdmissionPolicies/MutatingAdmissionPolicies.
3) Добавили новые CEL возможности и функции
4) Уход от legacy API. Policy и ClusterPolicy больше развиваться не будут, тоесть в новых версия нужно успеть сделать миграцию на CEL политики!

Вы все еще используете Kubernetes Dashboard? 21 января 2026 года проект был официально закрыт и переведен в архив. Это означает прекращение активной разработки и развития инструмента.

В качестве современной альтернативы сообществу теперь рекомендуется Headlamp — расширяемый веб-интерфейс для работы с кластерами. Проект развивается под эгидой SIG UI и ориентирован на управление и troubleshooting в Kubernetes.

Если вы все еще используете Dashboard, самое время планировать миграцию. Headlamp предлагает более гибкую архитектуру и активную поддержку сообщества.

Если вы заботитесь о сетевой безопасности своих кластеров на CNI Cilium, то вы точно по крайней мере знаете проект/сайт/портал Network Policy Editor, где можно визуализировать и создавать Native и кастомные политики для CNI Cilium.

А вот если у вас CNI на базе Calico и вы используете его кастомные политики (а не Native), то инструмента такого не было можно сказать по сей день)

Встречайте проект Calico Network Policy Visualizer! Инструмент имеет знакомый и понятный интерфейс для тех кто уже работал с Network Policy Editor и учитывает много специфики Calico. Проект спокойно можно развернуть у себя локально и для своей работы никакую информацию он на сторону не отправляет.

Подробнее о проекте:
- Запись "Calico Network Policy Visualiser" в блоге автора
- Исходный код проекта на GitHub
- Online версия проекта

В общем, это отличное дополнение к Whisker UI для Calico.

P.S. Большое спасибо нашему читателю за ссылку на свой замечательный проект) И не стесняйтесь делиться с нами своими pet project!

Вы уже начали переход на Gateway API? Если нет и думаете над реализацией, то репозиторий gateway-api-bench вам в помощь.

Это проект с набором тестов для оценки реализации Kubernetes Gateway API: он помогает сравнивать реальное поведение разных реализаций (Cilium, Istio, Envoy, Traefik, Kong и других) в сценариях, которые не покрыты официальными тестами.

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

Проект особенно полезен тем, кто выбирает или внедряет Gateway API в продакшн кластере, и хочет основывать выбор на реальных результатах, а не только на спецификации или маркетинговых обещаниях.

Вышло очередное обновление фреймворка Jet Container Security Framework (JCSF) от наших друзей.

Если вы не знаете, что это, для чего это и как с этим работать, то мы еще в феврале прошлого года проводили совместный вебинар "Фреймворк безопасности контейнеров JCSF" (слайды, видео), где это все обсуждали и обсуждали как его можно улучшить и поправить.

Недавно на канале мы рассказывали про статью "Kubernetes Remote Code Execution Via Nodes/Proxy GET Permission", в которой исследователь показывает как получить RCE с помощью права на чтения GET (без CREATE).

Сегодня хотим поделиться способом, как можно закрыть этот мисконфиг, используя Istio.

В репозитории nodes-proxy-get-rce-fix предлагается использовать EnvoyFilter, ServiceEntry и DestinationRule для блокировки WebSocket соединения к kubelet на порт 10250.

Из статьи "Breaking eBPF Security: How Kernel Rootkits Blind Observability Tools" можно узнать как вредоносный код на уровне ядра может ослеплять/обходить средства защиты на базе eBPF. Сам этот факт вообще не является никаким откровением. Ценность статьи в реальном разборе и демонстрации с примерами кода. Автор глубоко погружается в такие аспекты как: BPF iterators, ringbuffers и perf events.

Основной вывод: "If an attacker gains the ability to load kernel modules, they control the kernel’s view of reality. eBPF security tools run inside the kernel and thus cannot fully protect a compromised kernel. The only reliable defense is preventing kernel compromise in the first place."

По сути получаем работу в недоваренном окружение и как следствие мы уже не можем доверять информации от этой системы.

16 февраля 2026 в 11.00 наша команда Luntry совместно с командой платформы управления средами контейнерной оркестрации «Штурвал» проведет вебинар "Синергия безопасности Luntry и Штурвал. Часть 2"!

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

В рамках второй части мы коснёмся 2 областей:
- Контроль Kubernetes кластеров;
- Безопасность образов контейнеров.

Зарегистрироваться можно тут.

P.S. Материалы с первой части можно посмотреть тут.

На канале мы не раз рассказывали про проект Kata Containers, позволяющий запускать контейнеры в виде легковесных вирутальных машин, что в целом повышает уровень изоляции. Несмотря на это, критичные уязвимости в таких проектах тоже встречаются и CVE-2026-24054 тому подтверждение.

Уязвимость CVE-2026-24054 в Kata Containers (High, CVSS 8.8) позволяет при использовании повреждённого или пустого контейнерного образа некорректно смонтировать rootfs, из-за чего хостовый блочный девайс может быть «подключён» внутрь VM. Это происходит из-за fallback поведения containerd и ошибки в обработке bind-mount, из-за которой runtime принимает директорию за блочное устройство. В итоге возможно повреждение файловой системы хоста и перевод его диска в режим read-only.

Атака может вызывать двойное выделение inode и другие ошибки на уровне файловой системы, что приводит к отказу в обслуживании и риску нарушения целостности системы. Уязвимость затрагивает все версии Kata Containers до 3.26.0.

Буквально, для того чтобы сложить целую Node, нужно задеплоить контейнер на базе образа из такого однострочного Dockerfile:

FROM scratch

Zot — это проект CNCF, представляющий собой OCI-native реестр образов контейнеров. Он поставляется в виде одного бинарного файла, работает без привилегий и поддерживает разные платформы. Решение включает встроенную безопасность (подписи, сканер уязвимостей), дедупликацию и аутентификацию.

И все это в 1 бинаре!

dock-fire — это экспериментальный runtime-плагин для Docker, который запускает контейнеры внутри microVM на базе Firecracker. По сути он даёт уровень изоляции как у виртуальной машины, но сохраняет привычный workflow через docker run.

Каждый контейнер стартует в отдельной легковесной VM с собственным ядром, что повышает безопасность по сравнению с классическими namespace и cgroup изоляциями. Проект ориентирован на запуск временных workload’ов, тестирование и эксперименты.

Эту рабочую неделю мы хотим закончить разбором интересной статьи под названием "We Reverse-Engineered Docker Sandbox's Undocumented MicroVM API".

Возможно вы не знали, но Docker решил делать не только контейнеры, но и MicroVM (облегченные виртуальные машины с собственным ядром). проект называется Docker Sandboxes.

Технологий закрытая и исследователи ее разреверсили и добились того, что кроме заранее определённых AI-агентов там можно теперь запускать свое любое! Изначально создатели Docker Sandboxes целиться только в запуск там: Claude, Codex, Gemini, Copilot, Kiro и Cagent. Но теперь можно что угодно ;)

Ранее мы уже писали о подобном, но только от Google под названием Agent Sandbox.

Но есть серьезная разница в том, что проект от Google работает на Linux, то эта реализация только на Docker Desktop 4.58+ на macOS и Windows. Linux не поддерживается, так как реализация опирается на платформенные фреймворки виртуализации: Apple Virtualization.framework на macOS и Hyper-V на Windows. Для работы функции требуется поддержка вложенной виртуализации (nested virtualization).

kubectl-rexec — это небольшой плагин для kubectl, который позволяет повторно подключаться (re-exec) к уже запущенному контейнеру в Kubernetes. Он решает ту проблему, когда kubectl exec рвётся из-за сетевых проблем или таймаутов.

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