k8s (in)security

06 марта 2024 06:58

Cross Container Attacks: The Bewildered eBPF on Clouds – очень крутой 19-страничный paper о внутреннем устройстве eBPF для нападения и защиты и всё это в контексте container escape.

Отдельно порадовал раздел eBPF-based Cross Container Attacks с пунктами:

- Container Escape with eBPF
- Kubernetes Cross Node Attack
- Bypassing Cloud Security Products

k8s (in)security

04 марта 2024 12:47

За последнее время приходило много вопросов в личку, а также в чатах про runtime security в Kubernetes. Видно, что данная тема многих интересует, но при этом есть много недопонимания что, как, зачем и когда работает. Слишком много подходов, технологий и решений.

Поэтому мы решили провести вебинар «Runtime Security: на вкус и цвет все фломастеры разные». Он пройдет 14 марта в 11:00.

Мы расскажем о Runtime Security для контейнеров. В том числе обсудим конкретные темы:
• Виды Runtime-защиты: Isolation, Detection, Reaction, Prevention;
• Встроенные Runtime-защиты в Linux и Kubernetes: Linux capability, Seccomp, AppArmor (LSM), SeLinux (LSM), PARSEC (LSM), NetworkPolicy.
• Реализации сторонних средств защиты: Falco (Sysdig/StackRox/…), Tetragon, Tracee (KubeArmor), Kubernetes Security Profiles Operator и т.д.

А также обозначим взгляд Luntry на эти вопросы и расскажем, как это работает у нас.

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

P.S. Это будет в том же формате, что и вебинар "Соответствует ли ваш Kubernetes-кластер лучшим практикам?", где мы много показывали всего вживую, а не просто сидели на слайдах. Ну и продолжительную сессию вопросов и ответов гарантируем ;)

k8s (in)security

01 марта 2024 07:06

Сегодня мы рады анонсировать первые доклады с нашей конференции БеКон 2024.

№1
Название: Почему защитой k8s должно заниматься целое подразделение?
Докладчик: Артем Мерец (Tinkoff)
Описание: Все больше компаний и сервисов живут в системах оркестрации контейнеров. Кибербезопасность реагирует на эти изменения путем развития практик защиты внутри и рядом с k8s, при этом часто выделение ресурсов на эту часть выглядит недоинвестированным. Порассуждаем о том, какие проблемы должна решать команд, какая должны быть экспертиза и почему это выглядит как целое подразделение для защиты "одного приложения".

№2
Название: Linux user namespace в чертогах Kubernetes
Докладчик: Дмитрий Евдокимов (Luntry)
Описание: В сообществе Linux и по сей день не утихают споры о полезности и нужности такого механизм как user namespace в области безопасности, хотя именно для этого он и создавался. Давайте рассмотрим какую роль и значение он играет в связке с Kubernetes и разберемся кто он друг или враг.

P.S. До 15 марта можно взять билеты по сниженной цене.

k8s (in)security

28 февраля 2024 07:52

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

1) Разрешено удалять любые ресурсы
2) Разрешено читать Secrets
3) Разрешен доступ ко всем ресурсам
4) Разрешено выпускать Secrets token
5) Разрешены все действия над ресурсами
6) Разрешено удалять Pods
7) Разрешены все API Group
8) Разрешено создавать Pods
9) Разрешено модифицировать Pods
10) Разрешено создавать PersistentVolumeClaims

Топ самых опасных правил составлен на основе количества Roles\ClusterRoles, которые содержат данные права. Если так, то первая половина практически всегда так выглядит, а вторая может незначительно меняться (позиции и появляться что-то новое). И, наверное, стоит отдельно отметить, что это все делалось в компаниях, которые занимаются безопасность своих кластеров, а не пускают все на самотек)

Если топ строить относительно количества субъектов, у которых есть эти права, то топ у компаний, что занимаются ИБ сильно, не поменяется. А вот в компаниях, что не занимаются ИБ часто содержит правило Cluster Admin с парой десятков сотрудников =)

k8s (in)security

26 февраля 2024 07:41

