Уже завтра состоится наш вебинар «Безопасность контейнеров и Kubernetes для CISO» и мы настоятельно рекомендуем перед ним ознакомиться (или освежить в памяти) выступление "Почему защитой k8s должно заниматься целое подразделение?" (слайды, видео) от Артем Мерец (Т-Банк) с прошлогодней конференции БеКон 2024. Будет достаточно пересечений и отсылок к нему, и вообще полезно посмотреть на то как к данному вопросу подходят другие компании.

P.S. Прием заявок на доклады БеКон 2025 еще идет.

Если вы любитель внимательно почитать release notes, то прочитав их к последнему релизу Docker 28, наверняка ваше внимание зацепили следующие изменения:

Fix a security issue that was allowing remote hosts to connect directly to a container on its published ports. moby/moby#49325
Fix a security issue that was allowing neighbor hosts to connect to ports mapped on a loopback address. moby/moby#49325

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

Если посмотреть комментарии к pull request, можно увидеть что мейнтейнеры пока еще не опубликовали CVE. Также готовится заметка в блог Docker о том как эта уязвимость может повлиять на конечных пользователей.

Наши друзья зарезили проект для графической генерации AuditPolicy для Kubernetes! Проект находиться в стадии beta, но с ним уже можно ознакомиться тут. Подробнее ребята писали о проекте тут.

При этом хочется напомнить о замечательном докладе Алисы Кириченко (один из авторов данного проекта) "Вы еще не читаете Kubernetes Audit Log? Тогда мы идем к вам!" (слайды, видео) с прошлой конференции БеКон 2024.

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

25 февраля 2025 года рабочая группа SIG Security Kubernetes опубликовала документ под названием “Shift Down Security”. Цель этого документа — помочь организациям использовать лучшие практики безопасности в облачных средах для снижения бизнес-рисков и повышения продуктивности разработчиков.

В нем описывается, как платформенные команды могут внедрять технологии, такие как “Policy as Code”, для предотвращения неправильных конфигураций и автоматизации вопросов безопасности во всех приложениях.

Подход “Shift Down Security” предлагает интегрировать функции безопасности непосредственно в платформу Kubernetes, что позволяет улучшить защиту и предоставить разработчикам больше возможностей для самостоятельной работы.

Вчера готовясь к одному закрытому мероприятию, подбивал разные наши данные по результатам наших аудитов/пентестов контейнерных сред под управлением Kubernetes (за другие мы и не беремся) и можно констатировать следующие:
1) В 95% проектах мы получали в итоге права роли Cluster Admin - анализом и контролем RBAC занимается мало кто, в итоге выливается в это.
2) Использование эксплоитов для конкретных CVE составляет всего около 5% от всех наших находок - почти все это было для побега из контейнера через уязвимый системный компонент/сервис.
3) Абсолютное большинство успешных атакующих действий было через специально подготовленный YAML - тут не удивительно, k8s система декларативная и все крутиться вокруг них и с помощью правильных политик на Policy Engine это можно было бы предотвратить.
4) Много специфичных, уникальных кейсов - тут тоже не удивительно, все k8s кластера непохожие друг на друга, все готовят их под свои задачи, специфику и т.д.

Всем хороших выходных!

Наверняка многие знают, что с docker socket можно достаточно легко взаимодействовать при помощи curl, даже когда в контейнере нет подходящих инструментов или возможности докачать их извне:

$ curl -s --unix-socket /var/run/docker.sock http:/containers/json

Но также легко это делать, если мы имеем дело с containerd socket ?

Для начала мы можем докачать или воспользоваться имеющимся инструментами типа ctr или crictl:

$ sudo ctr --address /var/run/containerd/containerd.sock -n k8s.io containers list
CONTAINER                                                           IMAGE                                                                   RUNTIME
01a91532d97f8f7162c477dd1e402520d313e9c4333827d74a93cde25dddc1cc    registry.k8s.io/pause:3.6                                               io.containerd.runc.v2
05536e2ec91d018cdb4edac21ab613b22f0755721e082c99f81b87516bce60ec    registry.k8s.io/pause:3.6                                               io.containerd.runc.v2
0894b4942001821ad9c36949ae7c15fc2dd9b54bf6e5d531b6e5b03e6f5e313c    docker.io/calico/cni:v3.25.0                                            io.containerd.runc.v2

Если их нет, то можно также отправить запрос с помощью curl, правда это будет несколько сложнее:

$ echo -ne "\x00\x00\x00\x00\x00" | sudo curl -v -s --http2-prior-knowledge --unix-socket /run/containerd/containerd.sock -X POST  -H "content-type: application/grpc" -H "te: trailers"  -H "grpc-accept-encoding: gzip" http://localhost/containerd.services.version.v1.Version/Version --data-binary @- --output /tmp/versionresponse.bin
*   Trying /run/containerd/containerd.sock:0...
* Connected to localhost (/run/containerd/containerd.sock) port 80 (#0)
* Using HTTP2, server supports multiplexing
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x55c22b6bdec0)
> POST /containerd.services.version.v1.Version/Version HTTP/2
> Host: localhost
> user-agent: curl/7.81.0
> accept: */*
> content-type: application/grpc
> te: trailers
> grpc-accept-encoding: gzip
> content-length: 5
>
} [5 bytes data]
* We are completely uploaded and fine
* Connection state changed (MAX_CONCURRENT_STREAMS == 4294967295)!
< HTTP/2 200
< content-type: application/grpc
<
{ [55 bytes data]
< grpc-status: 0
< grpc-message:
* Connection #0 to host localhost left intact

Об этом и не только Stephen Bradshaw рассказал в своём блоге, в одноименных заметках containerd socket exploitation в трёх частях (1, 2, 3).

Сегодня в центре нашего внимания документ "SoK: A Comprehensive Analysis and Evaluation of Docker Container Attack and Defense Mechanisms" (github).

В данной работе авторы пытаются систематизировать атаки на контейнеры и механизмы их защиты.

Атаки:
1) Execute Arbitrary Code
2) Gain Privilege
3) Disclose Credential Information
4) Authentication Bypass
5) Denial Of Service

Защитные техники:
1) Static Scanning - тут сканы на уязвимости образов
2) Image Hardening - тут уменьшение поверхности атаки, убирая все лишнее
3) Security Policies and Practices - тут отсутствие запуска от root, флага privileged, использование AppArmor и Seccomp профилей
4) Dynamic Anomaly Detection - обучение и обнаружение аномалий

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

Послевкусие после изучения материала странное - вроде и много что упомянули, но при этом есть что еще добавить и в атаках и в защитах ...

Исследователь Graham Helton опубликовал ресурс yProbe – Kubernetes YAML Manifest Sanity Checker.

Онлайн сервис может проверять загружаемые в него YAML манифесты с Workloads на Pod Security Standard, а также проверять избыточные RBAC привилегии в Role или Cluster Role.

По сути, yProbe представляет из себя ничто иное как супер обрезанную версию Policy Engine в режиме Audit и с красивой визуализацией.

Также автор выложил исходный код сервиса на Github.

Стали доступны материалы с нашего вебинара "Безопасность контейнеров и Kubernetes для CISO" запись (ВК,YouTube) и слайды (тут). Приятного просмотра!

P.S. Скоро объявим даты нашего следующего вебинара "Безопасность контейнеров и Kubernetes для SOC".

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

Мы рады официально объявить дату нашей конференции по безопасности контейнеров и контейнерных сред БеКон 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, в которых эта фича тоже есть.

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