Всем, привет!

Мы рады официально объявить дату нашей конференции по безопасности контейнеров и контейнерных сред БеКон 2025 и это 3 июня!

Продажа билетов стартанет на следующей неделе ;)

Также напомним, что прием заявок на доклады идет до 31 марта!

Исследователи из CrowdStrike недавно выпустили статью с интересным названием – Improving Kubernetes Security: Lessons from an Istio Configuration Finding. В статье они рассказывают, как атакующий с возможностью создавать Pod с парой определенных аннотаций от Istio и специально заготовленного образа может сбежать из контейнера (без магии в SecurityContext).

Так например, используя аннотацию sidecar.istio.io/proxyimage, можно задать кастомный образ для sidecar контейнера. А аннотация sidecar.istio.io/enableCoreDump добавляет sidecar контейнеру CAP_SYS_ADMIN capability.

Интересно, что команда Istio не признала это как проблему безопасности, сославшись на то, что пользователь с достаточными привилегиями может запустить такой контейнер и сбежать из него независимо от Istio. Хотя этот аргумент верен, создание такого debug контейнера с возможностью выполнения произвольного кода под прикрытием Istio может значительно затруднить его обнаружение в случае реальной атаки, поскольку sidecar контейнер Istio будет выглядеть гораздо более легитимным, чем неучтенный «обычный» привилегированный контейнер.

Данную ситуацию можно контролировать с помощью Policy Engine, на пример, Kyverno, но и тут надо очень внимательно писать политику. Стандартное контролирование YAML ресурса Pod в разделе Security Context не поможет. Так что как всегда Policy Engine must have!

Однако, после обращения ресерчеров из CrowdStrike, команда Istio немедленно открыла PR, чтобы удалить функциональность четырехлетней давности. 7 октября PR был принят.

14 марта наша команда Luntry выступит на митапе CyberCamp, который в этот раз посвящён сфере Digital Forensics & Incident Response, с темой «Форензика для контейнеров и контейнерных инфраструктур».

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

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

Зарегистрироваться на митап можно по ссылке.

На конференции SCaLE 22x был представлен доклад "Many Ways of Building Containers: From Manual to Transparently Built On-Demand Containers" (слайды).

Из него можно узнать как в ручную (hard way) собрать образ контейнера!
Далее с помощью утилит: Buildpacks, NixPacks, Nixery, Kontain.me, MinToolkit.
И еще автор задается вопросом "Как собрать контейнер, который грузится быстро." и дает на него ответ, где речь идет про lazy loads, eStargz.

Недавно мы рассказывали как нужно смотреть CISO (и другим на С-level уровне) на безопасность контейнеров и Kubernetes. А теперь 25 марта мы расскажем это с ориентиром на специалистов SOC (Security Operation Center). Это будет полезно как внутренним, так и внешним SOC.

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

Проект Cyphernetes - это новый язык запросов для Kubernetes. С примерами запросов можно ознакомиться тут. В данном языке работа с ресурсами k8s идет как с графом. У проекта есть как CLI утилита (дает работать через web UI, REPL и просто запросом), так и operator.

После этого наверно можно сказать, что у Kubernetes уже есть все свое, включая язык запросов =)

Новый режим nftables для kube-proxy был представлен в качестве альфа-функции в Kubernetes 1.29. В настоящее время он находится в бета-версии, но в версии 1.33 (выйдет в конце апреля) ожидается появление в GA. Новый режим устраняет давние проблемы с производительностью режима iptables, и всем пользователям, работающим на системах с достаточно свежими ядрами, рекомендуется опробовать его.

Более подробно про сравнение и бенчмарки со старым режимом можно почитать в статье NFTables mode for kube-proxy.

Команда kubectl cordon одна из важнейших и одна из самых первых команд, которую нужно использовать в случае обнаружения security инцидента в контейнере на Node.

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

P.S. Если тема интересна, то в эту пятницу мы представим доклад «Форензика для контейнеров и контейнерных инфраструктур».

Очередная unpatchable CVE в Kubernetes – CVE-2025-1767: GitRepo Volume Inadvertent Local Repository Access.

Уязвимость позволяет пользователям с правами на создание Pods использовать gitRepo Volumes для доступа к локальным git-репозиториям, принадлежащим другим Pod'ам на той же Node. Поскольку функциональность in-tree gitRepo Volumes была признана deprecated и не будет получать обновления безопасности, все кластеры, использующие эту функцию, остаются уязвимыми. Тем не менее уязвимость получила оценку 6.5 по CVSS.

