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 года назад и обновление получило много изменений и заслуживает внимания.

Reflector - это Kubernetes operator, предназначенный для мониторинга изменений в ресурсах (Secrets и ConfigMaps) и отражения изменений на зеркальных ресурсах в том же или других namespaces.

Для того чтобы указать источник (откуда будут скопированы данные) нужно добавить аннотацию вида reflector.v1.k8s.emberstack.com/reflection-allowed: "true" и reflector.v1.k8s.emberstack.com/reflection-allowed-namespaces: "<list>" к ConfigMaps или Secrets

Если источник удален, то удаляются и автоматические зеркала. Также если отражение или автоматическое зеркалирование отключены или namespace автоматического зеркала больше не соответствует разрешенным namespace, автоматическое зеркало удаляется.

Оператор будет полезен как минимум при решении двух задач:

- Для обеспечения TLS в динамических окружениях проектов необходимо выписывать сертификат для ветки main каждого проекта и копировать Secret во все остальные неймспейсы этого проекта
- Уметь автоматически синхронизировать Secret из централизованного хранилища во все нужные Kubernetes-кластеры и выбранные внутри них неймспейсы.

Закончим эту неделю смешным постом от организаторов конференции "Стачка", где выступал наш коллега Андрей Ганюшкин с докладом про безопасность контейнеров)

Классно, креативно =)

В начале новой недели с удовольствием поделимся с вами слайдами с выступления "ZeroTrust в Kubernetes:Не пустые слова" нашей команды Luntry с одного из последних мероприятий!

Для понимания всей картины добавили в презентацию множество рекомендаций для погружения в тему, чтобы для начинающих было проще изучать данную область.

Всем хорошей недели!

m9sweeper – OpenSource Kubernetes security платформа (а по факту интерфейс над несколькими проектами).

На данный момент закрывает следующие потребности и выводит результаты и графики по:

- Image scan (trivy)
- K8s CIS benchmark (kube-behch)
- K8s templates best practice (kubesec)
- PolicyEngine (OPA Gatekeeper)
- K8s pentest (kube-hunter)
- Runtime (Falco)

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

Исследователи из компании Quarkslab запустили цикл статей реверс Windows контейнеров и выпустили первую часть "Reversing Windows Container, episode I: Silo". Скорее всего 98% читателей данного канала врятли это пригодится в работе ... Но на наш взгляд концепция контейнеров будет развиваться активно и в ОС Windows, тем более с учетом активного развития в ней Windows Subsystem for Linux (WSL) картинка будет получаться очень интересная. Скорее всего все придет в итоге к гибридным системам совмещающем в себе лучшее из двух миров.

Так что познакомиться с данным циклом статей будет как минимум полезно ради общего развития (реверсерам так обязательно, это будет использовать малварь для обхода антивирусов и EDR - о таком уже писали тут). С французами из Quarkslab доводилось общаться на конференциях - крутые и материалы делают такие же.

Вчера для CNI Cilium вышло три CVE:

1) CVE-2023-41332 (DoS via Kubernetes annotations in specific Cilium configuration)
2) CVE-2023-39347 (Kubernetes users may update Pod labels to bypass network policy)
3) CVE-2023-41333 (Bypass of namespace restrictions in CiliumNetworkPolicy)

Две из трёх уязвимости позволяют злоумышленнику при определённых условиях обойти ограничения NetworkPolicy – причем как нативной (которую реализует сам Cilium), так и кастомной от Cilium.

Официальный патч с фиксом данных уязвимостей вышел две недели назад. Поддерживаемые версии с исправленными багами:

- 1.12.14
- 1.13.7
- 1.14.2

Из статьи "Making Sense Out of Native Sidecar Containers in Kubernetes" вы узнаете как прям по шагам изменяется возможность/последовательность запуска и завершения контейнеров в Pod с учетом появления нового "типа" контейнеров, как sidecar (по сути нативная поддержка такого паттерна на базе init), в Kubernetes 1.28.

P.S. Визуализация данного процесса это отдельный вид искусства - Иван молодец ;)

Как правило, для уменьшения поверхности атаки и в целом для уменьшения размера образа используют distroless image. В таких образах нет ничего лишнего – только полезная нагрузка.

Но если всё таки появилась необходимость проверить сетевое взаимодействие (health check probe) изнутри такого контейнера – LProbe будет очень кстати. Для этого в Dockerfile нужно добавить строчку вида:

COPY --from=ghcr.io/fivexl/lprobe:0.0.6 /lprobe /bin/lprobe

И в K8s манифесте добавить exec для readiness и liveness probes:

command: ["/bin/lprobe", "-port=8080", "-endpoint=/readiness”]

P.S – Мы уже как-то рассказывали про инструменты, которые могут пригодится при работе с distroless контейнерами – один из таких Dive.

"Escaping the Google kCTF Container with a Data-Only Exploit" - классная демонстрация Data-Only эксплоита (это очень не простой и достаточно редкий трюк) для побега из контейнера в рамках Google kCTF! В качестве подопытного взята бага в многострадальном io_ring )

Любителям хардкора премного рекомендуем =)