Вышла версия Kubernetes 1.29 под кодовым названием Mandala! Если говорить о security изменениях, то это в первую очередь:

- Structured Authorization Configuration. Упрощается аудит безопасности, что облегчает применение и проверку политик доступа.
- Bound Service Account Token Improvements. Повышает безопасность токенов, привязывая их к конкретным экземплярам Pods.
- Reduction of Secret-Based Service Account Tokens. Фича направлена на уменьшение зависимости от долгоживущих токенов учетных записей.
- Ensure Secret Pulled Images. Образы всегда будут извлекаться с использованием секретов Kubernetes для использующего их Pod.
- Support for User Namespaces. Фича поддерживает пользовательские пространства имен и повышает безопасность Kubernetes.
- Structured Authentication Configuration. Новая фича дает более удобный и безопасный подход к управлению аутентификацией.
- KMS v2 Improvements. Эта фича стала стабильной и направлена на улучшение плагина KMS.

Перед началом выходных и концом 2023 года давайте посмотрим на Hype Cycle for Application Security 2023 от Gartner.

Смотря на данную кривую и вспоминая эту же кривую для Application Security от 2021 года (рассматривали тут), можно обратить внимание что тема Kubernetes security каким-то чудесным образом "вернулась" на пик хайпа!!!

Мы не супер знатоки Hype Cycles, но удивительно что у них технологии возвращаются на пик хайпа и при этом даже сами названия меняются (ранее пункт назывался Container and Kubernetes security). По идее все должно быть единообразно, а так как будто они собственные же прошлые отчеты не смотрят)

А что вы думаете на этот счет и какие интересные изменения увидели тут вы?

Наша команда Luntry недавно поучаствовала в подкасте SafeCode Live на тему "Контейнерная безопасность"!

Обсуждали и делились мнениями на абсолютно разные аспекты контейнерной безопасности. Конечно, успели обсудить не все (да это и не возможно), но получилось интересно)

Выпуск уже доступен на разных площадках:
— YouTube
— Apple Podcasts
— Яндекс Музыке
— ВКонтакте

Всем приятного прослушивания и хороших выходных!

Начинаем эту неделю с атакующей тематики, а именно с доклада "Orchestrate This! Kubernetes Rootkit" (слайды), который был представлен на прошедшей конференции BlackHat Europe 2023.

Как вы уже могли догадаться, речь пойдет container-based rootkit, главная цель которых скрыть вредоносные контейнеры от container runtime.

Основные принципы работы Kubekit:

- изменение ответов Kubernetes API для сокрытия развернутых Pods с полезной нагрузкой
- скрывает userspace компоненты для парсинга и модификации JSON-ответов в реальном времени
- скрывает целевой Pod от kubectl get pods, а также от всех других запросов, использующих схему API /pods

Однако, тут нельзя не упомянуть, что сам руткит подгружается с помощью модуля ядра, а для этого в контейнере должна быть capabilities CAP_SYS_MODULE. Ко всему прочему, Kubekit должен быть запущен на Master Node. Забавно, но чтобы обнаружить руткит, вам нужен другой руткит – в виде модуля ядра или eBPF программы =)

P.S. – На канале мы уже писали пост на похожую тематику.

Сегодня мы хотим поделиться с вами нашими слайдами с доклада «EDR vs Containers: актуальные проблемы» с конференции SOC-Forum 2023. Данное исследование это совместная работа команды Luntry и команды Solar 4RAYS.

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

Особое внимание уделено сигнатурного способу детектирования. На реальных примерах атак демонстрируется неэффективность данного способа в контейнерных средах. Все это на примерах для правил Falco, НО это применимо и к другим сигнатурным движкам таким как Tracee, Tetragon, которые в свою очередь могут лежать в основе других решений (про них есть другие исследования). Опять же повторимся, что это все именно про сигнатурный способ детектирования, а не конкретные проблемы Falco!

P.S. Видео выступления можно найти тут, пока отдельным роликом оно не доступно.