Хочется показать, что вокруг творится много всего интересного, а именно создаются различные OpenSource проекты нашими читателями, друзьями, коллегами в тематике контейнеров и Kubernetes.

Так, например, мы некоторое время назад релизили проект MTKPI для pentest и писали про open-source платформу для подготовки к экзаменам CKA, CKAD и CKS.

А сегодня хочется представить проект нашего читателя - kube_tor_gateway. Это VPN-шлюз с множественной инкапсуляцией (аналог TOR-сети). Как пишет сам автор: "Цель данного решения - продемонстрировать нестандартное использование системы управления контейнерами на базе Kubernetes, так как k8s - это SDK :)".

Из интересного также отметим там сборку через проект nixpkgs. Если не знаете, что это такое, то можно как раз познакомиться и с этим проектом ;) На этом канале мм уже как-то писали о связанном проекте Nixery.

В ближайшее время мы представим еще ряд проектов наших читателей. А если вы что-то сейчас делаете, то также присылайте - мы рассмотрим и постараемся больше внимания привлечь к вашему проекту, чтобы он не был заброшен, а развивался!

k8s (in)security

22 февраля 2024 06:08

Закончим эту короткую неделю простенькой задачкой с подвохом, которую я люблю задавать на своих тренингах "Cloud Native безопасность в Kubernetes".

Представим Kubernetes кластер, в котором все ресурсы попадают только через репозиторий, никакие сотрудники компании на прямую в k8s ничего деплоить не могут.

При этом как вы, наверное, знаете популярные PolicyEngine в виде Kyverno и OPA Gatekeeper в CLI режиме (в принципе можно и другими тулами тоже) можно встроить в pipeline и прям там все несоответствующее политикам браковать/блокировать, тоесть не допускать не то что до k8s, но и вообще до репозитория.

И тут возникает вопрос: если мы так все здорово можем сделать в духе Shift Left Security, то зачем вообще нужен в такой системе PolicyEngine в виде Admission Controller ?!

Пишите ваши варианты в комментариях, а мы отметить правильный вариант в Пн, а если его вдруг не будет (но в такое не вериться - тут собралось много крутых ребята), то напишем его также в Пн.

P.S. Чтобы чуть-чуть усложнить задачу также уберем сценарий с наличием какого-то mutating admission webhook.

P.S.S. Тот, кто знает ответ с моего тренинга просьба не учувствовать ;)

k8s (in)security

20 февраля 2024 05:26

На глаза попался интересный проект RAD Security - Cloud native workload fingerprints! По сути это сборник моделей поведения для публичных образов. Сама модель поведения представляет из себя дерево процессов с их взаимоотношением с файловой и сетевой подсистемой. Задумка такая, что это типа эталон и вы наблюдая у себя за поведением, сравниваете его с эталоном. Как результат, можете поймать как 1day и 0day атаки, так и проблемы с Software Supply Chain Security.

На скрине можно видеть модель поведения с этого проекта и с нашего Luntry для mongodb. На самом деле у нас подобная идея есть давно, но все руки никак не дойдут до реализации этого ... =( При этом есть ряд нюансов для подобного, которые не дают для всех случаев сказать что это эталон.

В общем, предлагаем собраться еще на одном вебинаре и мы расскажем и про различные механизмы runtime security и про модели поведения. Как вам идея?)

k8s (in)security

16 февраля 2024 06:04

Инструмент Grant это анализатор лицензий от создателей Syft и Grype. Он позволяет просматривать лицензии для образов контейнеров, SBOM файлов, файловой системы и применять правила (достаточно гибкие), которые помогут построить license compliance отчет. Знает и понимает безумное количество лицензий https://spdx.org/licenses/ !

k8s (in)security

14 февраля 2024 05:49

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

Вся наша команда Luntry очень рада объявить, что уже полным ходом идет подготовка ко второй нашей конференции БеКон 2024 !!!

Что сейчас есть и известно:
1) Дата: 5 июня
2) Место: Москва, LOFT HALL#2
3) Сайт: https://bekon.luntry.ru/
4) Билеты: Уже можно покупать и до 15 марта действует early bird цена. Количество билетов ограничено.
5) Партнерство: Появилось возможность стать партнером конференции!
6) Доклады: Будет порядка 10 и постепенно будем их выкладывать

