Мы уже на канале писали про инструмент 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 экзамена тут.

Мы продолжаем активно развивать тему безопасности контейнеров и Kubernetes. И в этот раз 15-16 сентября в Ульяновске в рамках международной IT-конференция “Стачка” наш коллега Андрей Ганюшкин (да, наш коммерческий директор тоже разбирается в безопасности кубов) простым языком для широкой аудитории представит доклад: “Контейнеры и Kubernetes: не боимся, а используем и защищаем”. Он расскажет об отличии контейнеров от виртуальных машин, затронет тему оркестрации и объяснит, как “видят” контейнерные среды государственные регуляторы (PCI DSS, 118 приказ, ГОСТ 57580.1-2017) и, конечно, о специфике безопасности Kubernetes RBAC, NetworkPolicy и Kubernetes-ресурсов упомянуть не забудет.

"Container security fundamentals part 6: seccomp" – шестая статья из цикла статей [1,2,3,4,5] про безопасность контейнеров от Rory McCune.

В ней рассматривается как с помощью seccomp фильтров (они кстати написаны на BPF) можно ограничить какие системные вызовы (syscalls) можно вызывать из контейнера, а какие нет. Тоесть этот механизм у нас больше не про изоляцию одних процессов на хосте от других, а про изоляцию контейнерных процессов от хоста. Это на пример поможет позволить не совершить легкий побег из контейнера! На скрине пример с unshare, о котором мы уже не однократно рассказывали.

Вчера прошла онлайн конференция eBPF Summit 2023. Программа конференции достаточно обширная, но если говорить про security доклады, то это:

- Minifying Containers with SlimToolkit and eBPF Leveraging Tetragon's File System Activity Tracing
- Detecting and Preventing Stack Pivots in Linux Userland Programs Using eBPF
- How to use eBPF as a solution to Observe and optimize applications for endpoint security

Вместе с тем, на eBPF Summit 2023 проходит CTF. Если вы хотите порешать таски, можно поднять их локально у себя отсюда.

Сами доклады уже доступны, запись трансляции можно посмотреть здесь.

В нашем решении компонент сенсора (у нас собственная разработка, а не какой-то OpenSource проект) использует данную технологию и наша команда с большим интересом следит за данным мероприятием!

В этот пятничный день нам бы вас хотелось познакомить с интересным Kubernetes оператором, который даже его создатели не рекомендуют запускать ... =)

Встречайте MagicHappens Kubernetes Operator!

Его идея до безобразия просто и беспощадна: в CustomeResource (тоесть в YAML) в текстовом поле описываем человеческими словами какие Kubernetes ресурсы мы хотим получить и все. Далее это попадает OpenAI (под капотом еще есть проект Kopf) и результат уже в Kubernetes API.

Для полной завершенности проекта на наш взгляд еще не хватает распознавания речи, чтобы это CustomeResource не вбивать в ручную, а надиктовывать системе ;)

P.S. "Создай Deployment для образа registry.corp.ru полностью соответствующий требованиям Pod Security Standard и с установленным default seccomp profile" - как-то так джун DevOps будет работать в будущем!

P.S.S. Мидл DevOps результат полученный на предыдущем шаге отправит на проверку другой AI системе ;)

На прошедшей в августе конференции OFFZONE был доклад, который мы не могли оставить без внимания – Как скрыть свои действия, когда отслеживается каждый шаг (Иван Гаврилов, Innostage).

В своем докладе Иван рассмотрел сильные и слабые стороны технологии eBPF для задач безопасности, а также возможные методы сокрытия своих действий на примере существующих eBPF‑based-инструментов безопасности для Kubernetes – Tetragon и KubeArmor.

Как итог – автору удалось обойти обнаружение всех видов событий (процессы, файловые и сетевые) при определенных условиях:

- передача в качестве аргумента utf-8 символа
- запуск бинарника с большим путём
- запуск процесса с большим количеством аргументов

Также автор поделился инструментами, которые он написал для своего исследования. Их можно найти по ссылке тут. Кстати, слайды презентации можно найти здесь, а видео с выступления тут.

21 сентября на онлайн-конференции про IT-инфраструктуру для бизнеса Selectel Tech Day наша команда в лице Дмитрия Евдокимова представит доклад “ZeroTrust в Kubernetes: Не пустые слова”. Там рассмотрим насколько сложно или не сложно построить ZeroTrust в Kubernetes c примерами атак и защиты.

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

Kubernetes может быть не только в контексте серверных приложений, но и безопасности рабочих мест пользователей!

Проект kVDI это Virtual Desktop Infrastructure запущенная на Kubernetes. Возможности:
- Контейнерезированный пользовательский "desktops" без требований к виртуализации
- Шифрование трафика между конечным пользователем и "desktop" контейнером
- Возможность персистентности пользовательских данных
- Поддержка воспроизведения аудио, микрофона
- Передача файлов с/на "desktop" сессию
- RBAC система для мапинга пользовательского доступа
- Поддержка MFA
- Использование локальной аутентификации, LDAP или OpenID
- UI для управления системой

Получаем эфемерное рабочее место, которое в любой момент времени можно развернуть, убить и создать с чистого листа! Отдаленно напоминает идею Google ChromeOS с ее множеством уровней изоляции и облачной идеологией.

P.S. И да, компании уже сейчас начали пилотировать такой подход у себя ;)

Недавно встретили такое требование в DevSecOps концепции одной компании, которое звучит примерно следующим образом: "Автоматический запрет развертывания образов с определенными CVE и секретами". И если про проблемы с первым мы уже не раз писали и рассказывали [данный пост и в вебинаре "Patch management не поможет, фиксики не спасут"], то второй момент это что-то новое, что мы ранее не встречали. Давайте разбираться - имеет ли это какой-то смысл.

Если в образ попал секрет и этот образ уже лежит в registry, то можно уже констатировать факт, что секрет утек. Ведь все сотрудники, что могут пулить образы могут забрать как весь образ так и его конкретный слой. А в последствии извлечь все необходимое. То есть организовать такой канал утечки данных (помните о registry staging). Контроль этого в моменте развертывания, это какой-то узкий кейс, не решающий основную проблему, и несущий угрозу только в том случае если в образ потом кто-то попадет из вне. Плюс все те же проблемы, что и с CVE, которые могут привести к падению системы.

По правильному еще в pipeline должна быть соответствующая проверка образа и в случае ее не прохождения pipeline должен падать и образ не попадать в registry. Последней стадией в этом pipeline, это подпись образа, если только он прошел все чеки. А уже в моменте развертывания только проверка этой подписи ;)

Microsoft обновила "Threat matrix for storage services". Первая версия вышла 2 года назад и обновление получило много изменений и заслуживает внимания.