В качестве меры митигации предлагается использовать init контейнер для выполнения операции git clone, а затем смонтировать каталог в основной контейнер:

apiVersion: v1
kind: Pod
metadata:
  name: git-repo-demo
spec:
  initContainers:
    - name: git-clone
      image: alpine/git
      args:
        - clone
        - --single-branch
        - --
        - https://github.com/kubernetes/kubernetes
        - /repo
      volumeMounts:
        - name: git-repo
          mountPath: /repo
  containers:
    - name:  busybox
      image: busybox
      args: ['sleep', '100000']
      volumeMounts:
        - name: git-repo
          mountPath: /repo
  volumes:
    - name: git-repo
      emptyDir: {}

Мы запустили продажу билетов на БеКон 2025! Успейте взять билет по ранней цене.

P.S. Напоминаем про промокоды на скидку на бейджах прошлого года ;)

Будущая версия containerd 2.1 еще на шаг приблизит возможность в Kubernetes делать live миграцию сервисов! Изучите данный тикет "Support container restore through CRI/Kubernetes #10365" - там много всего интересного с исторической репрезентацией данного вопроса. При этом есть и параллели с Podman и CRI-O, в которых эта фича тоже есть.

С точки зрения ИБ напомним, что это упростить процесс форензики в контейнерах нативными средствами контейнеров.

Возвращаясь к CVE-2025-1767, о которой мы рассказывали в прошлую пятницу, нельзя не упомянуть о довольно простой эксплуатации этой баги:

apiVersion: v1
kind: Pod
metadata:
  name: git-repo-pod-test
spec:
  containers:
  - name: git-repo-test-container
    image: raesene/alpine-containertools
    volumeMounts:
    - name: git-volume
      mountPath: /tmp
  volumes:
  - name: git-volume
    gitRepo:
      repository: "/TestingScripts"
      directory: "."

Про это подробно Rory McCune рассказал в свой статье CVE-2025-1767 - Another gitrepo issue.

Кстати говоря, после выхода CVE-2025-1767 активизировались обсуждения насчет выпиливания gitRepo Volume как фичи с версии Kubernetes 1.33 по умолчанию. И как итог, в рамках KEP-5040, gitRepo Volume driver был удален. Более подробно обсуждения можно почитать тут и тут.

Этот кейс еще раз показывает важность использования Policy Engine механизмов.

Вернемся к непопулярной у нас теме (но при этом достаточной интересной) - Windows containers и поможет нам в этом статья "How do COWs (Containers on Windows) work?" с хорошей визуализацией и сравнением с Linux containers.

При этом отдельно хочется отметить что аналогичный runc компонент в Windows под названием hcsshim (Host Compute Service Shim) доступен в исходниках и изучить его можно тут.

Сегодня вернемся к атакующей тематике, а именно – Mark Manning представил крутейший доклад Command and KubeCTL: Kubernetes Security for Pentesters and Defenders на прошедшей вчера конференции B-Sides Reykjavik 2025.

В докладе он рассмотрел Real World Scenario – начиная с компрометации среды сборки и заканчивая эксфильтрацией секретов в продакшн кластере Kubernetes.

Также нельзя упомянуть о модификациях некоторых ранее известных инструментов, которые автор сделал специально для доклада:

1) В go-pillage-registries добавлен bruteforce имен образов для выкачивания их из regsitry, а также добавлена интеграция с trufflehog для поиска чувствительных данных внутри образов.
2) В backdoored-vault (форк Vault) добавлена DNS эксфильтрация секретов

Со слайдами можно ознакомиться тут.

Конкурс!

7 и 8 апреля в Москве пройдет DevOpsConf 2025! Там как всегда будем много интересного по теме контейнеров, Kubernetes и безопасности этих технологий.

Мы разыгрываем:
- 1 офлайн билет
- 2 онлайн билета

И так, Kubernetes очень активно развивается и с каждой новой версией там появляется все больше новых возможностей! Это легко можно увидеть, на пример, в проекте Kaniuse, который является Kubernetes Feature Status Tracker.

