Совсем недавно AWS релизнула новый функицонал – EKS Pod Identity. Фича призвана упростить предоставление доступа к AWS для Pods. Более подробно о том как это работает под капотом можно почитать тут.

Одно из преимуществ Pod Identity заключается в том, что гораздо проще понять, какой Pods имеет доступ к определенной роли в AWS - достаточно просто вызвать ListPodIdentityAssociations. В отличие от этого, IRSA требует от вас:

1) Найти все роли IAM, которые имеют доверительные отношения с провайдером OIDC кластера
2) Проанализировать условие в политике доверия роли на вложенном поле JWT
3) Выяснить, какие из ваших Pods соответствуют этому условию и, следовательно, могут принять роль

Еще одно преимущество – возможность настраивать всё через AWS API, без необходимости какого-либо внутрикластерного взаимодействия. В случае с IRSA вам нужно явно пометить Service Account с помощью label eks.amazonaws.com/role-arn.

Тут нельзя не упомянуть инструмент MKAT, о котором мы уже рассказывали на канале. Теперь он поддерживает EKS Pod Identity.

Подобного механизма в отечественных облаках до сих пор нет.

Проект CNCF Cloud Native Interactive Landscape обновился и получил версию 2.0!

По прежнему гигантский и ребята перестали гнаться уместить его на один экран и более удобно разместили на странице, добавив различную статистику, более удобные фильтры и инструкцию по работе с этим landscape.

Kyverno прошел third-party аудит, проводимый компанией Ada Logics. Прежде всего главными целями аудита были:

1. Определить модели нарушителя для Kyverno
2. Провести ручной аудит кода на предмет уязвимостей
3. Оценить фаззинг Kyverno на предмет соответствия моделям угроз
4. Оценить риски цепочки поставок Kyverno в соответствии с SLSA

В ходе ручного аудита кода компания Ada Logics обнаружила 10 проблем безопасности. Четыре из них имели первопричину в Notary, который не был выпущен до начала аудита. Одна из проблем была обнаружена в сторонней зависимости от Kyverno и была исправлена в проекте Cosign.

Благодаря самой критичной баге из найденных, CVE-2023-47630 злоумышленник может заставить пользователя Kyverno непреднамеренно использовать недоверенный image.

В общей сложности в ходе аудита было выявлено 6 CVE. Все они исправлены в версии 1.11

Более подробно с самим отчётом можно ознакомиться по ссылке тут.

Недавно поучаствовал в онлайн-митапе SafeCode 2023 на тему "Обзорная прогулка по инструментам AppSec". Там была дискуссия вообще про текущие проблемы AppSec и дальнейшее его развитие. Как по мне получилось очень интересно. Я вспомнил времена когда еще специализировался на поиске уязвимостей в бинарных приложениях, реверсе, фазинге! Конечно, аспект безопасности контейнеров нами не был оставлен без внимания - без этого сейчас никуда ;)

Видео можно посмотреть тут.

В рамках KubeCon NA 2023 (Chicago) бала секция Lightning Talks и там был доклад "Why Service Is the Worst API in Kubernetes, & What We’re Doing About It" (слайды, видео) - всего 6 мин!

Согласны с этой мыслью? Или у вас есть свой кандидат на звание worst API in Kubernetes ?)

P.S. Кстати ресурс Service один из старейших в Kubernetes

Rory McCune запустил новый цикл статей под названием Kubernetes security fundamentals. По сути это можно считать логическим продолжением статей из цикла Container security fundamentals (которые мы тоже освещали на канале – 1,2,3,4,5). Первая статья про API Security.

Данная статья посвящена основам безопасности Kubernetes, с фокусом на безопасности API компонентов. Kubernetes состоит из различных компонентов, предоставляющих API, и обеспечение их безопасности является важной частью общей безопасности кластера.

В статье отдельно отмечается важность безопасности kube-apiserver, etcd и kubelet, обсуждая их открытые порты, возможные уязвимости и рекомендации по улучшению безопасности.

Must have для начинающих погружаться в безопасность Kubernetes!

Наш хороший товарищ, постоянный читатель канала и активный пользователь CNI Cilium недавно поделились с нами интересным моментом о котором как нам показалось мало кто знает, но многих может затронуть.

И так, при использовании в инфраструктуре DNS-based NetworkPolicy и при проблемах с cilium agent, который как раз и отвечает за работы с DNS, все сессии приложений к которым применена такая NetworkPolicy теряют свои сессии!

По этому поведению даже есть отдельная issue - "Cilium agent restart causes dns requests failure #21059". При этом решения по ней по сути не будет - ответ звучит следующим образом: "That is the expected behavior in Cilium OSS. Some enterprise editions offer HA of FQDN policy enforcement."

P.S. Интересно если им соответствующий MR сбросить, то они cмерджат или точно также ответят?)

Сегодня хотим поделиться с вами плейлистом Container Security Fundamentals – видео, созданные по мотивам цикла статей от Rory McCune (1,2,3,4,5). В них рассматриваются все те же темы, что и в статьях – Linux Namespaces, Linux Capabilities, Seccomp, AppArmor.

Возможно кому-то будет легче воспринимать информацию с видео и динамически изменяющейся картинкой ;)

По рекомендациям друзей изучил доклад "The Attacker Perspective - Insights From Hacking Alibaba Cloud's Managed K8s Environments" (слайды, видео).

Под прицелом исследователей 2 managed сервиса: AnalyticDB и ApsaraDB RDS для PostgreSQL

Хорошее умение выполнять свой собственный код на PostgreSQL, который подробно описан в статье "The cloud has an isolation problem: PostgreSQL vulnerabilities affect multiple cloud vendors", и ряд грубейших мисконфигов привели их к возможности получить доступ к данным БД других пользователей!

На самом деле ребята поднимают серьезный вопрос про tenant isolation. И даже для этого релизнули специальный фреймворк Peach.

После изучения этого всего сразу же задумываешься, а насколько хорошо вообще изолированы у облачных провайдеров предлагаемые ими managed сервисы и сколько еще будет найдено таких атак позволяющих добраться до данных рядом работающих клиентов ...

P.S. Так напоминает атаку Azurescape ;)

Вышла версия 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 правил.