k8s (in)security

В конце прошлого года в Kubernetes была найдена серьезная уязвимость CVE-2023-5528 высокого уровня критичности с CVSS 7.2 (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H)!!!

Срочно бегите обновляйте свои кластера на Windows!

Пока те пару человек пошли обновляться (и команда Azure), давайте разберемся в самой уязвимости, а поможет нам в этом статья от исследователей, что ее обнаружили, под названием "What a Cluster: Local Volumes Vulnerability in Kubernetes".

Основные моменты:
- Кластер на Windows
- kubelet < v1.8.0
- Атакующий с правами создавать pods и persistent volumes
- Отсутствие проверки пользовательского ввода в subPath параметре YAML файла приводит к injection
- Получаем RCE c привилегиями SYSTEM на всех Windows тачках в кластере

Авторы также выложили политику для OPA для обнаружения и блокировки эксплуатации такого. Это еще раз говорит, что Policy Engine это просто must have компонент в безопасности - заранее нельзя знать от какого ресурса и параметра ожидать подставы...

P.S. Мне как бывшему реверсеру, так радостно снова увидеть calc.exe в payload =)

P.S.S. И уже сегодня в 11:00 мы поговорим на вебинаре про runtime security в k8s ;)

В будущей версии Kubernetes 1.30 фичу Support User Namespaces in Pods перевели в beta. Теперь её можно использовать с Pods c (или без) volumes, кастомными UID/GUID ranges и не только!

Благодаря использованию User Namespaces, можно митигировать риски от таких уязвимостей как CVE-2024-21626 или CVE-2021-25741. Для этого нужно включить feature gate – UserNamespacesSupport и добавить в манифест поле hostUsers:

apiVersion: v1
kind: Pod
metadata:
  name: cve202421626
spec:
  hostUsers: false
  containers:
  - name: ubuntu
    image: ubuntu
    workingDir: /proc/self/fd/8
    command: ["sleep"]
    args: ["infinity"]  

Демо с митигацией CVE-2024-21626 и использованием User Namespace можно посмотреть тут.

Сегодня мы рады анонсировать еще 2 доклада с нашей конференции БеКон 2024. Таким образом уже анонсировали 6 докладов. Будет еще 3-4.

#5
Название: От стандартных к нестандартным методам управления секретов в контейнерах
Докладчик: Валерий Кунавин
Описание: На сегодняшний день есть огромное количество способов управлять секретами - почти на любой вкус и цвет. Важно в этом ориентироваться и понимать какой способ выбрать в том или ином случае. При этом понимать от каких нарушителей это нас все равно не убережет ... И при необходимости думать уже в сторону нестандартных способов - в сторону короткоживущих секретов.

№6
Название: Мультитенантность в Kubernetes: есть ли серебряная пуля?
Докладчик: Константин Аксенов (Флант)
Описание: Существуют различные варианты для организации мультитенантности в Kubernetes, например Hierarchical Namespace Controller (HNC) или Capsule. Есть возможность реализовать свой подход к изоляции с помощью базового Kubernetes API или создать свой собственный API. Естественно выбор во многом зависит от требований и внутреннего устройства процессов и команд. В докладе рассмотрим преимущества и недостатки разных подходов, а также к чему мы пришли в процессе разработки нашего решения.

P.S. До 15 марта можно взять билеты по сниженной цене.

Статья "There are only 12 binaries in Talos Linux" в блоге разработчиков ОС Talos раскрывает интересную статистику и информацию, о том сколько исполняемых файлов надо чтобы завелся k8s.

Вы понимаете насколько вообще можно уменьшить поверхность атаки (attack surface) и гемор по vulnerability management?! Не говоря уже об исключении целой модели нарушителя)

P.S. В названии 12, а в таблице 29, потому что подсчитаны sym и hard линки.

Если вы используете SELinux (или AppArmor) в Kubernetes, то одним из условий использования является наличие профиля на каждой Worker Node, где могут запускаться нагрузки. Раскладывание профилей по Nodes довольно распространненая проблема, однако её можно решить с помощью Security Profles Operator (о котором мы не раз рассказывали на канале – 1, 2, 3).

В версии CRI-O 1.30 был добавлен ряд аннотаций, благодаря которым можно удобно ссылаться на размещенный в OCI registry SELinux профиль:

- seccomp-profile.kubernetes.cri-o.io/<CONTAINER>
- seccomp-profile.kubernetes.cri-o.io/<POD>

