Сегодня нам бы хотелось поделиться с вами интересным докладом с интригующим названием специалиста Google - "Why Perfect Compliance Is the Enemy of Good Kubernetes Security" (видео) c KubeCon + CloudNativeCon North America 2024. Самый полезный на наш взгляд слайд мы вынесли в картинку поста ;)

Способу побега из контейнера, о котором мы рассказывали в июле этого года, только на днях присвоили идентификатор CVE – CVE-2024-10220. Почему это произошло только сейчас, учитывая полный дисклоуз уязвимости, остаётся под вопросом.

Тем не менее, злоумышленник, используя deprecated gitRepo volume может совершить из контейнера, при соблюдении трёх условий – поддержка gitRepo volume type, наличие git бинаря на Node и отсутствие ограничений на использование gitRepo volume type.

Уязвимость аффектит следующие версии:

- kubelet v1.30.0 to v1.30.2
- kubelet v1.29.0 to v1.29.6
- kubelet <= v1.28.11

Фиксы доступны в:

- kubelet v1.31.0
- kubelet v1.30.3
- kubelet v1.29.7
- kubelet v1.28.12

Мысли/идеи о том что Virtual Desktop Infrastructure (VDI) можно сделать на базе классических/нативных контейнеров в Kubernetes все чаще мелькают на просторах сети и статья "How I came to build a cheap server cluster for VDI" еще одно подтверждение этому. Ранее мы писали о проекте kVDI, потом находили проект webmesh-vdi.

В рамках данной работы получился проект VM-Operator (написан на Java), где Qemu-based виртуальные машины (не классическая контейнеризация и так давно можно с помощью KubeVirt, но все же ) запускаются в Kubernetes Pods.

Мы абсолютно уверенны, что когда-нибудь и защита специализированных клиентский рабочих мест сведется к защите контейнеров ;)

Сегодняшний пост будет актуален для тех, кто использует у себя OpenShift. А, именно – была раскрыта CVE-2024-6538, позволяющая авторизированному пользователю эксплуатировать SSRF.

Бага была обнаружена в компоненте OpenShift console. Для её эксплуатации достаточно отправить следующий POST запрос:

POST /api/dev-console/proxy/internet

При этом, мы имеем Full Read SSRF, а значит получим полный ответ со всеми заголовками. Используя такой вектор атаки, злоумышленник может повлиять на другие сервисы, работающие внутри кластера и потенциально раскрыть информацию или оказать другое вредоносное воздействие на систему.

10 декабря в 11:00 наша команда Luntry проведет вебинар/стрим/эфир «Подпись и валидация образов в Kubernetes». Там мы планируем рассмотреть следующие темы:

– подготовка инфраструктуры для подписи и валидации образов;
– написание pipeline сборки для данного процесса;
– встраивание cosign в pipeline сборки;
– использование политик Kyverno и OPA Gatekeeper для валидации образов;
– возможности Luntry для контроля данного аспекта в инфраструктуре.

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

P.S. Так как это у нас полный live, то тут в комментариях можно написать ваши пожелания/вопросы, которые вы бы хотели увидеть в рамках данного эфира, чтобы мы максимально широко раскрыли данную тему.

kondense - это проект на Go выполненный в виде sidecar контейнера, который помогает автоматически управлять ресурсами контейнеров в Kubernetes без их перезапуска. На пример, освобождать не используемое количество выделенной контейнеру memory и CPU. Для этого используется не так давно появившееся фича InPlacePodVerticalScaling.

Многим такое полезно, но в данной реализации как по нам все омрачается правами ServiceAccount, которыми должен владеть Pod - это: "get", "list", "watch", "patch" на "pod" и (самое печальное) "create" на "pods/exec" (тут исходник, объясняющий зачем это)... С учетом этого также получается, что все сервисы теперь должны в своих NetworkPolicy иметь доступ к Kubernetes API.

Хоть проект и полезный, но с учетом вопросов ИБ к нему врят ли его можно рекомендовать. Явно нужно ждать другой реализации. Но сам факт появление подобных проектов вокруг фичи InPlacePodVerticalScaling это отлично.

