Частой проблемой при запуске/эксплуатации кластеров 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.

Недавно, заканчивая отчет по аудиту для клиента, а именно раздел про 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 с парой десятков сотрудников =)

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

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

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

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

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

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

Если вам нужно собирать 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.

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

Несколько дней назад вышел 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.