Более подробно об этом функционале можно почитать в официальном блоге Kubernetes, а именно в статье CRI-O: Applying seccomp profiles from OCI registries.

Сегодня мы рады анонсировать еще 2 доклада с нашей конференции БеКон 2024.

№3
Название: Мечтают ли антивирусы о docker-образах?
Докладчик: Владимир Капистка (samokat.tech)
Описание: Рассмотрим один из шагов нашего pipeline, который связан с антивирусным сканированием публичных docker-образов, загружаемых из Интернет в частный реджестри.

№4
Название: Все ли Service Mesh одинаковы полезны для ИБ?
Докладчик: Максим Чудновский (Сбертех)
Описание: Все знают, что одной из самых популярных фичей Service Mesh является функциональность zero-trust периметра для микросервисов: нам доступны mTLS, политики взаимной аутентификации и авторизации сразу из коробки. А еще все знают, что Service Mesh бывает разный - на sidecar-контейнерах, как Istio, или сетевых демонах, как Cilium, или что-то среднее, как новый Istio Ambient Mesh. В докладе мы рассмотрим, как под капотом реализованы популярные механизмы безопасности в этих решениях и научимся выбирать Service Mesh с точки зрения безопасности контейнеров.

P.S. До 15 марта можно взять билеты по сниженной цене.

На нашем сайте стали доступны слайды доклада "Безопасность Kubernetes кластеров: вредные советы" с прошедшего DevOpsConf 2024 (видео будет доступно позже). Доклад был очень хорошо принят аудиторией - спасибо вам большое за это! Многие уже начали спрашивать будет ли вторая часть?) Думаю, что да! Также после доклада кто-то из слушателей отметил, что доклад можно было назвать "Безопасность Kubernetes кластеров: Bullshit Bingo" и это правда возможно даже лучше бы отражало смысл доклада) Но я думаю, что можно будет реально выпустить такой Bullshit Bingo, чтобы не скучно проводить митинги/созвоны =)

P.S. Можно смело контрибьютить в этот список!

P.S.S. Всех девушек с наступающим 8 марта!

13-14 марта пройдет online-конференция SafeCode 2024, в которой примет участие Сергей Канибор - автор данного канала и специалист Luntry.

14 марта в 12:15 по МСК в своем докладе «Нестандартное применение Kyverno» он расскажет об одном из самых популярных решений для класса PolicyEngines. Доклад особенно заинтересует AppSec-/DevSecOps-инженеров и DevOps.

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

Узнать больше о докладе можно по ссылке.

Cross Container Attacks: The Bewildered eBPF on Clouds – очень крутой 19-страничный paper о внутреннем устройстве eBPF для нападения и защиты и всё это в контексте container escape.

Отдельно порадовал раздел eBPF-based Cross Container Attacks с пунктами:

- Container Escape with eBPF
- Kubernetes Cross Node Attack
- Bypassing Cloud Security Products

Несколько дней назад вышел Kubernetes v1.30.0-alpha.3 и, как всегда, мы полезли смотреть changelog и анализировать, что там есть по безопасности. Пока что наше внимание привлекло только появление такой новой фичи, как:

- Add feature gate MutatingAdmissionPolicy for enabling mutation policy in admission chain. (#123425) [SIG API Machinery]

Связано оно с KEP-3962: Mutating Admission Policies и является альтернативой mutating admission webhooks. И наши читатели определенно помнят недавно появившеюся фичу Validating Admission Policies. Как вы понимаете, MutatingAdmissionPolicy — это из той же области. Таким образом, данные фичи k8s медленно, но верно залезают на территорию PolicyEngines.

За последнее время приходило много вопросов в личку, а также в чатах про runtime security в Kubernetes. Видно, что данная тема многих интересует, но при этом есть много недопонимания что, как, зачем и когда работает. Слишком много подходов, технологий и решений.

Поэтому мы решили провести вебинар «Runtime Security: на вкус и цвет все фломастеры разные». Он пройдет 14 марта в 11:00.

Мы расскажем о Runtime Security для контейнеров. В том числе обсудим конкретные темы:
• Виды Runtime-защиты: Isolation, Detection, Reaction, Prevention;
• Встроенные Runtime-защиты в Linux и Kubernetes: Linux capability, Seccomp, AppArmor (LSM), SeLinux (LSM), PARSEC (LSM), NetworkPolicy.
• Реализации сторонних средств защиты: Falco (Sysdig/StackRox/…), Tetragon, Tracee (KubeArmor), Kubernetes Security Profiles Operator и т.д.

А также обозначим взгляд Luntry на эти вопросы и расскажем, как это работает у нас.

Регистрация на вебинар по ссылке.

P.S. Это будет в том же формате, что и вебинар "Соответствует ли ваш Kubernetes-кластер лучшим практикам?", где мы много показывали всего вживую, а не просто сидели на слайдах. Ну и продолжительную сессию вопросов и ответов гарантируем ;)

