Канал о (не)безопасности Kubernetes + микросервисных, контейнеризированных приложений. Ведет команда www.luntry.ru Вопросы, идеи, предложения => @Qu3b3c https://knd.gov.ru/license?id=673ddbc21039886b1d03b7ce®istryType=bloggersPermission
Наша команда Luntry очень любит тему observability
и красивую визуализацию. И данный проект нас не оставил равнодушными!
Речь идёт о проекте VpK, что является акронимом для Visually presented Kubernetes
. В данном инструменте есть много и разных способов визуализации ресурсов в кластере! Подробнее о проекте можно узнать из документации. Отдельно обратите внимание на режим Security, который посвящен RBAC
(и очень сильно напоминает rbac-tool).
В конце апреля вышла новая версия 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-кластер лучшим практикам?"
Проект 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.
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 ;)
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
.
secretgen-controller это контроллер, который предоставляет возможность с помощью специальных CRD
генерировать Secret
с определенным типом информации. Из поддерживаемых:
- Certificate (CAs, leafs)
- Password
- RSA Key
- SSH Key
- Secret Template Field
Тоесть не вы туда вписываете информацию, а она туда генерируется автоматически.
Также есть возможность:
- Импортировать и экспортировать секреты между namespaces
с помощью SecretExport
и SecretImport
- Описывать как создавать секрет из информации из других ресурсов с помощью SecretTemplate
Подробнее с проектом можно ознакомиться в документации и в директории с примерами.
Так данный контроллер должен быть интересен тем кто работает с секретами методом push
(а не pull
).
Стали доступны записи докладов с конференции fwd:cloudsec North America 2024!
P.S. Записи докладов с БеКон 2024 еще готовятся.
P.S.S. Сегодня можно в живую встретиться и пообщаться на Saint HighLoad++ 2024 ;)
В продолжение поста про метрики 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
.
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
, и как это можно использовать для атаки.
Очень хорошая заметка "Stop worrying about ‘allowPrivilegeEscalation’", но с очень противоречивым названием, которое привело к тому, что автору потом пришлось к началу стать добавить еще пояснение.
Материал обязателен к изучению, но не обращайте внимание на название. Также внимания заслуживает и доклад "Латаем огрехи в образах приложений с помощью Kubernetes" с БеКон 2024 нашего коллеги Анатолия Карпенко, где ‘allowPrivilegeEscalation’ также освещается ;)
Недавно увидели статью "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.
Если во время пентеста вы оказались на Node
и вам потребовалось собрать данные с etcd
, а набирать в консоле kubectl
и etcdctl
не хочется, то вот этот скрипт может вам помочь.
Всем, привет!
У нас есть опросник по итогам БеКон 2024 - он лежит здесь. Нам очень важна обратная связь от всех кто участвовал, чтобы следующую нашу конференцию еще лучше. И это не возможно без вашей помощи. Заранее большое спасибо за вашу помощь!
Определенно в следующим году мы немного расширим подход к отбору докладов и можно будет присылать свои заявки ;)
И еще раз всем спасибо, что пришли и поддержали нас на конференции)
В официальном блоге Kubernetes
вышла статья "10 Years of Kubernetes". Тоесть у K8s
День Рождение, отсчитывая от первого коммита на GitHub
! В статье описаны различные вехи, история и будущее развития. Всем не равнодушным обязательно к прочтению =)
P.S. Если у вас есть вопросы по докладам со вчерашнего БеКон, то пишите их в комментариях к соответствующим слайдам и докладчики ответят на них.
P.S.S. Исторически случайно случилось, что БеКон проходит рядом с ДР k8s - мелочь, а приятно)
"Вы еще не читаете Kubernetes Audit Log? Тогда мы идем к вам!" – Алиса Кириченко, Лаборатория Числитель
Читать полностью…Некоторое время назад мы уже писали про Cloud Threat Landscape и вот он обновился и там появился раздел Defenses. В данном разделе собраны защитные меры для противодействиям облачным атакам с кратким описанием и мапингом на D3FEND тактики. В общем, полезная вещь для систематизации своих знаний в данной области)
Читать полностью…16 июля
в 11:00
наша команда Luntry проведет webinar
на тему «Ловим злоумышленников и собираем улики в контейнерах Kubernetes».
Там мы рассмотрим следующие темы:
– способы обнаружения злоумышленника в контейнерных окружениях;
– какие подходы могут эффективно помочь в расследовании и реагировании на инциденты;
– возможности Luntry, полезные для Incident Response
: собрать артефакты для расследования и остановить злоумышленника.
Регистрация на вебинар по ссылке.
Относительно недавно 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
.
С 2021
года с любопытством слежу за двумя PolicyEngine
: Kubewarden, JsPolicy, - которые примечательны тем что, позволяют разрабатывать политики безопасности с использованием языков программирования общего назначения. Там политики можно писать на всем, что компилиться в WASM
и на JavaScript/TypeScript
соответственно.
Время показывает, что популярность они так и не завоевали ... На практике, необходимость написания политики на каком-то ЯП общего назначения для проверки YAML
это прям что-то очень эдакое (хотя, конечно, подтянуть задачу под условия можно). Получаем чрезмерную мощь с кучей сложностей по контролю, поддержки и развитию (их еще отдельным статическим анализатором надо проверять как любой код и контролировать на закладки ;) ) ...
По нашему опыту ни один из этих движков мы на проектах не встречали (да и на конфах и статьях они мелькаю редко). Бесспорными лидерами тут являются Kyverno
и OPA Gatekeeper
! И да не забываем про развивающиеся встроенные политики Kubernetes Validating Admission Policies, которые тоже не пошли по пути ЯП общего назначения, а выбрали CEL
.
27 июня в Москве пройдет BI.ZONE Cybersecurity Meetup, посвященный мониторингу и реагированию в контейнерах.
На встрече выступит Сергей Канибор, специалист Luntry, с темой «Поймай меня, если сможешь: как обнаружить следы злоумышленника в Kubernetes-инфраструктуре».
В ходе доклада вы узнаете какие подходы смогут эффективно помочь в расследовании и реагировании инцидентов, когда стало понятно, что злоумышленник скомпрометировал контейнер.
noah_h/top-offensive-techniques-for-kubernetes-a71399d133b2#b9f2">A Kubernetes Pentesting Checklist – неплохой по наполнению чеклист, чтобы удостовериться, что вы ничего не забыли про проведения пентеста в Kubernetes
инфраструктуре. Включает в себя проверки Control Plane
, RBAC Abuse
и EKS
.
Само собой, не стоит забывать про сетевые атаки, container escapes
и другие актуальные техники для k8s
окружения.
P.S. По нашему опыту проведения аудитов Kubernetes
кластеров, именно благодаря избыточным RBAC
привилегиям, а также уязвимостям компонентов Kubernetes
кластера удаётся не только сбежать из контейнера, но и получить cluster-admin
.
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
содержит практически всю информацию и учетные данные, необходимые для администрирования кластера, любой, кто имеет разрешение на ее чтение, тем самым получает доступ к кластеру на уровне администратора (и даже больше).
Время идет, а проникновение через публично доступный Docker Engine
никуда не девается.
В статье "Attackers deploying new tactics in campaign targeting exposed Docker APIs" разбирается недавняя атака, которая как по мне ничем особо не примечательная. Тут только атакующие написали несколько новых вспомогательных инструментов и все.
Помните, что наружу публиковать Docker API
не надо и что на него также можно навесить Policy Engine
. Об этом рассказывал Павел Сорокин на БеКон 2023 в докладе "OPA с shared Docker executor".
Всем, привет!
Рады сообщить, что стали доступны фотографии с нашей конференции БеКон 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
.
4 июля в 17:00 в рамках конференции Kuber Conf /24
от Yandex Cloud
наша команда Luntry представит доклад "Механизмы Kubernetes против атак supply chain" на треке Безопасность.
Поговорим про проблематику и актуальность Supply Chain
, а также рассмотрим как можно защититься от этого встроенными механизмами Kubernetes
.
Мероприятие будет доступно как офлайн, так и онлайн. Необходима предварительная регистрация.
Очень хардкорная статья "Flipping Pages: An analysis of a new Linux vulnerability in nf_tables and hardened exploitation techniques" для любителей атак через уязвимости ядра. Примечательна она тем что данный случай рассматривается в рамках KernelCTF
(о котором мы не однократно писали и который вышел из kCTF
). А также что для успешной атаки тут требуется unprivileged-user namespaces
, о котором мы рассказывали в одном из наших докладов на последнем БеКон ;)
В завершение этой недели хотим поделиться статьей – "Six Critical Blindspots While Securing Argo CD". Будет очень актуально, если вы используете (или планируете использовать) ArgoCD
в качестве GitOps
оператора в своей инфраструктуре.
В статье автор рассказывает о 6 принципах, которым необходимо следовать, чтобы сделать использование ArgoCD
максимально безопасным:1) Use a dedicated project for the control plane
2) Argo resources are for Argo admins only
3) Delete the “default” project
4) Block ClusterRoleBindings in (most) projects
5) Narrow roles on remote clusters
6) Have a CVE response plan ready
Мы завершили БеКон 2024. Всем, большое спасибо за участие!
Читать полностью…"Строим заборы между сервисами", – Андрей Бойцев, Яндекс Финтех
Читать полностью…