На канале мы не раз [1, 2, 3] рассказывали про distroless образы, вроде Wolfi, Chainguard или Google. Но там речь шла только про базовые образы, которые можно использовать для своих нагрузок.

Но не стоит забывать, что Chainguard выпускает не только базовые образы, но и distroless images для конкретных k8s-native (и не только) проектов. Например, среди большого разнообразия images можно найти distroless образы для таких проектов как Calico, Cilium, Istio, Hubble, Kube-bench и ещё десятки других проектов, вроде, Nginx, Redis, Nats, Envoy! Это поможет не только уменьшить размер образа, но и значительно ограничить возможный attack surface.

В конце сентября, совсем незаметно вышла новая версия CIS Kubernetes Benchmark с номером 1.8. Напомним что версия 1.7 была выпущена в феврале. В документе в разделе Appendix: Change History можно посмотреть историю изменений и там нет ничего критически нового. В качестве целевой версии указан Kubernetes 1.27, но смело может быть использован с любой другой.

Очень сильно рекомендуем хотя бы раз в жизни полностью ознакомиться с данным документом, а не просто запускать разные OpenSource сканеры и ориентироваться на их результаты. После ознакомления вы поймете сколько там всего важного не реализовано или реализовано частично. Конечно, вы найдете и ряд огрехов в самом benchmark, но это отдельная история и по ней можно (и мы уже в процессе) сделать отдельный доклад ;)

Пятничный пост будет про самую громкую новость этого года в Cloud Native области (по нашему мнению) - это покупка компании Isovalent (разработчик CNI Cilium, Hubble, Tetragon) другой широко известной американской компанией Cisco (похоронившей далеко не одну приобретенную компанию, и не хорошо отметившейся у нас в последнее время).

Помните такой легендарный IDS Snort ? Где он сейчас? Как он поживает ?

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

Что вы думаете об этом всем? Спасет ли CNCF ? Будете смотреть CNI Calico на eBPF или может быть CNI Antrea на Open vSwitch?

P.S. Отличная пятничная тема подискутировать ;)

Наши друзья из VK Cloud недавно пригласили нас поучаствовать в качестве экспертов по Kubernetes и по безопасности в нем в их исследование "State of Kubernetes"!

Мы с радостью приняли в этом участие и высказали свое мнение по различным его итогам - в первую очередь, конечно, по моментам связанным с безопасностью)

Приятно чтения и все хороших выходных!

P.S. На следующей неделе начнем подводить итоги года =)

Внимательный читатель нашего канала знает, что на SOC Forum 2023 от нашей команды Luntry было не одно, а два выступления. И второе выступление это доклад "SOC в контейнерах" (слайды)! Надеемся что все оценили оригинальность названия ;)

В рамках данного доклада поднимаются темы того что сильно мешает Security Operations Center (SOC), а что ему наоборот играет на руку при работе с контейнерными окружениями под управлением Kubernetes.

P.S. А видео можно найти тут.

И как и планировали давайте начнем подводить итоги уходящего 2023 года как данного канала, так и нашей команды Luntry!

В этом году наша команда участвовала в 36 публичных активностях по безопасности контейнеров и Kubernetes:
- 19 технических докладов
- 10 круглых столов и дискуссий
- 4 вебинара
- 3 подкаста

Для больших компаний эти цифры могут быть не столь впечатляющие, но если взять во внимание, что:
1) в 2021 было 7 докладов, в 2022 было уже 12, то мы очень хорошо растём)
2) и это все по одной узкой теме в которой мы специализируемся - безопасность контейнеров и Kubernetes!
3) запустили собственную конференция по БЕзопасности КОНтейнеров "БЕКОН"

То больше чем мы в этой теме никто не копает (пишет,создает, защищает, аудирует/пентестит) =)

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

P.S. Мы продолжаем расти и всегда в поиске крутых Go-разработчиков, если что пишите ;)

Статья Kubernetes RBAC: paths for privilege escalation описывает пути повышения привилегий RBAC в Kubernetes. В статье рассматриваются следующие техники:

- Mounting a Service Account Token
- Obtaining Access to a Cluster node
- Secret reading
- Brute-Forcing Secrets
- Impersonation
- Binding Roles
- Binding Clusterroles within a namespace
- Binding Clusterroles cluster-wide
- Escalate

Будет довольно полезно при проведении пентеста, когда у имеющегося вас ServiceAccount есть достаточные права. Автор статьи также приводит примеры нужных запросов к kube-api server с помощью curl – на тот случай если под рукой нет kubectl. Об этих и других техниках можно почитать в официальной документации Kubernetes и других постах с нашего канала [1, 2, 3]

P.S – Когда мы у себя в Luntry реализовывали функциональность поиска опасных привилегий при аудите RBAC у нас получилось порядка 40 правил.

Продолжаем подводить итоги 2023.

Как вы знаете наша команда делится информацией о безопасности контейнеров, Kubernetes и смежных тем по крайней мере раз в будний день. В итоге, за 2023 год с учетом того что в нем 247 рабочих дней, у нас ориентировочно будет около 330 сообщений за год! То есть порой писали и чаще, чтобы поделиться с вами интересными находками и мероприятиями. Ну вы же не против?)

В следующем году так же будем поддерживать свой график!

P.S. Это сообщение 325 и планируется еще около 5-6

А сегодня давайте поиграем в игру!

Уважаемые читатели расскажите пожалуйста нам зачем вы (или не вы) сканите хостовую ОС, на которой работает кластер Kubernetes, на известные уязвимости в пакетах? Какой сценарий атаки вы в таком случае рассматриваете? Какую модель нарушителя берете в рассмотрение? (Задачу прибавить работы коллегам не рассматриваем и "так написал коллега до меня" тоже!)

Лично мое мнение, что это максимально бесполезное дело в кластере Kubernetes и у меня есть следующие аргументы на этот счет:
1) Контейнеры используют пакеты из образа и хостовых никак не касаются
2) Ни один разработчик платформы Kubernetes не рассматривает вообще сценариев, что при работе с кластером человеку нужно ходить на Nodes, тоесть прямых доступов не надо. Общался с ребятами из Deckhouse, Штурвал, OpenShift, Talos. В сценариях с отладкой помним про kubectl debug на пример.
3) Любой пентестер знает, что если попал на тачку где работает Container Runtime Socket (а он есть на всех Nodes!), то все Game Over - повышение привилегий у тебя в руках.
4) Сценарии что у вас еще просто так запускается не контейнризированный софт (о котором не известно Kubernetes) не берем во внимание - это уже совсем другой класс проблем (и по мне более серьезный). И вы скорее напортачите с распределением ресурсов (ведь Kubernetes не учтет эту нагрузку если вы в ручную это не занесете) и в один день там просто случиться авария.

Теперь ваш ход =)

P.S. Игра называется Риск ориентированный подход! Игру придумали не мы ;)

Сегодня в центре нашего внимания будет заметка "Don’t pin base image exact version tags" одного из наших читателей, который скидывал нам ее как-то в комментариях. Эта заметка лично мне очень запомнилась, потому что в ней рассматривается не популярная точка зрения на одну уже устоявшеюся задачу/проблему. И с этой точкой зрения (аргументированной) можно как соглашаться, так и нет, но самое важно, как по мне подобные заметки заставляют шевелиться серое вещество в наших головах... А не просто слепо следовать устоявшимся правилам, регламентам, мнениям больших компаний и авторитетов индустрии. Я считаю, что если ничего не ставить под сомнение и не пытаться находить новые пути/решения, то и никого прогресса никогда не будет - будем просто ходить про протоптанным дорожкам и переливать воду в решете ...

Давайте подискутируем в комментариях!

P.S. Наш вчерашний пост был из этой же категории.

Немного цифр о канале по этому году.

Спасибо что нас читаете, комментируете, реагируете, пишите в личку, предлагаете идеи!

Спасибо за вашу активность)

P.S. Данные по прошлому году тут.

