k8s (in)security

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

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

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

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

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

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

Опубликовали очередную багу в 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.

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

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

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

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

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

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

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

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

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

POST /api/dev-console/proxy/internet

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

Мысли/идеи о том что 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.

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

Способу побега из контейнера, о котором мы рассказывали в июле этого года, только на днях присвоили идентификатор 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

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

Очередной прошедший KubeCon в первую очередь ассоциируется с обновлением ряда инструментов для Kubernetes и Container. В их числе containerd, он релизнулся в версии 2.0 (о чем мы вкратце написали в одном из предыдущих постов).

В неплохой обзорной статье Samuel Karp рассказывает об основных изменениях в новой версии:

- NRI enabled by default
- Image verifier plugins
- Удаление устаревшего и избыточного кода

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

По части security ломающих изменений хочется отметить – io_uring_* syscalls are disallowed by default. Более подробно мы рассказывали про это здесь.

В начале октября в рамках AM Life Plus наша команда Luntry в лице Дмитрия Евдокимова выступила с темой "Как контейнеры и Kubernetes меняют ландшафт угроз" в стиле TEDx. Где очень кратенько (всего 8 мин), без слайдов постаралась порассуждать на тему являются ли контейнерные технологии с оркестраторами новой головной болью для безопасников или наоборот являются новой возможностью противодействовать текущим вызовам и проблем ИБ.

Стали доступны видеозаписи и слайды с KubeCon + CloudNativeCon North America 2024 и это более 300 докладов (смотреть, не пересмотреть). Про безопасность докладов как всегда хватает и мы постепенно самые интересные начнем рассматривать на нашем канале.

На нашем сайте стали доступны слайды и видеозапись доклада "Kubernetes Audit Log в арсенале SOC" c SOC Forum 2024.

В рамках данного доклада наша команда Luntry делиться своими опытом и знанием о детектах на базе событий Kubernetes Audit Log.

Making Sense of Kubernetes Initial Access Vectors Part 2 – Data Plane – вторая статья (с первой можно ознакомиться тут) от WIZ, посвященная более глубокому разбору техник для получения Initial Access в Kubernetes кластере.

В этой статье автор разбирает техники, относящиеся к Data Plane:

- Applications – abuse RBAC и abuse system privileges
- NodePort Service
- Images and supply chain

В рамках конференции Cloud Native Rejekts 2024 прошел доклад “Malicious Compliance Automated: When You Have 4000 Vulnerabilities and only 24 Hours Before Release” от Duffie Cooley и Kyle Quest. Данный доклад является логическим развитием одного из моим самых любимых докладов за последнее время "Malicious Compliance: Reflections on Trusting Container Image Scanners" =)

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

Кто там сторонник zero tolerance к уязвимостям?! В общем сезон образов без уязвимостей объявляется открытым!

Making Sense of Kubernetes Initial Access Vectors Part 1 – Control Plane – неплохая статья от WIZ, посвященная более глубокому разбору техник для получения Initial Access в Kubernetes кластере.

Глобально автор разделил окружения на Control Plane, Data Plane, CI/CD и Cloud Access. В рамках данной статьи автор разбирает техники, относящиеся к Control Plane: Kubelet API Access, Management interfaces и K8s API Access.

Сегодня начался KubeCon + CloudNativeCon North America 2024, а значит что нас ждет море интересных докладов и анонсов. Ряд из больших анонсов уже были сделаны в преддверии конференции. Нам бы отдельно хотелось выделить:

1) Релиз containerd 2.0 (1.0 была выпущена 7 лет назад) - тут наконец есть стабильная поддержка user namespaces.

2) Istio Ambient Mode (то что работает без sidecar) достиг статуса General Availability в версии v1.24, что заняло у него чуть больше 2-х лет.

P.S. В комментариях можно поделится докладами, которые вам наиболее интересны с данного мероприятия.

Как думаете, насколько опасна такая Role?

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-exec-view-role
rules:
- apiGroups: [""]
  resources: ["pods/exec"]
  verbs: ["get"]

Если вы думали, что только Role/ClusterRole с правами create – pods/exec может позволить пользователю делать exec в Pod, то вы ошибались. Благодаря особенностям работы Websockets, прав get – pods/exec будет достаточно, чтобы выполнять команды в Pod.

Что ещё более интересно, так это то, что такое поведение уже было давно в Kubernetes, но вы могли его не заметить, поскольку по умолчанию для exec использовался SPDY протокол, а не Websockets. О проблеме известно с 2019 года!

Чтобы получить exec при правах get – pods/exec, например, можно воспользоваться wscat:

wscat -s "base64url.bearer.authorization.k8s.io.$token, base64.channel.k8s.io" -n -c 'wss://192.168.99.100:8443/api/v1/namespaces/default/pods/testpod/exec?container=testpod&command=sh&stdout=true&stderr=true&stdin=true&tty=true'

Однако, начиная с версии Kubernetes 1.31 для операций attach, exec и port-forward теперь по умолчанию используется Websockets, а это значит, что прав get – pods/exec будет достаточно, чтобы выполнять команды в Pod.

Нельзя не упомянуть свежую заметку Rory McCune – When is read-only not read-only?, в которой он рассказал об этой особенности.

12 ноября на конференции DevOops 2024 наша команда Luntry выступит с докладом “Латаем огрехи в образах приложений до рантайма, во время и после”, расскажем как сделать использование образов безопасными.

Внесем изменения на уровне самого образа, применяя модификации слоев с помощью docker-squash, mint и т. д. «Подкрутим» рантайм на уровне операционной системы и Kubernetes: AppArmor, capabilities, управление привилегиями и другие «ручки». Рассмотрим наблюдение за аномальным поведением контейнеров в рантайм.

Очень крутая статья "Kubernetes: The Road to 1.0" о том как все начиналось! Из материала можно узнать о следующих этапах появление Kubernetes:
1) Опыт эксплуатации оркестраторов Borg и Omega с 2009 по 2013
2) Ранняя разработка API контейнерного продукта в 2H2013
3) Подготовка к запуску в 1H2014
4) Финишная реализация устройства в 2H2014
5) Запуск в 2015

Напомним только что:
- 7 июня 2014 вышел initial релиз Kubernetes
- 10 июля 2015 вышел Kubernetes версии 1

И есть отдельный документальный фильм про Kubernetes.