Если вам нужно собирать Kubernetes Audit Log в Managed Kubernetes, инструмент kube-audit-rest может вам подойти.

Тулза может использовать Validation или Mutation webhook, для перехвата вызовов к Kubernetes API и отправлять эти данные в стороннюю систему, например в Elastic. Как утверждает автор, этот способ будет сильно дешевле, чем существующие предложения от облачных провайдеров, которые взимают плату за каждый вызов API.

Но у тулзы есть ряд очевидных минусов:

- используемый webhook может логировать запросы, которые были провалены другими vaildating webhook
- из-за игнорирования failure: ignore могут быть пропущенные запросы, которые не были залогированы ввиду недоступности kube-api server
- логируются dry-run запросы
- вызовы API могут логироваться неоднократно из-за того, что Kubernetes неоднократно повторно вызывает webhook, поэтому они могут быть расположены не в хронологическом порядке
- этот инструмент работает только с запросами на мутацию/валидацию. Read Only requests не отправляются на mutating или validating webhook.

Сегодня мы рады анонсировать первые доклады с нашей конференции БеКон 2024.

№1
Название: Почему защитой k8s должно заниматься целое подразделение?
Докладчик: Артем Мерец (Tinkoff)
Описание: Все больше компаний и сервисов живут в системах оркестрации контейнеров. Кибербезопасность реагирует на эти изменения путем развития практик защиты внутри и рядом с k8s, при этом часто выделение ресурсов на эту часть выглядит недоинвестированным. Порассуждаем о том, какие проблемы должна решать команд, какая должны быть экспертиза и почему это выглядит как целое подразделение для защиты "одного приложения".

№2
Название: Linux user namespace в чертогах Kubernetes
Докладчик: Дмитрий Евдокимов (Luntry)
Описание: В сообществе Linux и по сей день не утихают споры о полезности и нужности такого механизм как user namespace в области безопасности, хотя именно для этого он и создавался. Давайте рассмотрим какую роль и значение он играет в связке с Kubernetes и разберемся кто он друг или враг.

P.S. До 15 марта можно взять билеты по сниженной цене.

Продолжим тему анализа RBAC. После вчерашнего поста несколько друзей и знакомых в личке спрашивали: "А чем такой топ полезен, кроме того что это просто интересный рейтинг?". Если посмотреть на это с пентестерской точки зрения, то в некотором роде он демонстрирует, какие права и с какой вероятностью мы сможем найти, попав на Node и покопавшись в имеющихся там ServiceAccounts. Случай, когда мы пытаемся нужный Pod запустить там же, мы пока оставим за скобками.

Помимо этого рейтинга, мы еще идем с другой стороны. Мы анализируем права, которыми обладают сервисы, запущенные как DaemonSet, — тут думаю все понятно). Типа вот такого.

Недавно, заканчивая отчет по аудиту для клиента, а именно раздел про RBAC, поймал себя на мысли, что топ самых опасных правил практически такой же, как мы уже делали на другом проекте. Взяв еще несколько отчетов от нашего Luntry и сравнив с ними - мысль подтвердилась. Имеем следующий топ:

1) Разрешено удалять любые ресурсы
2) Разрешено читать Secrets
3) Разрешен доступ ко всем ресурсам
4) Разрешено выпускать Secrets token
5) Разрешены все действия над ресурсами
6) Разрешено удалять Pods
7) Разрешены все API Group
8) Разрешено создавать Pods
9) Разрешено модифицировать Pods
10) Разрешено создавать PersistentVolumeClaims

Топ самых опасных правил составлен на основе количества Roles\ClusterRoles, которые содержат данные права. Если так, то первая половина практически всегда так выглядит, а вторая может незначительно меняться (позиции и появляться что-то новое). И, наверное, стоит отдельно отметить, что это все делалось в компаниях, которые занимаются безопасность своих кластеров, а не пускают все на самотек)

Если топ строить относительно количества субъектов, у которых есть эти права, то топ у компаний, что занимаются ИБ сильно, не поменяется. А вот в компаниях, что не занимаются ИБ часто содержит правило Cluster Admin с парой десятков сотрудников =)

