В начале ноября было раскрыто 3 новых CVE в runc – CVE-2025-31133, CVE-2025-52565 и CVE-2025-52881 с оценкой 7.8 по CVSS. Они эксплуатируют ошибки в обработке maskedPaths, работе с /dev/console и монтировании /proc, что даёт возможность совершить побег из контейнера.

Исходя из описания бюллетеней для эксплуатации всех багов атакующему нужно иметь возможность запускать контейнеры с кастомными настройками монтирования (или получить напрямую доступ к runc), чего можно добиться через Dockerfile.

Обнаружить эксплуатацию этих уязвимостей можно отслеживая подозрительные симлинки, вроде таких:

ln -s /proc/sys/kernel/core_pattern /dev/pts/2

Разработчики runc рекомендуют включить user namespace для всех контейнеров, а также использовать rootless контейнеры.

Исправления доступны в версиях runc 1.2.8, 1.3.3, 1.4.0-rc.3.

Вышла новая версия Kubernetes - 1.35 и этому посвящена данная блоговая запись "Kubernetes v1.35: Timbernetes (The World Tree Release)" на официальном сайте. Из нее вы узнаете об основных изменениях и нововведениях. Релиз, включает 60 улучшений, из которых 17 стали стабильными, 19 — бета-версиями и 22 — альфа-версиями.

Отдельно отметим удаление поддержки cgroup v1!

Таким образом, поддерживаемые версии K8s и их жизненный цикл выглядит следующим образом:
- 1.35 - поддержка до 2027-02-28
- 1.34 - поддержка до 2026-10-27
- 1.33 - поддержка до 2026-06-28
- 1.32 - поддержка до 2026-02-28

Все остальные версии уже не поддерживаются!

Заканчиваем эту неделю полезной тулзой для пользователей Firecracker – FireCrackManager.

Он позволяет создавать, запускать и останавливать легковесные виртуальные машины через REST API и веб-интерфейс. Проект поддерживает работу с дисками, сетями, снапшотами и образами. Подходит для сценариев, где требуется запуск большого количества VM с минимальными накладными затратами.

Написан на Go и ориентирован на автоматизацию и инфраструктурные задачи.

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

И тут у нас есть нововведение. Теперь на конференции будет не 1, а 2 трека. При этом у них есть строгое логическое разграничение.

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

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

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

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

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

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

18 декабря состоялась первая встреча рабочей группы Checkpoint Restore! При этом технология в индустрии уже лет 6 так или иначе мелькает - мы писали об этом еще в 2020 и в 1.25 есть некоторые наработки.

На этой встрече команда выделила основные цели и задачи:
1) Интеграция в Kubernetes
2) Сбор мнений сообщества
3) Разработка стандартизованного API
4) Координация усилий (CRI-O, Containerd, gVisor)

Use Cases:
- Расследование инцидентов
- Быстрый запуск контейнеров (Java, AI)
- Отказоустойчивость
- Оптимизация ресурсов GPU
- Миграция контейнеров
- Пакетная обработка (batch) и AI обучение

Первые плоды данной рабочей группы мы должны увидеть к версии 1.36

На нашем сайте Luntry в разделе Исследований стали доступны все материалы с вебинара «Интеграция Luntry и ASOC»!

Там мы разобрали:
- Какие данные можно отправлять в ASOC;
- Как это сделать;
- Почему это важно в разрезе DevSecOps;
- Показали на примере нескольких ASOC-решений, как это выглядит.

В обширной статье "A Brief Deep-Dive into Attacking and Defending Kubernetes" описывается, как Kubernetes работает и почему его безопасность критична для корпоративных сред: платформа широко используется в продакшене, но её сложность создаёт обширную поверхность атак — от API сервера до kubelet и etcd.

Автор подробно разбирает реальные векторы атак: неаутентифицированный доступ к API, слишком широкие RBAC права, злоупотребление сервис аккаунтами, вредоносные admission контроллеры, DNS отравление через CoreDNS и опасные тома hostPath, которые позволяют захватить Nodes или данные.

Для защиты рекомендуются базовые практики безопасности: отключать анонимный доступ, настраивать RBAC по принципу наименьших привилегий, ограничивать автомонтирование токенов, жестко контролировать admission конфигурации, а также использовать runtime инструменты для обнаружения подозрительных действий в кластере.

Podtrace - диагностический инструмент на базе eBPF для контейнеров в Kubernetes. Возможности:

1. Сетевой мониторинг (Network Tracing)
• Отслеживание TCP: мониторинг задержек (RTT) и ошибок соединений, анализ переповторов (retransmissions), отслеживание состояний соединений (SYN, ESTABLISHED, FIN) и ошибок сетевых устройств.
• Мониторинг UDP: отслеживание операций отправки и получения данных с метриками задержки и пропускной способности.
• Анализ полосы пропускания: мониторинг объема переданных байт для операций TCP/UDP.

