Недавно увидели статью "A Guide To Kubernetes Logs That Isn't A Vendor Pitch" в канале нашего хорошего товарища Сергея Солдатова. А сегодня хотим поделиться своими впечатлениями о ней.

На первый взгляд она очень массивная, но на самом деле большую ее часть занимают скриншоты и примеры событий, логов. Но если вы начнете ее читать, то потратите минут 7-10. В начале автор говорит, что нужно собирать логи с 4 уровней:
- Code
- Container
- Cluster
- Cloud

Постоянные читатели нашего канала явно узнают в это "The 4C's of Cloud Native Kubernetes security" ;) Основной ориентир тут на уровень Cluster и естественно главный действующий герой это Kubernetes Audit Log cо своей AuditPolicy. Статья очень общая и каких-то откровений, новшеств там нет ... И честно не очень то и далеко ушла от официальной документации.

Тут бы мы больше рекомендовали посмотреть слайды (видео будет позже) "Вы еще не читаете Kubernetes Audit Log? Тогда мы идем к вам!" – Алиса Кириченко с БеКон 2024.

Сегодня делимся вами слайдами с доклада "PIVOT!" — Bouncing between your app, your cluster and your cloud с прошедшей конференции KCD Zurich 2024.

В докладе автор рассказал о распространненых векторах атак для Managed Kubernetes в EKS, AKS и GKE. О некоторых из них (как и об инструменте MKAT, который упоминается в докладе) мы уже рассказывали на канале [1,2].

Тем не менее, данные слайды можно использовать как cheatsheet с полезными техниками для проведения пентеста в Managed Kubernetes.

Очень хорошая заметка "Stop worrying about ‘allowPrivilegeEscalation’", но с очень противоречивым названием, которое привело к тому, что автору потом пришлось к началу стать добавить еще пояснение.

Материал обязателен к изучению, но не обращайте внимание на название. Также внимания заслуживает и доклад "Латаем огрехи в образах приложений с помощью Kubernetes" с БеКон 2024 нашего коллеги Анатолия Карпенко, где ‘allowPrivilegeEscalation’ также освещается ;)

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

Рады сообщить, что стали доступны фотографии с нашей конференции БеКон 2024!

Taking a look at the Kube-Proxy API – очередная статья от Rory McCune, на этот раз о Kube-Proxy API.

В Kubernetes есть несколько компонентов, которые предоставляют API (например, kube-apiserver или kubelet). Но мало кто знает, что kubeproxy также предоставляет API.

В статье упоминается несколько эндпоинтов, но наиболее интересным выглядит эндпоинт /metrics – в ответе возвращаются prometheus метрики, а также информация о том какие feature gates включены в кластере. Наверняка это будет полезно, если вы исследуете Managed Kubernetes (когда у вас нет доступа к Control Plane).

Тут нельзя не упомянуть доклад "How Attackers Use Exposed Prometheus Server to Exploit Kubernetes Clusters", в котором авторы рассказали какую информацию может извлечь атакующий из торчащих наружу Prometheus endpoints, и как это можно использовать для атаки.

Время идет, а проникновение через публично доступный Docker Engine никуда не девается.

В статье "Attackers deploying new tactics in campaign targeting exposed Docker APIs" разбирается недавняя атака, которая как по мне ничем особо не примечательная. Тут только атакующие написали несколько новых вспомогательных инструментов и все.

Помните, что наружу публиковать Docker API не надо и что на него также можно навесить Policy Engine. Об этом рассказывал Павел Сорокин на БеКон 2023 в докладе "OPA с shared Docker executor".

В продолжение поста про метрики kubeproxy хочется затронуть тему Kubernetes Profiling и вместе с тем заметку из блога Rory McCune "Taking a look at Kubernetes Profiling".

По умолчанию профайлинг включен в kube-apiserver, scheduler, controller-manager и kubelet. Доступ к этой информации можно получить обратившись к эндпоинту /debug/pprof/profile, однако для kube-apiserver, kube-controller-manager и kube-scheduler нужны необходимые права RBAC, тогда как для kubelet любой пользователь, обладающий правами на node/proxy может получить доступ к информации о профилировании. Ранее мы уже освещали какие возможности представляются атакующему с правами nodes/proxy.

Один из наиболее интересных сценариев (с точки зрения безопасности), где можно использовать эту функциональность, раскрывается в случае, когда у пользователя, взаимодействующего с кластером есть возможность просматривать Kubernetes API server logs, поскольку это может позволить ему проэксплуатировать CVE-2020-8561 и начать использовать malicious webhooks.

Rancher раскрыли уязвимость в RKE, оцененную на 10/10 по CVSS – Credentials are stored in the RKE1 Cluster state ConfigMap.