Очередной очень простой способ побега из привилегированного контейнера, через монтирования корня ФС хоста внутрь контейнера.

Работает связка cat /proc/cmdline + findfs UUID + mkdir + mount.

Хочется показать, что вокруг творится много всего интересного, а именно создаются различные OpenSource проекты нашими читателями, друзьями, коллегами в тематике контейнеров и Kubernetes.

Так, например, мы некоторое время назад релизили проект MTKPI для pentest и писали про open-source платформу для подготовки к экзаменам CKA, CKAD и CKS.

А сегодня хочется представить проект нашего читателя - kube_tor_gateway. Это VPN-шлюз с множественной инкапсуляцией (аналог TOR-сети). Как пишет сам автор: "Цель данного решения - продемонстрировать нестандартное использование системы управления контейнерами на базе Kubernetes, так как k8s - это SDK :)".

Из интересного также отметим там сборку через проект nixpkgs. Если не знаете, что это такое, то можно как раз познакомиться и с этим проектом ;) На этом канале мм уже как-то писали о связанном проекте Nixery.

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

24-25 февраля в Нижнем Новгороде на базе ННГУ им. Лобачевского пройдет Пятая ежегодная конференция DEFCON НН. Среди участников в этом году будет наш коллега и друг по Luntry — Анатолий Карпенко. Он выступит с докладом «Как сделать контейнеры и работу с ними безопасными».

Выступление будет построено в виде диалога с аудиторией, в котором спикер и слушатели обсудят сразу несколько вопросов в рамках темы:
— Что отслеживать ещё на этапе написания Dockerfile,
— Что использовать при организации pipeline,
— Как взаимодействовать с registry,
— Что использовать в контейнерных оркестратора.

Вход на конференцию бесплатный. Программа и регистрация — по ссылке.

Закончим эту короткую неделю простенькой задачкой с подвохом, которую я люблю задавать на своих тренингах "Cloud Native безопасность в Kubernetes".

Представим Kubernetes кластер, в котором все ресурсы попадают только через репозиторий, никакие сотрудники компании на прямую в k8s ничего деплоить не могут.

При этом как вы, наверное, знаете популярные PolicyEngine в виде Kyverno и OPA Gatekeeper в CLI режиме (в принципе можно и другими тулами тоже) можно встроить в pipeline и прям там все несоответствующее политикам браковать/блокировать, тоесть не допускать не то что до k8s, но и вообще до репозитория.

И тут возникает вопрос: если мы так все здорово можем сделать в духе Shift Left Security, то зачем вообще нужен в такой системе PolicyEngine в виде Admission Controller ?!

Пишите ваши варианты в комментариях, а мы отметить правильный вариант в Пн, а если его вдруг не будет (но в такое не вериться - тут собралось много крутых ребята), то напишем его также в Пн.

P.S. Чтобы чуть-чуть усложнить задачу также уберем сценарий с наличием какого-то mutating admission webhook.

P.S.S. Тот, кто знает ответ с моего тренинга просьба не учувствовать ;)

Некоторое время назад помогали клиентам решать следующую задачу: Как можно отловить проблемы безопасности с NetworkPolicy перед их применением? При этом как можно меньше для этого всего дела привлекать специалистов по ИБ (тоесть максимально автоматизировать), так как их мало, а команд разработки очень много.

И в начальных условиях мы еще имеем:
1) GitOps
2) Kyverno, который всегда на любого нового namespace создавал default-deny политику.

В итоге, мы остановились на том что в качестве критерий привлечения ИБ было появление или изменение в NetworkPolicy следующих моментов:
1) Появление/изменение ipBlock (чтобы контролировать все внешние коммуникации в egress)
2) Использование namespaceSelector без podSelector (чтобы не давали доступы целым namespaces)
3) Отсутствие в podSeclector специальных labels (чтобы использовали только определенную уникальную, хранящую имя сервиса)
4) Контроль portRange (чтобы не давать доступ сканировать прям целые диапазоны портов)

Это все для native реализации политик и как вы понимаете можно ее улучшать и ужесточать (например, тригерить при использовании определенного критичного namespаce) и т.д.

Логика по сути была такая, что если NetworkPolicy касается только внутрикластерного взаимодействия и не является какой-то "широковещательной" (диапазоны, подсети, целые namespace), то применяем без привлечения ИБ. Если же политика касалась внешних коммуникаций, была "широковещательной", то требовало ревью ИБ.

Как вам такой план? Может у вас в компании это решено по другому?