Мы планируем сохранить все что всем понравилось на первом БеКон и поработать над его недочетами, чтобы мероприятие сохранило свою атмосферу и стало еще лучше =)

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

P.S. Про первый БеКон 2023 можно посмотреть и почитать тут!

k8s (in)security

12 февраля 2024 06:09

Наш хороший товарищ и крутой инженер Григорий завел tg-канал Кубернетчик, где как не трудно догадаться делиться своим опытом и знанием по k8s. У него есть и замечательные посты связанные и с безопасностью! Отдельно выделим посты, с которыми мы вам и рекомендуем сегодня ознакомиться:

1) Проблема переполнения maps в CNI Cilium при определенных условиях работы с NetworkPolicy и ее DNS-based вариацией
2) Как восстановить случайно удаленный cluster-admin Role
3) NVIDIA GPU Operator как страшный сон безопасника

Что греха таить, некоторые его мысли лежали в основе наших постов, вот теперь он будет всем своим опытом делиться на своем канале =) Хочется ему пожелать только удачи в этом начинании!

k8s (in)security

08 февраля 2024 06:29

Частой проблемой при запуске/эксплуатации кластеров Kubernetes является нехватка дискового пространства. При провижинге Node необходимо следить за тем, чтобы на ней было достаточно места для хранения образов контейнеров и запущенных контейнеров.

В статье Image Filesystem: Configuring Kubernetes to store containers on a separate filesystem авторы хотят обратить внимание на то, как можно настроить runtime на хранение его содержимого отдельно от раздела по умолчанию.
Это позволяет более гибко настраивать Kubernetes и обеспечивает поддержку добавления большего диска для хранения контейнеров, сохраняя при этом файловую систему по умолчанию нетронутой.

k8s (in)security

06 февраля 2024 12:44

За последнее время у нас накопилось много мыслей, идей, материала по поводу всем хорошо известного CIS Kubernetes Benchmark (и вообще compliance-моментах). Вам может казаться, что вы хорошо знаете этот benchmark (мы тоже так когда-то думали), но поверьте это далеко не так ;)

Поэтому мы решили в рамках вебинара "Соответствует ли ваш Kubernetes-кластер лучшим практикам?" всем этим поделиться с вами и поговорить о:
- Стандартах безопасности для Kubernetes,
- Очевидные и не очень вещи в CIS Kubernetes Benchmark,
- Возможности Open Source решений,
- И, конечно, взгляд Luntry на эти вопросы и расскажем о реализации со стороны нашей команды.

Дата: 15 февраля в 11:00
Регистрация: по ссылке тут

P.S. Если у вас уже сейчас есть интересующие вас вопросы, то пишите в комментариях - раскроим их на вебинаре!

k8s (in)security

05 февраля 2024 13:41

Недавно мы проводили конкурс с призом в виде билета на DevOpsConf 2024, где можно послушать много интересных докладов, включая от нашей команды Luntry : “Безопасность Kubernetes-кластеров: вредные советы”.

На наш взгляд выиграл вариант про бесполезность антивирусов на нодах Kubernetes! Он и в нашем докладе будет рассмотрен и больше всего отклика у аудитории вызвал)

Поздравляем победителя и спасибо всем кто участвовал =)

k8s (in)security

02 февраля 2024 06:03

Поскольку новая уязвимость container escape в runc CVE-2024-21626 уже получила успешные PoC эксплойты (1, 2), самое время вспомнить пару важных основ контейнерной безопасности.

Во-первых, не запускайте образы, которым вы не доверяете! Это звучит очень очевидно, но тем не менее.. В данном случае запуск образа из недоверенного источника может привести к тому, что злоумышленник сможет закрепиться в вашем Kubernetes кластере.

Во-вторых, не забывайте патчить все компоненты вашего окружения. О runc иногда забывают, поскольку это компонент низкого уровня, но его безопасность жизненно важна, поскольку именно он устанавливает container sandbox и запускает ее.

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

k8s (in)security

01 февраля 2024 08:45

