Wiz представила SITF (SDLC Infrastructure Threat Framework) — первую в мире открытую модель угроз, специально ориентированную на защиту инфраструктуры жизненного цикла разработки программного обеспечения. Эта инфраструктура (IDE, VCS, CI/CD, Registry) становится привлекательной целью для атак не только на код, но и на сами процессы сборки и доставки ПО.

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

Контейнеры, их спецификации и форматы уже давно вышли за рамки просто запуска контейнерных приложений. И сегодняшний проект очередное этому подтверждение.

bootc - это инструмент для транзакционного обновления ОС через OCI/Docker-образы. Он позволяет использовать контейнеры как формат доставки загрузочного ядра и базовой системы. Проект написан на Rust, входит в состав CNCF и поддерживает стабильный CLI для разных дистрибутивов.

По использованию можно посмотреть тут.

Ingress-nginx доживает свои последние дни, но это не мешает появляться новым уязвимостям – CVE-2026-1580, CVE-2026-24512, CVE-2026-24513, CVE-2026-24514.

Две уязвимости уже ставшие классическими для этого решения – configuration injection с последующим RCE внутри контейнера с ingress-nginx. Еще одна уязвимость также – configuration injection с последующим обходом auth-url protection. И DoS Admission Controller.

Все четыре уязвимости оценены как High и имеют оценку 8.8 по CVSS.

Конечно, вы можете обновиться на версию v1.13.7 или v1.14.3, но мы крайне рекомендуем переезжать на API Gateway.

K8sQuest — это локальный симулятор для обучения Kubernetes через практику. Игроки решают 50 задач по отладке (Pods, Networking, RBAC) на кластерах kind или k3d. Платформа бесплатна, не требует облаков и включает систему опыта (XP), подсказки и разборы реальных инцидентов.

В пятом и последнем разделе есть немного задачек по безопасности, связанные с:
- RBAC (ServiceAccounts, Roles, RoleBindings)
- SecurityContext, Pod Security Standards (restricted)
- ResourceQuotas, NetworkPolicies, node scheduling
- Taints/Tolerations, PodDisruptionBudgets, PriorityClass

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

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

Эту рабочую неделю мы хотим закончить разбором интересной статьи под названием "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).

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

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

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

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

На канале мы не раз рассказывали про проект 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

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, то есть речь не о компрометации всей платформы, а о выходе из пользовательского контейнера.

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