k8s (in)security

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

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

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

Мы выложили запись недавнего вебинара "Соответствует ли ваш 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. Слайды будут добавлены в разделе "Исследования" сегодня в течении дня.

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

Сегодня в центре внимания статья "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 pinned a photo

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Если вы никогда не слышали про 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>.

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

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

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

В конце прошлой неделе вышло довольно крупное обновление 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 можно понять, какие сетевые политики разрешают трафик.

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

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

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

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

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

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

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

Исследователи из 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.

Совсем скоро, а именно с 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

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

Распределение полезных нагрузок по Nodes очень важная составляющая безопасного Kubernetes кластера. Правильная scheduling strategy может помочь снизить общий риск компрометации Pods – уменьшить возможный blast radius и предотвратить lateral movement.

В статье Kubernetes Scheduling And Secure Design описаны следующие методы для построения scheduling strategy:

- nodeSelector
- nodeName
- Affinity and anti-affinity
- Interpod affinity and anti-affinity
- Taints and Tolerations
- Pod topology spread constraints
- Custom Scheduler

P.S – Также не стоит забывать о NodeRestriction плагине. Даже если злоумышленник смог сбежать из контейнера на Nodes, при включенном плагине он не сможет повлиять на нагрузки, запущенные на других Nodes.