Исследователи из Snyk нашли ряд уязвимостей в runc и docker, благодаря которым можно совершить container escape:

1) CVE-2024-21626: Several container breakouts due to internally leaked fds
2) CVE-2024-23653: Interactive containers API does not validate entitlements check
3) CVE-2024-23652: Possible host system access from mount stub cleaner
4) CVE-2024-23651: Possible race condition with accessing subpaths from cache mounts

Все уязвимости оцениваются от high до critical. Необходимые патчи уже выпущены.

Также для преждевременного обнаружения эксплуатации данных уязвимостей был выпущен инструмент leaky-vessels-dynamic-detector.

k8s (in)security

05 марта 2024 05:35

Несколько дней назад вышел Kubernetes v1.30.0-alpha.3 и, как всегда, мы полезли смотреть changelog и анализировать, что там есть по безопасности. Пока что наше внимание привлекло только появление такой новой фичи, как:

- Add feature gate MutatingAdmissionPolicy for enabling mutation policy in admission chain. (#123425) [SIG API Machinery]

Связано оно с KEP-3962: Mutating Admission Policies и является альтернативой mutating admission webhooks. И наши читатели определенно помнят недавно появившеюся фичу Validating Admission Policies. Как вы понимаете, MutatingAdmissionPolicy — это из той же области. Таким образом, данные фичи k8s медленно, но верно залезают на территорию PolicyEngines.

k8s (in)security

04 марта 2024 06:01

Если вам нужно собирать Kubernetes Audit Log в Managed Kubernetes, инструмент kube-audit-rest может вам подойти.

Тулза может использовать Validation или Mutation webhook, для перехвата вызовов к Kubernetes API и отправлять эти данные в стороннюю систему, например в Elastic. Как утверждает автор, этот способ будет сильно дешевле, чем существующие предложения от облачных провайдеров, которые взимают плату за каждый вызов API.

Но у тулзы есть ряд очевидных минусов:

- используемый webhook может логировать запросы, которые были провалены другими vaildating webhook
- из-за игнорирования failure: ignore могут быть пропущенные запросы, которые не были залогированы ввиду недоступности kube-api server
- логируются dry-run запросы
- вызовы API могут логироваться неоднократно из-за того, что Kubernetes неоднократно повторно вызывает webhook, поэтому они могут быть расположены не в хронологическом порядке
- этот инструмент работает только с запросами на мутацию/валидацию. Read Only requests не отправляются на mutating или validating webhook.

k8s (in)security

29 февраля 2024 06:15

Продолжим тему анализа RBAC. После вчерашнего поста несколько друзей и знакомых в личке спрашивали: "А чем такой топ полезен, кроме того что это просто интересный рейтинг?". Если посмотреть на это с пентестерской точки зрения, то в некотором роде он демонстрирует, какие права и с какой вероятностью мы сможем найти, попав на Node и покопавшись в имеющихся там ServiceAccounts. Случай, когда мы пытаемся нужный Pod запустить там же, мы пока оставим за скобками.

Помимо этого рейтинга, мы еще идем с другой стороны. Мы анализируем права, которыми обладают сервисы, запущенные как DaemonSet, — тут думаю все понятно). Типа вот такого.

k8s (in)security

27 февраля 2024 06:09

Очередной очень простой способ побега из привилегированного контейнера, через монтирования корня ФС хоста внутрь контейнера.

Работает связка cat /proc/cmdline + findfs UUID + mkdir + mount.

k8s (in)security

22 февраля 2024 14:28

24-25 февраля в Нижнем Новгороде на базе ННГУ им. Лобачевского пройдет Пятая ежегодная конференция DEFCON НН. Среди участников в этом году будет наш коллега и друг по Luntry — Анатолий Карпенко. Он выступит с докладом «Как сделать контейнеры и работу с ними безопасными».

Выступление будет построено в виде диалога с аудиторией, в котором спикер и слушатели обсудят сразу несколько вопросов в рамках темы:
— Что отслеживать ещё на этапе написания Dockerfile,
— Что использовать при организации pipeline,
— Как взаимодействовать с registry,
— Что использовать в контейнерных оркестратора.