Опубликовали очередную багу в Cilium – CVE-2024-52529. И в очередной раз бага связана с тем, что CiliumNetworkPolicy не работают так как должны (тут мы рассказывали про подобный баг).

Проблема возникает когда есть L3 политика с выставленным port range и L7 политика с портом из диапазона первой политики. В таком случае L7 CiliumNetworkPolicy работать не будет. Например:

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: "l3-port-range-rule"
spec:
  endpointSelector:
    matchLabels:
      app: service
  ingress:
    - fromCIDR:
      - 192.168.60.0/24
      toPorts:
      - ports:
        - port: "80"
          endPort: 444
          protocol: TCP

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: "l7-port-range-rule"
spec:
  endpointSelector:
    matchLabels:
      app: service
  ingress:
    toPorts:
    - ports:
      - port: "80"
        protocol: TCP
      rules:
        http:
        - method: "GET"
          path: "/public"

В приведенном выше примере будут разрешены запросы ко всем HTTP path, а не только GET-запросы к пути /public, как это предусмотрено политикой l7-port-range-rule.

На нашем сайте в разделе исследований стали доступны слайды и видеозапись доклада "Безопасность от виртуальных машин до контейнеров и обратно" с конференции Industrial++ 2024.

Доклад для тех кто только погружается в тему и хочет понять в чем тут вообще разница)

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

Проект zeropod позволяет скалировать Pod в 0.

Zeropod — это Kubernetes runtime (точнее, containerd shim), который автоматически сохраняет контейнеры на диске после определенного времени последнего TCP-подключения. В таком состоянии (scales down to zero) он будет прослушивать тот же порт, который прослушивало приложение внутри контейнера, и восстановит этот контейнер при первом входящем подключении. В зависимости от размера программы с контрольной точкой это происходит за десятки или несколько сотен миллисекунд, практически незаметно для пользователя. Поскольку все содержимое памяти сохраняется на диске во время создания контрольной точки, восстанавливается все состояние приложения.

Для работы понадобиться установить данный runtime на Nodes, указать для соответствующих приложений runtimeClassName: zeropod, а затем уже проект CRIU (уже неоднократно о нем писали на канале 1,2,3,4,5), который находится под капотом сделает свое дело. На схеме можно увидеть процесс активации контейнера после того как он был checkpointed и к нему снова пошли сетевые обращения.

Начинаем эту неделю с eBPF тематики, а точнее со свежего документа "A Security Threat Model for eBPF" от eBPF Foundation. Этот документ будет полезен для тех, кто рассматривает внедрение технологии eBPF в своих системах, чтобы понимать связанные с этим риски и способы их снижения.

Отдельно хотим отметить раздел "Detailed Threats and Controls". Очевидно, что там отражены не все возможные угрозы, многие из них обобщены, описаны необходимые меры для митигации рисков.

Если вам мало CRI,CNI,CSI,CDI,CMI,CPI, то встречайте еще один интерфейс в Kubernetes под названием NRI.

NRI - это Node Resource Interface. По сути это механизм плагинов, позволяющий расширять возможности containerd с 1.7 и CRI-O c 1.26. Можно добавить собственную логику, которая будет выполняться в такие моменты жизни Pods как run, stop, remove и контейнеров как creation, post-creation, starting, post-start, updating, post-update, stopping, removal.

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

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

P.S. В процессе изучения данной темы был найден интересный показательный проект Koordinator (QoS-based scheduling), на котором можно проследить эволюцию подходов к управлению ресурсами в K8s.

Среди инструментов (коих немного) упрощающих процесс проведения пентеста контейнерных окружений очередное пополнение – Am I Isolated.

В целом, ничего нового, очень похоже на уже давно имеющиеся botb и amicontained. Из плюсов – написан на Rust и активно развивается.

Сейчас, например, в нём есть проверки на:

