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

Zot — это проект CNCF, представляющий собой OCI-native реестр образов контейнеров. Он поставляется в виде одного бинарного файла, работает без привилегий и поддерживает разные платформы. Решение включает встроенную безопасность (подписи, сканер уязвимостей), дедупликацию и аутентификацию.

И все это в 1 бинаре!

На канале мы не раз рассказывали про проект Kata Containers, позволяющий запускать контейнеры в виде легковесных вирутальных машин, что в целом повышает уровень изоляции. Несмотря на это, критичные уязвимости в таких проектах тоже встречаются и CVE-2026-24054 тому подтверждение.

Уязвимость CVE-2026-24054 в Kata Containers (High, CVSS 8.8) позволяет при использовании повреждённого или пустого контейнерного образа некорректно смонтировать rootfs, из-за чего хостовый блочный девайс может быть «подключён» внутрь VM. Это происходит из-за fallback поведения containerd и ошибки в обработке bind-mount, из-за которой runtime принимает директорию за блочное устройство. В итоге возможно повреждение файловой системы хоста и перевод его диска в режим read-only.

Атака может вызывать двойное выделение inode и другие ошибки на уровне файловой системы, что приводит к отказу в обслуживании и риску нарушения целостности системы. Уязвимость затрагивает все версии Kata Containers до 3.26.0.

Буквально, для того чтобы сложить целую Node, нужно задеплоить контейнер на базе образа из такого однострочного Dockerfile:

FROM scratch

16 февраля 2026 в 11.00 наша команда Luntry совместно с командой платформы управления средами контейнерной оркестрации «Штурвал» проведет вебинар "Синергия безопасности Luntry и Штурвал. Часть 2"!

Luntry и Штурвал вместе создают сквозной контур безопасности для Kubernetes, который не только обнаруживает уязвимости, но и предоставляет инструменты для их оперативного устранения и даже предотвращения.

В рамках второй части мы коснёмся 2 областей:
- Контроль Kubernetes кластеров;
- Безопасность образов контейнеров.

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

P.S. Материалы с первой части можно посмотреть тут.

Из статьи "Breaking eBPF Security: How Kernel Rootkits Blind Observability Tools" можно узнать как вредоносный код на уровне ядра может ослеплять/обходить средства защиты на базе eBPF. Сам этот факт вообще не является никаким откровением. Ценность статьи в реальном разборе и демонстрации с примерами кода. Автор глубоко погружается в такие аспекты как: BPF iterators, ringbuffers и perf events.

Основной вывод: "If an attacker gains the ability to load kernel modules, they control the kernel’s view of reality. eBPF security tools run inside the kernel and thus cannot fully protect a compromised kernel. The only reliable defense is preventing kernel compromise in the first place."

По сути получаем работу в недоваренном окружение и как следствие мы уже не можем доверять информации от этой системы.

Недавно на канале мы рассказывали про статью "Kubernetes Remote Code Execution Via Nodes/Proxy GET Permission", в которой исследователь показывает как получить RCE с помощью права на чтения GET (без CREATE).

Сегодня хотим поделиться способом, как можно закрыть этот мисконфиг, используя Istio.

В репозитории nodes-proxy-get-rce-fix предлагается использовать EnvoyFilter, ServiceEntry и DestinationRule для блокировки WebSocket соединения к kubelet на порт 10250.

Вышло очередное обновление фреймворка Jet Container Security Framework (JCSF) от наших друзей.

Если вы не знаете, что это, для чего это и как с этим работать, то мы еще в феврале прошлого года проводили совместный вебинар "Фреймворк безопасности контейнеров JCSF" (слайды, видео), где это все обсуждали и обсуждали как его можно улучшить и поправить.