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

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

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

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

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

Из статьи "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."

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

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

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

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

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

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

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

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

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

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

Если вы заботитесь о сетевой безопасности своих кластеров на 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!

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

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

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

Вышла новая версия 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 политики!

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

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

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

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

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

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


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

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

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

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

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

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

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

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