2. Мониторинг уровня приложения (Application Layer)
• HTTP и DNS: отслеживание HTTP-запросов/ответов через uprobes и мониторинг DNS-запросов с фиксацией задержек и ошибок.
• Базы данных: трассировка запросов PostgreSQL и MySQL с извлечением паттернов запросов и анализом времени их выполнения.
• TLS/SSL и пулы: мониторинг рукопожатий TLS/SSL, а также отслеживание использования пулов соединений (истощение, повторное использование).

3. Файловая система и системные события
• Операции с файлами: отслеживание операций чтения/записи
• Память: мониторинг ошибок страниц (page faults) и обнаружение завершения процессов из-за нехватки памяти (OOM Kill)
• Системные вызовы (Syscalls): отслеживание жизненного цикла процессов через execve, fork, open и т.д.

4. Производительность системы
• CPU и планировщик: мониторинг блокировок потоков, событий планирования и потребления CPU конкретными процессами.
• Стеки вызовов (Stack Traces): захват стеков вызовов в пользовательском пространстве для медленных операций (I/O, DNS, блокировки CPU), превышающих заданные пороги.
• Конкуренция блокировок: отслеживание ожидания futex и pthread mutex для идентификации «горячих» блокировок.

5. Распределенная трассировка (`Distributed Tracing`)
• Извлечение контекста: автоматическое извлечение данных трассировки из заголовков HTTP/HTTP2 и метаданных gRPC.
• Графы потоков: построение направленных графов взаимодействия сервисов с метриками задержек и ошибок.
• Экспорт данных: поддержка OpenTelemetry (OTLP), Jaeger и Splunk HEC.

6. Диагностика и оповещения
• Режим диагностики (Diagnose Mode): сбор событий за определенный период
• Алерты: Slack, webhook или Splunk
• Интеграция с Prometheus и Grafana

На нашем сайте Luntry в разделе Исследований стали доступны все материалы с вебинара «ИТОГИ 2025»!

В рамках данного вебинары мы:
- Вспомнили о самых значимых и знаковых событиях в развитии Kubernetes;
- Проанализировали громкие уязвимости, атаки и инциденты в контейнерных инфраструктурах;
- Подвели итоги 2025 и заглянули в 2026 год.

В общем, если вы хотите быстро понять каким был этот год в K8s или просто вы были на необитаемом острове целый год и все пропустили, то тут мы все собрали для вас ;)

В статье «A Tour of eBPF in the Linux Kernel: Observability, Security, and Networking» подробно объясняется, что такое eBPF и почему он стал ключевой технологией для современных Linux-систем: eBPF позволяет безопасно выполнять код прямо в ядре без написания модулей, сохраняя высокую производительность и изоляцию. Это радикально меняет подход к наблюдаемости, безопасности и сетям, особенно в облаках и Kubernetes-окружениях.

Автор последовательно разбирает, как устроен eBPF: от компиляции программ в байткод и проверки verifier’ом до JIT-исполнения и привязки к событиям вроде syscalls, tracepoints и сетевых хуков. Отдельное внимание уделено BPF-картам, которые позволяют передавать данные между ядром и user-space и строить сложную логику без заметного overhead.

В практическом плане eBPF уже используется для трейсинга, runtime-безопасности и высокопроизводительного networking’а, часто заменяя iptables, kernel-модули и агентские решения.

Одним из самых частых вопросов на протяжении последних 3-х лет, который мне задавали на моем тренинге, да и вообще на конференциях, после докладов, в кулуарах - это: "А есть отечественные аналоги Talos?"

Этот вопрос и сейчас активно спрашивают, НО теперь на него можно положительно ответить!

Проект ALT Orchestra (исходники) от ребят из Базальта, на базе Talos и в реестре Российского ПО.

О проделанной работе, вкладе в upstream Talos, отличиях, изменениях и планах было рассказано в этом году на KUBER CONF.

Мы очень рассчитываем на то что, это даст положительный толчок нашей индустрии, сигнал для регуляторов, что можно и нужно по другому защищать контейнерные окружения и не мучать всех антивирусами на Node, и вообще повысит уровень безопасности, выбросив модель нарушителя "атакующий на Node" из модели угроз.

Кто-то уже активно использует container specific OS, а кого-то наконец сможет их использовать)

P.S. Также надеемся, что другие отечественные разработчики ОС посмотрят на этот вектор развития своих ОС.

UPD. В комментарии добавлены слайды с KUBER CONF