Всё дело в том, что при провижининге кластера RKE сохраняет state в ConfigMap full-cluster-state в неймспейсе kube-system. А уже внутри этой ConfigMap хранится куча чувствительных данных: начиная от приватных SSH ключей, заканчивая кредами от облачных провайдеров.

Хотя эта ConfigMap не является общедоступной (для ее чтения требуется доступ к кластеру RKE), то, что она является именно ConfigMap, делает её доступной для неадминистраторов кластера. Поскольку full-cluster-state содержит практически всю информацию и учетные данные, необходимые для администрирования кластера, любой, кто имеет разрешение на ее чтение, тем самым получает доступ к кластеру на уровне администратора (и даже больше).

Стали доступны записи докладов с конференции fwd:cloudsec North America 2024!

P.S. Записи докладов с БеКон 2024 еще готовятся.

P.S.S. Сегодня можно в живую встретиться и пообщаться на Saint HighLoad++ 2024 ;)

A Kubernetes Pentesting Checklist – неплохой по наполнению чеклист, чтобы удостовериться, что вы ничего не забыли про проведения пентеста в Kubernetes инфраструктуре. Включает в себя проверки Control Plane, RBAC Abuse и EKS.

Само собой, не стоит забывать про сетевые атаки, container escapes и другие актуальные техники для k8s окружения.

P.S. По нашему опыту проведения аудитов Kubernetes кластеров, именно благодаря избыточным RBAC привилегиям, а также уязвимостям компонентов Kubernetes кластера удаётся не только сбежать из контейнера, но и получить cluster-admin.

secretgen-controller это контроллер, который предоставляет возможность с помощью специальных CRD генерировать Secret с определенным типом информации. Из поддерживаемых:
- Certificate (CAs, leafs)
- Password
- RSA Key
- SSH Key
- Secret Template Field

Тоесть не вы туда вписываете информацию, а она туда генерируется автоматически.

Также есть возможность:
- Импортировать и экспортировать секреты между namespaces с помощью SecretExport и SecretImport
- Описывать как создавать секрет из информации из других ресурсов с помощью SecretTemplate

Подробнее с проектом можно ознакомиться в документации и в директории с примерами.

Так данный контроллер должен быть интересен тем кто работает с секретами методом push (а не pull).

27 июня в Москве пройдет BI.ZONE Cybersecurity Meetup, посвященный мониторингу и реагированию в контейнерах.

На встрече выступит Сергей Канибор, специалист Luntry, с темой «Поймай меня, если сможешь: как обнаружить следы злоумышленника в Kubernetes-инфраструктуре».

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

Istio (а точнее Envoy, используемый под капотом) как обычно щедр на баги. Ресерчеры из Snyk нашли способ обойти AuthorizationPolicy. Для байпаса Istio изначально веб-приложение должно быть уязвимо к HTTP header injection. При такой уязвимости query параметры подставляются в заголовки ответа.

Чтобы проэксплуатировать уязвимость для начало необходимо убедить Istio, что TCP соединение было успешно преобразовано в WebSocket. Для этого в параметрах и заголовках к запросу необходимо выставить параметры upgrade=websockets и connection=upgrade. При этом сервер вернёт 200-ый код ответа, что не типично при успешном переключении на WebSocket. После этого все запросы отправленные на ручки, ограниченные AuthorizationPolicy, будут успешно проходить.

Уязвимости присвоили CVE-2024-23326, необходимые патчи уже выпущены.

P.S – Актуальный доклад про внедрение AuthorizationPolicy с прошедшего БеКон 2024.

P.S.S – Использование механизмов Service Mesh не освобождает от использования Network Policy.

С 2021 года с любопытством слежу за двумя PolicyEngine: Kubewarden, JsPolicy, - которые примечательны тем что, позволяют разрабатывать политики безопасности с использованием языков программирования общего назначения. Там политики можно писать на всем, что компилиться в WASM и на JavaScript/TypeScript соответственно.

Время показывает, что популярность они так и не завоевали ... На практике, необходимость написания политики на каком-то ЯП общего назначения для проверки YAML это прям что-то очень эдакое (хотя, конечно, подтянуть задачу под условия можно). Получаем чрезмерную мощь с кучей сложностей по контролю, поддержки и развитию (их еще отдельным статическим анализатором надо проверять как любой код и контролировать на закладки ;) ) ...

По нашему опыту ни один из этих движков мы на проектах не встречали (да и на конфах и статьях они мелькаю редко). Бесспорными лидерами тут являются Kyverno и OPA Gatekeeper! И да не забываем про развивающиеся встроенные политики Kubernetes Validating Admission Policies, которые тоже не пошли по пути ЯП общего назначения, а выбрали CEL.

