k8s (in)security

В первый рабочий день в этом году хотим поделиться с вами полезной статьёй от Chainguard про ingress-nginx. Мы уже говорили в одном из прошлых постов, что проект ingress-nginx движется к завершению жизненного цикла и фактически будет архивирован в 2026 году.

В статье подробно объясняется, почему это проблема для продакшена: без поддержки и security-патчей ingress-nginx со временем станет уязвимым и рискованным компонентом инфраструктуры. При этом ingress-nginx всё ещё используется в огромном количестве Kubernetes кластеров по всему миру.

Chainguard решила временно «поддержать жизнь» проекта через программу EmeritOSS — выпуская обновления безопасности, чтобы дать командам время спокойно спланировать миграцию. Хороший повод проверить, что у вас с ingress-nginx сейчас, и начать готовиться к переходу на альтернативы.

С форком можно ознакомиться тут.

Команда нашего канала и вся команда Luntry хочет поздравить всех вас с наступающим Новым Годом!

В кругу близких и родных за вкусным и аппетитным столом вы получение личные поздравления, а у нас на канале профессиональные ;)

Желаем вам строить и развивать свои безопасные инфраструктуры на базе контейнеров и Kubernetes не по остаточному принципу, а как по одному из основополагающих факторов!

Желаем вам заниматься интересными, креативными задачами, а не муторными, монотонными прописанными в уставе, устаревшим еще в момент его написания.

Желаем вам получать от работы удовольствия и развития!

Мы же со свой стороны как всегда готовы вас радовать интересной, полезной информацией, крутыми фичами в Luntry и всегда помогать по любым вопросам, двигая нашу индустрию вперед!

Подведем итоги года данного канала в цифрах.

Большое спасибо всем читателям, всему сообществу за вашу активность!

P.S. Цифры прошлых лет можно посмотреть тут: 2022, 2023, 2024.

Последним техническим постом в этoм году мы хотели бы рассказать про статью "A Safer Container Ecosystem with Docker: Free Docker Hardened Images".

По сути это аналог chainguard images, но от ребят из Docker: минималистичный, обновляемый и с аттестационной информацией (SBOM,VEX,SLSA).

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

Подробнее можно узнать из документации.

Начинаем эту неделю с небольшой фишки, которая будет полезна при проведении пентеста Kubernetes в связке с Vault.

Если у вас есть RBAC права на CREATE на ValidatingWebhookConfiguration, вы можете развернуть webhook, который будет незаметно сливать чувствительные данные — такие как secrets, configmaps и т.п. — на ваш веб-сервер.

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

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

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

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

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

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

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

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

В статье «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-модули и агентские решения.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В начале ноября было раскрыто 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.

songbird - простенький CLI инструмент, упрощающий жизнь и работу с NetworkPolicy (к сожалению, только нативными). А именно данный инструмент позволяет:
1) Проверять достижимость между Pods или к конкретному адресу через анализ NetworkPolicy. То есть помогает ответить на вопрос "а они вообще могут общаться друг с другом или нет?"
2) Сгенерировать NetworkPolicy для общения между двумя сервисами
3) Отобразить все сетевые политики, которые влияют на выбранный Pod

P.S. Определенно ряд мыслей мы подсмотрим для Luntry, расширив поддержкой Calico и Cilium ;)

17 декабря 2025 в 11.00 наша команда Luntry проведет последний вебинар в этом году, посвящённый итогам 2025 года в области Kubernetes и его безопасности.

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

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

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

P.S. Новогоднее настроение гарантируем!

Стали доступны презентации с прошедшей на прошлой неделе конференции Black Hat Europe 2025.

Так, например, стало возможно ознакомиться с докладом, который мы упомянали на канале – Breaking AI Inference Systems: Lessons From Pwn2Own Berlin. Авторы подробно рассказывают о своем подходе к фаззингу, а также какие баги им удалось найти в AI стеке, который часто живет в контейнерах.

Слайды доступны по ссылке тут.

k8s (in)security pinned a photo