Вход на конференцию бесплатный. Программа и регистрация — по ссылке.

k8s (in)security

21 февраля 2024 06:46

Некоторое время назад помогали клиентам решать следующую задачу: Как можно отловить проблемы безопасности с NetworkPolicy перед их применением? При этом как можно меньше для этого всего дела привлекать специалистов по ИБ (тоесть максимально автоматизировать), так как их мало, а команд разработки очень много.

И в начальных условиях мы еще имеем:
1) GitOps
2) Kyverno, который всегда на любого нового namespace создавал default-deny политику.

В итоге, мы остановились на том что в качестве критерий привлечения ИБ было появление или изменение в NetworkPolicy следующих моментов:
1) Появление/изменение ipBlock (чтобы контролировать все внешние коммуникации в egress)
2) Использование namespaceSelector без podSelector (чтобы не давали доступы целым namespaces)
3) Отсутствие в podSeclector специальных labels (чтобы использовали только определенную уникальную, хранящую имя сервиса)
4) Контроль portRange (чтобы не давать доступ сканировать прям целые диапазоны портов)

Это все для native реализации политик и как вы понимаете можно ее улучшать и ужесточать (например, тригерить при использовании определенного критичного namespаce) и т.д.

Логика по сути была такая, что если NetworkPolicy касается только внутрикластерного взаимодействия и не является какой-то "широковещательной" (диапазоны, подсети, целые namespace), то применяем без привлечения ИБ. Если же политика касалась внешних коммуникаций, была "широковещательной", то требовало ревью ИБ.

Как вам такой план? Может у вас в компании это решено по другому?

k8s (in)security

19 февраля 2024 06:12

Мы выложили запись недавнего вебинара "Соответствует ли ваш Kubernetes-кластер лучшим практикам?" продолжительность почти 1 час 30 мин! Для тех кто пропустил, содержание следующее:
- Стандарты безопасности для контейнерных сред - поговорили что вообще есть от CIS, NAS/CISA, DoD, PCI, NIST, ФСТЭК
- Очевидные и не очень вещи в CIS Kubernetes Benchmark - окунулись в него и прошлись по оригинальному документу
- Возможности Open Source решений - рассмотрели реализации kube-bench, trivy-operator, StackRox, NeuVector
- Взгляд Luntry - рассмотрели нашу реализацию с автоматизацией в 99%

Многим такой формат вебинара очень зашел (немного слайдов, изучение документов, рассмотрение исходного кода на GitHub, живая демонстрация, интерактив (его можно добавить еще больше)) и честно я сам от такого кайфанул, так как нет никаких ограничений) Так что будем продолжать делать подобное! Все равно ни одна конференция не даст возможности столько времени раскрывать тему, постоянно прыгать от одного документа/страницы к другой и т.д. Уже придумали порядка 5 тем в таком же формате!

P.S. Слайды будут добавлены в разделе "Исследования" сегодня в течении дня.

k8s (in)security

15 февраля 2024 05:30

Сегодня в центре внимания статья "Calico vs. Cilium: 9 Key Differences and How to Choose". Сравнение двух CNI идет по следующим 9 пунктам:
- High-Level Architecture
- Performance and scalability
- Network policy
- Policy management
- Observability
- Kubernetes platform support
- Multi-Cluster management
- Cluster mesh
- Deployment and configuration

Согласны ли совсем или есть что добавить?)

P.S. Напомним, что сегодня 11:00 мы проведем наш вебинар, где окунемся в мир CIS Kubernetes Benchmark!

k8s (in)security

13 февраля 2024 05:31

Вышла вторая статья из цикла Kubernetes security fundamentals и в этот раз про Authentication (первая была про API Security и о ней мы писали тут).

Как обычно очень кратко и просто представлена база, полезная для новичков.

Для более продвинутых мы рекомендуем следующие три материала: 1, 2, 3.

k8s (in)security

09 февраля 2024 06:27

kubeletmein – инструмент для проведения pentest, который при мисконфигурации использует API cloud provider для генерации kubeconfig. Поддерживает GKE, EKS и AKS.