Заканчиваем эту неделю (и год) постом про повышением привилегий в GKE кластере через FluentBit и Anthos Service Mesh. Авторы рассматривают кейс Second-Stage Cloud Attacks – это тип атаки, при котором злоумышленник уже получил определенный уровень доступа к кластеру Kubernetes.

Можно выделить следующие шаги в этой атаке:

0) Злоумышленник получает RCE в контейнере FluentBit
1) Воспользовавшись смонитрованной директорией /var/lib/kubelet/pods получает доступ к ServiceAccount токенам
2) Используя избыточно высокопривилегированные права в кластере, которые назначены Anthos Service Mesh злоумышленник создает полезную нагрузку в неймспейсе kube-system используя и одновременно воруя другой высокопривелигрованный ServiceAccount – clusterrole-aggregation-controller.
3) Cluster-Admin profit!

Мисконфигурация GCP-2023-047 уже исправлена:

- убрали маунт /var/lib/kubelet/pod
- ограничили права в кластере Anthos Service Mesh

Команда нашего канала и вся команда Luntry хочет всех вас поздравить с наступающим Новым Годом! И если все личные пожелания - вы скорее всего получите от родных, близких и друзей, то мы направим наши поздравления в профессиональное русло)

В Новом Году мы желаем вам поменьше заниматься бестолковыми рутинными задачами, а заниматься интересными, креативными задачами, которые помогут вам расти как специалисты в своей области и становиться лучше всей вашей компании.

Желаем вам, чтобы ваши контейнерные окружения с этапа архитектуры предусматривали механизмы безопасности (а не по остаточному принципу или в виде заплаток поверх всей системы), а политики безопасности учитывали специфику контейнеров, Kubernetes и соответствующие модели угроз (а не использовались со времен Windows 98)!

В общем, чтобы технологический прогресс и здравый смысл не убегали от вас вперед ;)

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

Надеемся, что все хорошо провели праздники, отдохнули и теперь готовы как губка впитывать новую информацию, учиться, развиваться вместе с нами!

Мы совсем недавно на нашем сайте Luntry привели в порядок раздел Исследования, который содержит абсолютно все наши публичные исследования/выступления (как в формате слайдов, так и видео) с 2021 года (мы в теме, когда это еще не было мейнстримом)!

На наш взгляд этот раздел может быть хорошим стартом для новичков (и не только), которые погружаются в тему безопасности контейнеров и Kubernetes!

P.S. Если у вас есть еще идеи как сделать этот раздел более удобным для обучения, то предлагайте! Так у нас в планах еще добавить теги ко всем работам ;)

В версии Kubernetes 1.29 и более поздних обнаружено интересное изменение для кластеров, созданных через Kubeadm. Оказалось, что admin.conf больше не является членом группы system:masters из-за изменений, внесенных в Kubeadm, включая введение нового super-admin.conf. Теперь Kubeadm генерирует два файла: оригинальный admin.conf и новый super-admin.conf. admin.conf был изменен таким образом, чтобы иметь права cluster-admin но так, чтобы они могли быть отозваны путем удаления прав этой группы, а super-admin.conf остался членом system:masters, права которого нельзя отозвать.

Более подробно об этом можно почитать в статье "When is admin not admin?, when it's super-admin!" , за авторством Rory McCune.

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

Сегодня рассмотрим тему, которой мы не касались ни разу за все время существование данного канала (а это почти 4 года) - шифрование образов контейнеров! Вряд ли вы вообще о таком задумывались, но если касались темы Confidential Containers/Computing, то это вам знакомо.

Основным путеводителем для нас тут будет презентация "Advancing image security and compliance through Container Image Encryption!". Так для практического ознакомления с темой шифрования образов можно использовать:
- ocicrypt
- imgcrypt
- podman
- skopeo
- buildah

А для расшифровки настроенные:
- Containerd
- CRI-O

Кстати, можно шифровать конкретные слои (а не весь образ), на пример, с вашими ML модельками и контролировать их запуск только в вашей контролируемой среде и нигде более.

P.S. Есть кто уже шифрует?)