CNCF опубликовало текст документа "Security Zero Trust using Cloud Native Platforms". Очень достойный документ, который в очередной раз заставляется задуматься о "пользе" постоянных сканирований, использования сигнатур и т.д. В итоге понять какие действительно меры рабочие в текущих реалиях.

P.S. Всем хороших выходных!

Security Tool Ranking – довольно забавный рейтинг популярности security тулзов. Рейтинг расчитывается по трем критериям: stars, pull requests и issues.

Интересно, что из 50 позиций около 20 так или иначе относятся к направлению Kubernetes security. Это, в свою очередь, говорит о популярности самого Kubernetes в целом.

Однако, слепо верить и доверять таким рейтингам при выборе инструмента не стоит ;)

Ребята из команды GitHub выпустили заметку "mTLS: When certificate authentication is done wrong" на базе своих исследований представленный на конференциях Black Hat USA и DEF CON. В рамках ее они рассматривают:
1) Что такое mutual TLS
2) Атаки на mutual TLS

Рассматриваются как известные атаки, так и новые на базе уязвимостей:
- CVE-2023-2422 improper certificate validation in KeyCloak
- CVE-2023-33201 LDAP injection in Bouncy Castle
- CVE-2023-28857 credentials leak in Apereo CAS

По нашим клиентам знаем, что периодически компании для организации mutual TLS между сервисами используют не какие-то готовые решения (типа ServiceMesh), а пишут полностью свои. И вот это исследование будет полезно как первым так и вторым ;)

Давненько не доводилось попадать в печатные журналы (чуть ли не с времен когда я был одним из редакторов журнала ХАКЕР). Но тут по приглашению друзей поучаствовал в очень интересном формате (offline круглый стол) на тему безопасной разработки. В этом круглом столе поучаствовало 19 организаций и каждая ответила на 7 вопросов. По мне это прекрасная возможность за короткий промежуток времени ознакомиться с различными точками зрения по одной теме. С самим эти круглым столом можно ознакомиться в журнале "Информационная безопасность" №3 (стр. 40-41) или online тут.

P.S. Не забываем о вебинаре «Patch management не поможет, фиксики не спасут», что пройдет 29 августа! А так в живую можно увидеться с нашей командой Luntry на конференции OFFZONE.

Ни для кого не секрет, что Istio для своей работы инжектит sidecar контейнер в довесок к основным, работающим в Pod. Однако в Kubernetes 1.28 появилась нативная реализация sidecar контейнеров и статья Kubernetes Native Sidecars in Istio как раз про это!

Один из самых популярных кейсов в issue трекере – продолжение работы sidecar контейнера после завершения работы Job. Теперь у этой проблемы появилось решение. Начиная с версии Kubernetes 1.28 новое featureGate – SidecarContainers призвано решить этот кейс. Для того чтобы Kubernetes понял, что это действительно sidecar – нужно вынести контейнер в initContainers и выставить restartPolicy: Always.

P.S. Мы уже рассказывали про эту возможность, в одном из предыдущих постов.

Проект Kuasar как говорят авторы это Efficient Multi-Sandbox Container Runtime. Давайте разберемся что это за зверь такой. Ребята выделяют 3 типа sandbox:
1) microVM
2) Application-kernel
3) WASM

При это они говорят, что нет единого container runtime, может работать со всеми этими sandbox одновременно ... И тут как раз их low-level container runtime написанный на Rust и должен решить эту проблему.

Следующий момент, это то что в недрах containerd, с 2022 идет работа над Sandbox API. И данный проект является по сути первым, который это реализовал/поддержал.

По сути Kuasar соединяет high-level container runtime c sandbox плагинами и sandbox API.

Так это все по сути очень сырое: Sandbox API еще не зафиксировано, containerd по хорошему нужен 2 версии, но он еще не выпущен, ...

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

