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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Некоторое время назад помогали клиентам решать следующую задачу: Как можно отловить проблемы безопасности с 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), то применяем без привлечения ИБ. Если же политика касалась внешних коммуникаций, была "широковещательной", то требовало ревью ИБ.

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

Закончим эту короткую неделю простенькой задачкой с подвохом, которую я люблю задавать на своих тренингах "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. Тот, кто знает ответ с моего тренинга просьба не учувствовать ;)

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

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

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

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

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

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

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

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

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

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