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

Ежегодное соревнование хакеров Pwn2Own, известное тем, что исследователи демонстрируют 0-day эскплоиты и компрометируют Tesla Model 3, Windows, macOS, Ubuntu и различные другие системы, приложения и устройства, в этом году расширяется и пополняется новой категорией – Cloud-Native/Container category.

Организаторы готовы выплатить $60,000 (в рамках китайского TianfuCup 2022 цена такая же) исследователям при условии, что их эксплоит должен быть запущен внутри контейнера/microVM и в результате совершить побег на хост (container escape).

$30,000 выплатят тому, кто сможет использовать уязвимость в кодовой базе gRPC для получения возможности выполнения произвольного кода.

Однако, это не единственные мероприятия, где можно заработать деньги за поиск уязвимостей в containers/Kubernetes. За баги найденные в соревнованиях kCTF и kernelCTF от Google (которые идут круглый год и без остановки) тоже выплачиваются баунти.

P.S. Как правило, на черном рынке подобное дороже в 5-10 раз в зависимости от спроса.

Перед прочтением новой статьи "Better Together: Real Time Threat Detection for Kubernetes with Atomic Red Tests & Falco" у нас были (хоть и маленькие) надежды на что-то интересное, но они были быстро развеяны ...

Что можно узнать из статьи:
1) Как Atomic Red Team запустить в виде Kubernetes Deployment manifest
2) Чтобы не отставать от атакующего нужно постоянно писать свои правила: "revising the executed techniques and crafting custom rules." , "This iterative process aims to extend MITRE ATT&CK coverage"
3) Чем больше правил, тем больше шансов что-то поймать (и пускай для этого даже лучше ставить не последнюю версию Falco): "we can install Falco via Helm on a fixed version prior to the segregation of rules into different rules feeds" (а про вычислительные ресурсы при таком раскладе писать не будем)
4) Проще искать, когда знаешь что искать: "To ignore this noise, let’s instead just check for the specific Falco rule we are looking to detect".
5) Правил из коробки никогда не бывает достаточно: "Again, we have an [out-of-the-box rule]" , "CUSTOM RULE".
6) Пост вроде про Kubernetes, но для убедительности все будем показывать из темы хостовых ОС: "Adversaries may clear system logs to hide evidence of an intrusion. macOS and Linux both"
7) Но где-то глубоко внутри самих описаний правил все же будем признавать, что сначала надо разобраться как у нас вообще все работает: "However, it requires customization after profiling your environment."

В общем какая-то очень слабая статья получилась у Developer Advocate из Project Falco - хотя опять же все претензии выше не к конкретному решению, а к самому сигнатурному подходу, что мы уже не раз рассматривали. На пример, в нашем докладе. «EDR vs Containers: актуальные проблемы».

В последнем релизе Kyverno 1.11 компания Nirmata, помимо обновленной версии, представила также инструмент для тестирования Kubernetes операторов – chainsaw.

Изначально, в качестве инструмента для тестирования Kubernetes opertator использовался KUTTL, но довольно быстро разработчики столкнулись с рядом ограничений и нехваткой нужного функционала. Так и появился chainsaw.

Chainsaw предоставляет декларативный подход к тестированию операторов и контроллеров Kubernetes. Это значит, что само наполнение тестов описывается тоже декларативно, с помощью YAML.

Помимо этого, chainsaw может встраиваться в пайплайн, что несомненно является плюсом.

4 марта в Москве в рамках DevOpsConf 2024 наша команда Luntry выступит с докладом "Безопасность Kubernetes кластеров: Вредные советы".

У всех у нас есть какой-то опыт, и мы всегда стараемся переносить его с собой повсюду. Так, на пример, велик соблазн перенести свой опыт обеспечения безопасности Linuх/Docker инфраструктур (не говоря уже о Windows) на Kubernetes кластера. При этом, к сожалению, до конца, не понимая самой природы Kubernetes. И это может быть ваш личный опыт или опыт кого-то из коллег, которые писали корпоративный стандарт с “лучшими практиками” по безопасности в Kubernetes, а вам ему уже необходимо следовать ... К сожалению, то, что работало раньше и где-то очень полезно, на практике не эффективно, бесполезно или вообще может привести к печальным последствиям.

Рассмотрим, что в теории звучит очень полезно, а на практике приводит к авариям, падениям приложений и Kubernetes кластеров.

И в рамках этого проведем конкурс и разыграем 1 проходку на конференцию. Для этого в комментариях к этому посту напишите какие самые странны, бесполезные, смешные требования вы встречали в процессе работы в корпоративных стандартах, ТЗ и т.д. по теме безопасности контейнеров, Kubernetes, DevSecOps =) Через неделю мы выберем победителя!

P.S. И для все у нас есть еще специальный промокод со скидкой 5% - k8security

Исследователи из Wiz опубликовали базу данных инцидентов Cloud Security – Cloud Threat Landscape!

Изначально, база была исключительно внутренней, создавалась для аналитики угроз и поддерживалась собственными силами. Однако, эту кладезь знаний решили опубликовать. База содержит в себе более 100 задокументированных инцидентов в области Cloud Security, профили злоумышленников, используемые ими инструменты, техники и маппинг на Mitre Tactic.

Кстати говоря, если верить этой базе, то Kubernetes является most targeted технологией из всех представленных там.

Несомненно, этот ресурс будет полезен Threat Intelligence специалистам, изучающих Cloud Threats, SOC аналитикам, и в целом всем, кто погружен в тему Cloud Security.

Исследователи из Orca Research Pod обнаружили опасную мисконфигурацию в GKE, которая может позволить злоумышленнику с любой учетной записью Google взять под контроль неправильно настроенный кластер Kubernetes, что потенциально может привести к серьезным инцидентам безопасности, таким как криптомайнинг, отказ в обслуживании и кража конфиденциальных данных.

Мисконфигурации дали название Sys:All ввиду вероятного широко распространенного заблуждения, что группа system:authenticated в GKE включает только проверенные и детерминированные идентификаторы, тогда как на самом деле она включает любую аутентифицированную учетную запись Google (в том числе за пределами организации).

По минимальным оценкам, ресерчеры обнаружили 250 000 активных кластеров GKE, сотни из которых содержали секреты, позволяющие осуществлять lateral movement и получать доступ к конфиденциальным данным. Подробнее об этих случаях можно почитать здесь.

Kyverno, в свою очередь, оперативно выпустила политику, закрывающую этот мисконфиг.

Распределение полезных нагрузок по 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.

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

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

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

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

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

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

Поскольку новая уязвимость 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. Если у вас уже сейчас есть интересующие вас вопросы, то пишите в комментариях - рассмотрим их на вебинаре!