- возможность эксплуатации опасных capabilities
- возможность эксплуатации namespaces
- наличие проброшенного containerd/docker socket
- определение использования microVM
- поиск участков памяти для RWX

Недавно копаясь и разбираясь с различными container runtimes, данное действие привело к проекту на Go под названием runj.

runj - это экспериментальный OCI-совместимый runtime для FreeBSD jails! Лично для меня это можно сказать завершение определённого цикла. Ведь механизм FreeBSD jails появился в 2000 году, а это за 13 лет до появления Docker, 15 лет до Kubernetes и 17 лет до OCI спецификация v1.0.0 для образов контейнеров. И тут можно сказать, что один из прародителей концепции контейнеров встретился со своим потомком =)

В начале декабря вышла новая версия Calico – 3.29 и в ней есть достаточно много мажорных изменений:

1) nftables dataplane. nftables использует новую реализацию nftables-based kube-proxy (представленную в Kubernetes 1.31) и обеспечивает совместимость с новыми функциями ядра, а также использует преимущества улучшенной безопасности, заложенные в новые функции ядра.

2) Tiered Network Policies. Новый ресурс в OpenSource версии Calico, позволяет группировать политики и выстраивать их приоритеты. Более подробно об этом можно почитать тут.

3) AdminNetworkPolicy support. Теперь Calico поддерживает AdminNetworkPolicy, которую должны добавить в следующих релизах. Об этом ресурсе мы рассказывали ранее на канале.

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

Если вы, например, думали что спецификация runtime зафиксирована и не изменяется, то вы ошибаетесь. Вот тут в changelog для Open Container Initiative Runtime Specification можно посмотреть как они тихо, без громких анонсов уже доросли с версии 1.0 до 1.2.

P.S. Напоминаем, что завтра в 11:00 наша команда Luntry проведет вебинар/стрим/эфир «Подпись и валидация образов в Kubernetes».

11 и 12 декабря команда Luntry участвует в открытой конференции ИСП РАН в Москве.

В 2024 г. конференция посвящена 30-летию ИСП РАН, который был основан крупным советским и российским учёным В.П. Иванниковым. Участниками конференции станут эксперты отечественных и зарубежных научных и образовательных организаций, представители ведущих ИТ-компаний и государственных ведомств.

Мероприятие пройдет в Москве, в инновационном кластере «Ломоносов». Зарегистрироваться на мероприятие и ознакомиться с программой можно по ссылке.

Релиз Kubernetes 1.32 уже не за горами (на этой неделе), все изменения внесены, а это значит что можно посмотреть, что нового, с точки зрения security, нас ждёт в версии 1.32.

Наверное, одно из самых заметных изменений это добавление Feature Gate KubeletFineGrainedAuthz, благодаря которому доступ до эндпоинтов /health и получению списка Pods на конкретной Nodes будет разрешен соответствующими правами RBAC nodes/healthz и nodes/pods.

Также внесли ряд улучшений в Kubernetes Audit Policy, а вернее в логи, которые отставляет после себя этот механизм.

Нельзя не отметить изменения в Authentication и Token Management – добавлен JTI claim, и другая дополнительная информация к Service Account Token, AnonymousAuthConfigurableEndpoints перешел в beta и теперь включен по умолчанию.

В следующих постах обязательно рассмотрим эти улучшения по подробнее.

Прием заявок на доклады на БеКон 2025!

Если мы на предыдущие конференции только приглашали докладчиков из наших клиентов, друзей и партнеров, на конкретные темы, то сейчас появляется возможность предложить свою тему самостоятельно ;)

Требования к заявке:
- Продолжительность доклада — не более 25 минут
- Тема по безопасности контейнеров и Kubernetes
- Выступление рассчитано на технических специалистов
- Доклад актуален и основан на личном опыте
- Доклад ранее нигде не был представлен
- Доклад глубоко раскрывает тему и имеет практическое применение

P.S. Анонс сделали сильно заранее, чтобы было достаточно времени продумать и подготовить тему!

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

В качестве online платформы IMHO безусловным лидером является iximiuz Labs!