Более подробно об этом мисконфиге можно почитать в статье Hacking Kubelet on Google Kubernetes Engine.

k8s (in)security

07 февраля 2024 06:58

Securing Services Meshes Easier with Kyverno – небольшая статья, рассказывающая о том, как сделать ваши Pods безопаснее при использовании Service Mesh.

Наверняка при использовании Istio или Linkerd вы замечали, что их initContainers имеют достаточно высокие привилегии. Kyverno предоставляет довольно гибкие механизмы для создания исключений, в том числе и на уровне initContainers.

В грядущей версии Kyverno 1.12 (которая вероятно выйдет перед KubeCon + CloudNativeCon Europe 2024) разработчики сделали несколько интересных улучшений, которые сделают исключения для таких случаев использования ещё проще.

k8s (in)security

06 февраля 2024 06:01

Если вы никогда не слышали про Dependency Confusions в докер образах, то статья "Dependency Confusions in Docker and remote pwning of your infra" как раз для вас.

Проблема возникает, когда при использовании docker mirrors добавляется несколько источников. Сначала Docker будет искать базовый образ в первом указанном registry mirros, а затем во втором. Это возможно только в том случае, если проект использует внутренние пространства имен, поскольку, если не указать пространство имен, то по умолчанию неявно будет выбрано пространство имен библиотеки, куда загружаются только официальные образы.

Ваш проект уязвим, если:

- настроены два или более зеркал, а Docker Hub объявлен первым
- проект использует одно или несколько пространств имен в своем внутреннем registry
- это пространство имен не зарегистрировано на Docker Hub

Если говорить о мерах защиты:

1) Никогда не объявлять удаленный registry первым в зеркалах
2) Использовать только fully qualified image names: docker run <registry>/<namespace>/<image>:<tag>.

k8s (in)security

05 февраля 2024 06:02

В конце прошлой неделе вышло довольно крупное обновление CNI Cilium – 1.15. Если говорить о Security изменениях:

- Reduced Envoy Privileges. Процесс, обрабатывающий HTTP-трафик, больше не имеет привилегий для прямого доступа к BPF maps или socket options.

- Ingress Network Policy. Применение сетевых политик для входящего трафика через Ingress + GatewayAPI

- Новые dashboards для Grafana. О них мы уже рассказывали ранее.

- Hubble Flows to a Network Policy Correlation. Теперь с помощью Hubble можно понять, какие сетевые политики разрешают трафик.

k8s (in)security

01 февраля 2024 13:00

Читая данный канал и ориентируясь на подписи к постам, у вас может сложиться впечатление, что это делает всего 2 человека. Но это далеко не так! На самом деле это аккумуляция опыта всей нашей команды Luntry (Разработчиков, DevOps, R&D, QA, Support), которая каждый день сталкивается с интересными моментами и задачами при работе с cloud-native окружениями (+ ,конечно, внутренне споры и мозговые штурмы).

И сейчас мы продолжает расти и ищем к себе Middle/Senior Go Developer (2-3 человека).

Если вам и/или вашим друзьям/знакомым интересно поработать над высоконагруженным проектом для контейнеров и Kubernetes в области security и observability, то откликайтесь или по любым вопросам пишите @Qu3b3c ;)

k8s (in)security

31 января 2024 06:52

Совсем скоро, а именно с 19 по 22 марта, в Париже пройдет KubeCon + CloudNativeCon Europe 2024! Финальная сетка докладов уже доступна. Вот некоторые из докладов, которые отдельно зацепили наш глаз из темы Security:

- Brewing the Kubernetes Storm Center: Open Source Threat Intelligence for the Cloud Native Ecosystem
- Stop Leaking Kubernetes Service Information via DNS!
- Misconfigurations in Helm Charts: How Far Are We from Automated Detection and Mitigation?
- I'll Let Myself in: Kubernetes Privilege Escalation Tactics
- Kubernetes Security Blind Spot: Misconfigured System Pods
- Living off the Land Techniques in Managed Kubernetes Clusters

Самые интересные доклады, по нашему мнению, после публикации слайдов и видео, мы постараемся разобрать на канале.