Сегодня наша команда, в лице Сергея Канибора, выступит на конференции OFFZONE 2023 с докладом – Kubernetes Pentest All‑in‑One: The Ultimate Toolkit на AppSec.Zone в 14:00.

Доклад будет посвящён docker образу, который призван упростить жизнь при проведении Kubernetes пентеста. Сам образ появился в результате проведения аудитов и обкатан в боевых условиях. Мы расскажем с какими реальными проблемами и ограничениями можно столкнуться при проведении пентеста k8s, а также поделимся тем, как эти проблемы можно решить.

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

P.S – будем рады пообщаться на тему безопасности контейнеров и Kubernetes ;)

На недавно прошедшем HITB Sec Conf 2023 в Phuket был представлен доклад "gVisor: Modern Linux Sandboxing Technology". Достаточно любопытное исследование, которое хорошо погружает в тему linux sandbox механизмов и решений. И после погружения в базу автор рассматривает написание собственного "идеального" решения под названием vmjail, который базируется на gVisor (внутреннее устройство, которого также рассматривается).

Самые важные моменты:
- vmjail находиться в разработке и кода не опубликовано
- Проект требует изменение в исходном коде gVisor (достаточно много доработок)
- Проект подразумевает два режима работы: enforce security policy (строго определяем политику) и analysis (мониторим поведение)
- Интересная идея привязки политик OCI spec

Так что, честно говоря, для большинства это исследование будет интересно чисто на уровне теории механизмов Linux ... Будет ли вообще опубликован проект (не говоря уже о его нормальной поддержке) - не известно.

P.S. Все слайды с конференции можно посмотреть тут.

Istio OutboundTrafficPolicy Egress Control Bypass – интересная статья про обход сетевого ограничения Istio.

Все кто сталкивался с Istio знают, что он для своей работы инжектит sidecar контейнер в довесок к основным, работающим в Pod. Этот sidecar контейнер редиректит трафик с Pod на Istio egress gateway c помощью правил iptables, которые как раз таки определяют возможности сетевого взаимодействия Pod. Но это ограничение можно обойти, если есть возможность получить UID 1337 внутри контейнера.

И это является довольно критичным моментом, ведь контейнеры внутри Pod имеют общее пространство имен. Так что если вы получили root в одном контейнере Pod это значит, что у вас есть root и в другом контейнере. Злоумышленнику, которому удалось попасть внутрь Pod, в котором работает Istio sidecar, достаточно выполнить setuid() и установить UID или GID равный 1337, чтобы подобрать правило iptables для Istio и обойти фильтрацию трафика.

Резюмируя: использование Istio для ограничения egress трафика не отменяет использование Network Policy.

P.S – на канале, в одном из предыдущих постов, мы уже рассказывали про возможности обхода ограничений безопасности Istio.

P.P.S – хотим напомнить, что сегодня в 11:00 мы проведем вебинар Patch management не поможет, фиксики не спасут, в котором разберем проблемы patch management в реальных условиях.

Мы уже на канале писали про инструмент Atomic Red Team и про его развитие Stratus Red Team. А теперь ребята из DataDog по сути сделали обертку над этим и назвали это Workload Security Evaluator, который позволяет симулировать runtime attacks. Вокруг этого можно в принципе сделать свой BAS (Breach and Attack Simulation).

Точно с такой же идей к нам подходили после нашего доклада "Kubernetes Pentest All-in-one: The Ultimate Toolkit" с OFFZONE 2023, где мы зарелизили наш инструмент MTKPI. То есть можно вокруг него разработать скрипты и получить BAS ;) Возможно что у нас это будет логичное продолжение развития проекта! Ну а также все вы можете принять в этом участие и присылать свои PR в данный Open Source проект.

В Kubernetes 1.28 появилась возможность ограничивать User Namespace у конкретного Pod. Сама по себе фича может довольно сильно уменьшить возможный attack surface. При попытке сбежать из контейнера такой процесс не сможет причинить значительного вреда хосту.