26-27 июня прошел CloudNativeSecurityCon North America 2024. Большая часть слайдов с конференции уже доступна в разделе расписания. На мой взгляд это конференциям прям удалась по контенту - очень много всего интересного. За изучением материала провел практически все выходные) В этот раз даже не будем выделять какие-то презентации иначе их будет около 15!

Если попытаться выделить какие-то основные трендовые мысли, то получится примерно следующее:
- Вектор развития на ZeroTrust как с точки зрения сети, так и работы самих приложений
- Безопасность AI/ML приложений и инфраструктур
- Закрепление неэффективности сигнатурных подходов детектирование и переход к поведенческим
- Важность сборов артефактов для расследования инцидентов в контейнерах
- Прямолинейный ориентир на количество CVE не дает никакой пользы
- Развитие Supply Chain Security за пределы классического SBOM в сторону Dynamic SBOM, VEX, моделей поведения

P.S. Подсвечу всё-таки один доклад - "User Namespaces in Kubernetes: Security and Flexibility", который является идейным близнецом моего доклада "Linux user namespace в чертогах Kubernetes" с нашего БеКон 2024 ;)

Относительно недавно Open Container Initiative (OCI) community представило новую версию OCI Image Spec v1.1.0. Одно из ключевых изменений в этой версии спецификации это добавление поддержки metadata artifacts.

В artifacts можно хранить любую metadata, асоциированную с OCI image, а это – SBOM, signatures, attestations и vulnerability scanning reports. Помимо этого, в artifacts можно указать так называемаем non-containers artifacts: Helm Charts, Kubernetes manifest files, WASM modules, OPA bundles, Bicep files.

P.S. – Azure Container Registry уже поддерживает OCI Image Spec v1.1.0.

Проект camblet это Kernel Space Access Control для Zero Trust Networking для организации fine-grained, zero-trust для идентификации нагрузок и контроля доступа, именно:
- аутентификации
- авторизации
- шифрования

Взаимодействия между нагрузками, которые могут быть запущены как в Kubernetes, так и просто на хосте вне контейнера!

Инструмент был представлен в рамках доклада "Leveraging the Linux Kernel for Building a Zero-Trust Environment Without a Service Mesh" на прошедшей CloudNativeSecurityCon North America 2024.

Пока проект, конечно, больше выглядит как PoC, но сам подход к реализации через ядро Linux, без sidecar очень интересен)

В теме этого хотелось бы также напомнить про замечательный доклад "Все ли Service Mesh одинаковы полезны для ИБ?" от Максима Чудновского с БеКон 2024.

16 июля в 11:00 наша команда Luntry проведет webinar на тему «Ловим злоумышленников и собираем улики в контейнерах Kubernetes».

Там мы рассмотрим следующие темы:

– способы обнаружения злоумышленника в контейнерных окружениях;
– какие подходы могут эффективно помочь в расследовании и реагировании на инциденты;
– возможности Luntry, полезные для Incident Response: собрать артефакты для расследования и остановить злоумышленника.

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

В конце апреля вышла новая версия CIS Kubernetes Benchmark под номером 1.9 для Kubernetes 1.27 – 1.29. Особо критических изменений в бенчмарке не было (их можно посмотреть в конце документа в разделе appendix):

- автоматизировали проверки с 5.1.1 по 5.1.6
- в пунктах 1.1.13 и 1.1.14 были изменены названия (появился super-admin.conf – об этом мы рассказывали в одном из предыдущих постов)

Конечно всякие Open Source инструменты, вроде kube-bench, уже обновили свои конфиги и поддерживают версию 1.9. Однако не стоит забывать о том, что такие инструменты не показывают полной и объективной картины происходящего на предмет соответствия кластера по CIS. Об этом кстати мы рассказывали в одном из прошлых вебинаров – "Соответствует ли ваш Kubernetes-кластер лучшим практикам?"

Некоторое время назад мы уже писали про Cloud Threat Landscape и вот он обновился и там появился раздел Defenses. В данном разделе собраны защитные меры для противодействиям облачным атакам с кратким описанием и мапингом на D3FEND тактики. В общем, полезная вещь для систематизации своих знаний в данной области)

Наша команда Luntry очень любит тему observability и красивую визуализацию. И данный проект нас не оставил равнодушными!

Речь идёт о проекте VpK, что является акронимом для Visually presented Kubernetes. В данном инструменте есть много и разных способов визуализации ресурсов в кластере! Подробнее о проекте можно узнать из документации. Отдельно обратите внимание на режим Security, который посвящен RBAC (и очень сильно напоминает rbac-tool).