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

В декабре, на прошедшей конференции KubeDay India 2023 был представлен доклад Sign, Attest, and Verify! A Practical Guide for Software Supply Chain Security - Anushka Mittal & Vishal Choudhary, Nirmata.

Докладчики рассказывают о проблеме целостности образов и о том как её можно решить. Для этого они используют Notary и Cosign, чтобы подписать и верифицировать образ, и Kyverno, чтобы ограничить недоверенные образы в нагрузках Kubernetes. В конце доклада авторы наглядно демонстрируют эти возможности в небольшом демо.

Слайды с доклада можно найти тут, а видео с выступления здесь.

Давненько мы ничего не писали про нашу любимую eBPF технологию, которую мы активно у себя в Luntry используем. И вот, вышла замечательная статья "BPF Memory Forensics with Volatility 3", позволяющая заглянуть в недра данной технологии. Но сразу отметим что не со стороны разработчика, а со стороны исследователя, который на руках исходных код может и не иметь ... То есть будем анализировать скомпилированный код и память. И все это с помощью утилиты Volatility 3. Если быть еще быть более точным, то статья будет больше полезна вирусным аналитикам, что хотят исследовать malware, rootkit на базе eBPF (писали и рассказывали уже о таком тут, тут и тут).

Вообще, на самом деле нужно быть очень внимательным даже при использовании OpenSource проектов на базе eBPF, так как это большие возможности и права в системе (на пример, чаще всего это привилегированные контейнеры), и нужно очень хорошо понимать что и как там делается. Так что читайте исходный код)

В январе 2024 года AWS CloudShell получил новую возможность: запуск контейнеров Docker. Это заинтересовало автора статьи "Deep dive into AWS CloudShell", поскольку Docker-in-Docker обычно подразумевает наличие привилегированных контейнеров. В статье автор рассказывает можно ли всё таки получить container escape в этом окружении, а также знакомит читателей с тем, что из себя представляет внутреннее устройство CloudShell.

P.S – Интересно, что раньше CloudShell использовал Firecracker microVM, но сейчас перешел на обычные EC2 инстансы. Как вы думаете, почему так?

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

Задача стояла в закручивании гаек (настройки SecurityContext, limits и т.д.) для волтовых init и sidecar контейнеров, чтобы на них не кричал PolicyEngine (а это считай на все нагрузки, где они используются) и как следствие они соответствовали внутренним стандартам компании. Использование PodSecurityContext (не путайте с SecurityContext) не решало задачи и задействовать механизм исключений не очень то и хотелось.

При этом как вы понимаете задача усложняется тем, что их самих в исходных ресурсах Pods нет и они уже добавляются в процессе выкатки через mutating admission webhook ...

В итоге, решением оказалось использование аннотаций vault.hashicorp.com/agent-init-json-patch и vault.hashicorp.com/agent-json-patch =) Берите и пользуйтесь!

P.S. Задача, кстати, очень напоминает задачу для ServiceMesh Istio, которую мы рассматривали тут.

P.S.S. Мы вам этого не говорили, но можно через этот механизм встраивать и backdoors и разные другие нехорошие вещи - придумать уже можете сами ;)

Kubetools – репозиторий с самой большой подборкой Open Source инструментов для Kubernetes на любые случаи жизни.

Все тулзы поделены на категории. Если говорить об инструментах в security направлении, то в первую очередь будут интересны следующие категории:

- Security Tools
- Network Policies
- Service Mesh
- Observability

Что интересно, наш инструмент MTKPI для проведения пентеста Kubernetes кластеров тоже попал в эту подборку! Если вы ещё не знакомы с ним, то советуем ознакомиться – репозиторий, слайды, видео.

На канале мы уже рассказывали про некоторые подборки – например по krew security plugins.

Современные микросервисы состоят на 60-80% из стороннего кода и отчет "The State of Software Supply Chain Security 2024" будет как никогда кстати, чтобы разобраться что и как у нас сейчас с цепочками поставки.