В pod.Spec добавляется булево поле hostUsers. Если его значение true или не задано, то используется пространство имен хоста (как и раньше). Если же false, то для пода создается новый userns.

Тем самым, даже если вы используете уязвимую версию ядра к CVE-2022-0492, можно использовать довольно лаконичную митигацию данного риска. Наглядное демо с тем как это работает можно посмотреть тут.

В день знаний, завершающий эту неделю, поделимся с вами короткой, но очень технической заметкой под названием "Short Note About Container Escapes, Namespaces, and Filesystem Roots". Полезна она будет в первую очередь kernel exploit writers (на пример, участникам Google’s kernelCTF), которым эксплуатации баги ядра из контейнера нужно еще и преодолеть ограничения mount namespace. рассматривается два сценария:
1) Через вызов setns()
2) Через перезапись fs в структуре task_struct

Каждый из способов имеет как свои преимущества и недостатки, что зависят от ситуации, баги, условиях, которые есть при эксплуатации баги в ядре. Так при использовании ROP первый сценарий будет проще, а при наличии arbitrary write примитива второй сценарий будет более стабильным.

Всем хороших выходных!

В ближайшее время пройдет конференция DevOops 2023 и наша команда Luntry примет в этом мероприятии активное участие. А именно: Сергей Канибор представит 1 доклад, а Дмитрий Евдокимов поучаствует в 3 круглых столах!

Доклад:
1) 18 сентября "Network Policy для разработчиков: как, зачем и почему"

Круглые столы:
1) 5 сентября "Безопасность: консультативная vs запрещающая"
2) 5 сентября "Решит ли eBPF все проблемы?"
3) 18 сентября "Безопасность контейнеров в 2023 году. Тренд или необходимость?"

В общем, покроем все темы на которых наша команда специализируется: Kubernetes, безопасность, eBPF и контейнеры. 18 сентября будем рады пообщаться со всеми на площадке DevOops 2023 =)

Начнем эту неделю с образовательной темы по работе Kubernetes, а именно с ответа на вопрос "Where does the kubelet mount volumes?".

Краткий ответ /var/lib/kubelet/<pod-id>/volumes/.

А более подробный - в рамках данной стать ;)

Самому автору понадобилось это из-за:"Recently, I was troubleshooting an issue where some files were being mounted as a volume to a container in a Pod on a Kubernetes cluster. The volume appeared to be mounted successfully, but the container was failing to authenticate with credentials that should have been present in the mounted directory."

Так при прочтении ее всегда давайте себя отчет в том что все показывается на kind кластере с его спецификой.

Рады поделиться записью нашего вебинара "Patch management не поможет, фиксики не спасут", который мы проводили на прошлой неделе! Так что если вы по тем или иным причинам не смогли на нем присутствовать, то теперь можно спокойно посмотреть, оставить обратную связь и задать свои вопросы ;)

Безопасность Linux контейнеров (да, есть и Windows реализация [1,2,3]) неразрывно связана с безопасностью ядра Linux. И по этому вопросу есть два великолепных ресурса от Александра Попова и Андрея Коновалова соответственно:
- Linux Kernel Defence Map
- Linux Kernel Exploitation

Отличные ресурсы, чтобы погрузиться в kCTF и kernelCTF ;)

K8s Network Policy Migrator – это инструмент для миграции кастомных сетевых политик Calico или Cilium в нативные сетевые политики Kubernetes. Инструмент предлагает такие возможности, как предварительные проверки, сбор и преобразование политик, а также удобные опции проверки, применения, отката и очистки.

Будет полезно, если вы переезжаете в кластер, где в качестве CNI используется не привычный вам Calico или Cilium, а что-то другое, но наличие NetworkPolicy очень необходимо.