Для того чтобы выиграть один из призов в комментариях к данному посту напиши какую вы фичу ждете и почему, описав конкретную вашу боль. Эта фича как уже может иметь какой-то KEP, так и полностью придумана вами. Чем подробнее вы опишите тем больше шансов выиграть.

Варианты принимаем до 27 марта.

P.S. Наша команда будет на конференции и мы с радостью пообщаемся в офлайн.

P.S.S. Промокод на скидку в 5% при покупке билета dc25_k8security ;)

Grant - инструмент (от создателей Syft и Grype) для работы с лицензиями для образов контейнеров, SBOM, файловых систем и применения правил для построения отчетов соответствия лицензионным политикам/требованиям.

Пример правила:

pattern: "*gpl*"
name: "deny-gpl"
mode: "deny"
reason: "GPL licenses are not allowed"
exceptions:
  - "alpine-base-layout" # We don't link against this package so we don't care about its license

Сегодня нашему каналу k8s (in)security исполняется 5 лет !!!

Мы всей нашей командой Luntry стараемся держать уровень и радовать вас новыми интересными материалами и мыслями про безопасность контейнеров и Kubernetes!

Не так давно мы пересекли рубеж в 10 000 подписчиков и продолжаем уверенно расти благодаря вам и формировать отличное сообщество. Вместе с вами в этом году мы уже проведем 3 специализированную конференцию БеКон!

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

P.S. А для меня это всегда двойной праздник, так как День рождение и у моего сынишки, который на 1 год младше данного канала)

На нашем сайте в разделе Исследований стали доступны слайды и видеозапись выступления "Форензика для контейнеров и контейнерных инфраструктур" c CyberCamp 2025.

И если вам эта тема интересна и близка, то напоминаем что уже завтра 25 марта в 11:00 состоятся вебинар "Безопасность контейнеров и Kubernetes для SOC". Зарегистрироваться можно тут.

В Kubernetes раскрыта очередная уязвимость – CVE-2024-7598: Network restriction bypass via race condition during namespace termination.

Наверняка вы замечали, что некоторые ресурсы могут висеть в статусе terminated при удалении namespace целиком. Так вот порядок удаления ресурсов при таком namespace termination не определен, и это может привести к тому, что в какой-то момент времени Pods будут всё ещё работать, а Network Policy уже не будет существовать и применяться к Pods. Такое удаление ресурсов вызывает состояние гонки, которое в свою очередь даёт возможность обойти сетевые ограничения, наложенные Network Policy.

Аналогично совсем недавно раскрытой CVE-2025-1767 исправлений для текущих версий нет. Однако, очередность удаления ресурсов уже реализована в рамках KEP 5080 и будет завезена в статусе alpha в 1.33.

В качестве мер митигации предлагается вручную удалять Workloads перед удалением Namespace. Также предлагается использовать Network Policy Finalizer.

Уязвимость затрагивает Kubernetes кластера >= v1.3 версии и имеет оценку Low (3.1) по CVSS.

Исследователи из WIZ плотно взялись за ресерч очередного продукта, на этот раз – ingress-nginx controller. В результате было раскрыто 5 уязвимостей, одна из которых имеет severity critical.

Что интересно, в отличии от прошлых CVE, что находили в контроллере, для эксплуатации этих уязвимостей (не всех) не нужно создавать ресурс Ingress. Атакующему необходимо отправлять вредносные запросы через admission review напрямую в admission controller.

Максимальный импакт может нанести атакующий, находящийся внутри сети Kubernetes. И тут на помощь в очередной раз приходит Network Policy! Не устаем напоминать насколько это must have механизм.

Несмотря на то, что исследователи довольно подробно описали технические детали для эксплуатации уязвимостей реального эксполйта они не опубликовали. Однако PoC уже доступны на GitHub.

Забавно, что для уязвимости с максимальной критичностью 9.8 по CVSS для фикса просто закомментировали уязвимый функционал:

/* Deactivated to mitigate CVE-2025-1974
// TODO: Implement sandboxing so this test can be done safely

Сегодня наша команда Luntry в рамках конференции Deckhouse Conf 2025 представит доклад "Стандарт безопасности контейнеров NIST 800-190 в 2025 году".

В процессе подготовки выступления были проанализированы документы NIST серии SP 800, связанные так или иначе с микросервисами, контейнерами, облаками и Cloud Native технологиями в общем.

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