Тем временем, в предверии конференции KubeCon + CloudNativeCon NA 2024, вышла новая версия Kyverno – 1.13. Основных изменений не так много:

- добавлена поддержка подписей images, использующих sigstore bundle
- добавлена поддержка PolicyExceptions для ValidatingAdmissionPolicies сгенерированных из Kyverno политик (используя subrule validate.cel)

Также нельзя не упомянуть о ломающих изменениях:

1) С версии 1.13 у контроллеров Kyverno отобраны wildcard разрешения на просмотр всех ресурсов. Это изменение может повлиять на отчеты, а также на политики mutate и generate на пользовательских ресурсах, поскольку контроллер больше не сможет просматривать пользовательские ресурсы
2) CVE-2024-48921 позволяла пользователям с возможностью создавать PolicyExceptions обходить ClusterPolicy в конкретном неймспейсе.

Совсем недавно обновился учебный план для сертификата Kubernetes Security Specialist (CKS) (новая версия 1.31). Данный план в принципе может быт неким ориентиром по построению защиты у себя. Там есть разбивка на разделы:
- Cluster Setup
- Cluster Hardening
- System Hardening
- Minimize Microservice Vulnerabilities
- Supply Chain Security
- Monitoring, Logging and Runtime Security

Отдельно выделим следующие моменты:
1) Необходимость NetworkPolicy встречается сразу в нескольких разделах
2) "Minimize host OS footprint (reduce attack surface)" <- специализированные OS
3) "Minimize base image footprint" <- про тонкие/минималистичные образы
4) "Perform behavioral analytics to detect malicious activities" <- обнаружение по поведению, а не правилам
5) "Use Kubernetes audit logs to monitor access" <- доклад об этом сегодня от нас на SOC Forum ;)

Продолжая тематику Kubernetes Network Security, Rory McCune представил новую заметку в своем блоге – Exploring A Basic Kubernetes Network Plugin.

Статья объясняет, как в Kubernetes кластере Pods получают IP-адреса через сетевые плагины, соответствующие спецификации CNI. В примере используется kind с плагином kindnetd.

Конфигурация сети хранится в файле 10-kindnet.conflist, где указаны IP-диапазоны для каждого узла. Для маршрутизации трафика между подами на разных узлах kindnetd создает записи в таблице маршрутизации. В завершение автор отмечает, что работа с сетью в Kubernetes может быть сложной и зависит от выбранного сетевого плагина.

Очень крутая статья "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.

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

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

Как думаете, насколько опасна такая 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?, в которой он рассказал об этой особенности.

Сегодня начался 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. В комментариях можно поделится докладами, которые вам наиболее интересны с данного мероприятия.

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.

В рамках конференции 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 2 – Data Plane – вторая статья (с первой можно ознакомиться тут) от WIZ, посвященная более глубокому разбору техник для получения Initial Access в Kubernetes кластере.

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

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

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

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

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

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

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

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

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

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

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

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