Само собой, тулза способна конвертировать только тот функционал, который есть и в кастомоных и в нативных политиках. FQDN, L7 и Host политики она не поддерживает, точно также как и привязку по Service name, Service Account и прочему... Наверное, в качестве инструмента для миграции стоит также упомянуть NetworkPolicy editor от Cilium – там можно создать Cilium политику и перевести её в Native. О нём мы уже как-то рассказывали на канале.

Про кастомные политики рекомендуем посмотреть наше выступление "NetworkPolicy — родной межсетевой экран Kubernetes" ;)

Совсем недавно обновился интересный проект за которым мы с удовольствием наблюдаем и возможно кому-то даже для решения каки-то специфичных, узких задач даже и подойдет. Речь идет о Usernetes, который представляет из себя Kubernetes без root привилегий. Проект похож на Rootless kind и Rootless minikube, но в отличии от них он поддерживает создание кластера с множеством нод.

Самая идея и фича крутятся вокруг KEP-2033: Kubelet-in-UserNS (aka Rootless mode).

eBPF программы однозначно стали новым трендом – они помогают повысить уровень observability и security, нередко их можно встретить и у Kubernetes Secuity вендоров. Но помимо очевидных плюсов, которые привносит eBPF, также не стоит забывать и про угрозы, которые они могут принести. Статья eBPF Offensive Capabilities – Get Ready for Next-gen Malware от Sysdig как раз про это.

Авторы выделили четыре eBPF offensive capabilities:

- Abusing direct map access
- Abusing Kprobes
- Abusing TC hook
- Abusing Uprobes

Для каждого из векторов они приводят рабочий код, а также возможные меры prevention. Если говорить о глобальных способах митигаций даннного направления, то это ограничение capabilities SYS_BPF для root юзера.

P.S. Поэтому чрезвычайной важно понимать, что делает eBPF код. И это одна из причин почему у себя в решении мы используем свой код, а не взятый на стороне.

Те кто давно читают наш канал знают, что наша команда очень любит концепцию Kubernetes operators, так как с ними можно привнести и автоматизировать в Kubernetes что угодно. И, конечно, время от времени мы находим разные готовы решения, которые могут что-то улучшить, упростить или просто помочь в решении какой-то задачи.

Не давно к нам на глаза попался оператор namespace-configuration-operator, разработанный командой RedHat. Он позволяет: "create rules that will react to the creation of Users, Groups and Namespace and will create and enforce a set of resources." То есть упростить onboarding процесс для пользователей, групп или неймспейсов. Для этого в нем есть такие CustomResources как UserConfig, UserConfig, NamespaceConfig, которые описывают правила при совпадении с которыми автоматом появляются описанные в них ресурсы.

В документации есть 2 примера, для разных сценариев:
1) developer sandbox
2) team onboarding с поддержкой всего SDLC в multitentant окружении

Таким образом удобно автоматом накидывать определенные ограничения как ИБ, так и ИТ. Опытный читатель может заметить пересечение с проектом HNC и ему подобными, завязанными на мультитенантность.

Такой подход можно подсмотреть для собственного оператора, особенного если вы внутри совей компании строите свою платформу на базе Kubernetes ;)

У нас отличные новости для всех, кто готовится к экзаменам CKA, CKAD и CKS или просто хочет освоить Kubernetes. Подписчик нашего канала создал совершенно бесплатную open-source платформу, которая делает подготовку максимально удобной.

Возможности платформы:

- Создание всех необходимых ресурсов (VPC, subnets, EC2) автоматически.
- Настраивайте кластеры под различные сценарии в несколько кликов.
- Эквивалент killer.sh, но абсолютно бесплатно.
- Возможность легко добавлять свои собственные сценарии.
- Тесты для проверки правильности выполнения заданий.
- Контроль времени для максимально реалистичных мок-экзаменов.

На данный момент доступны сценарии:

- CKA mock экзамена
- CKS hands-on lab
- CKS mock экзамена

Ссылку на GitHub можно найти тут, а видео с примером запуска CKA mock экзамена тут.