k8s (in)security

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

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

Совсем недавно 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.

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

Недавно наткнулся на следующий твит от Ивана (в котором он комментирует этот твит от Келси) и он меня навел на следующую мысль (как по мне хорошая, дискуссионная - как раз для пятницы).

Мы привыкли, всегда говоря о Kubernetes, говорить про оркестратор, фреймворк, платформу, НО по сути на сегодняшний день это же и в каком-то роде определенный СТАНДАРТ. При этом, честно говоря, в этом стандарте есть и хорошее, и плохое (как и в любом стандарте). И у всех одинаковые боли, проблемы в инфраструктуре и, по сути, одинаковые решения, которые можно прийти и обсудить в сообществе у которого все тоже самое и они уже это проходили или банально найти специалистов. Такого бы не было если у вас кастом. При этом это касается любой темы и направления: reliability, observability и security.

Как по мне стандартная проблема, лучше специфичной =)
А что вы думаете на этот счет?

Всем хороших выходных!

В Москве прошел HighLoad++ 2023 и мне там довелось побывать ведущем одного из залов, где основная тематика была Security и Platform engineering. Если с первой темой все более-менее понятно (сюрпризом было только упоминание на слайдах нашего решения Luntry в контексте поведенческого анализа), то на второй теме хотелось бы остановиться и поделиться своими наблюдениями (IMHO):
1) У зрелых IT компаний есть зрелые продвинутые платформы, полируемые уже не 1 год
2) Platform team в таких компаниях становиться "тесно" в рамках одной компании со своим продуктом
3) Данные Platform в разном виде: Dev Platform, Self-hosted облачные платформы как на базе Kubernetes, так и нет хочется/планируется выводить во внешний Мир

Так что я думаю, что в следующем году кроме изобилия различных дистрибутивов Kubernetes, начнут появляться и различные платформы для разработчиков и self-hosted облаков...

И да, я как один из участников программного комитета конференции DevOpsConf призываю всех присылать заявки (до 15 декабря) на доклады нам! Я лично с радостью рассмотрю и помогу с заявками по теме Security, Kubernetes и Platform engineering ;)

Статья с говорящим названием "Rootless Containers - A Comprehensive Guide" расскажет все о rootless контейнерах и врятли у вас останутся еще какие-то вопросы по данной теме после ее изучения.

В качестве Rootless контейнеров приводятся и частично рассматриваются:
- Docker rootless-mode (c 19.03)
- Podman rootless-mode
- BuildKit rootless-mode
- LXC unprivileged-mode
- Apptainer userns-mode or fakeroot-mode

Не обошлось тут и без рассмотрения темы User Namespaces ;)

29 ноября 2023 года в 11:00 наша команда Luntry примет участие в online эфире AM Live по теме "Защита контейнерных сред"! Дискуссия будет состоять из 3-х частей:
1) Угрозы и риски безопасности для контейнерных сред
2) Защита контейнерных сред на примере Kubernetes
3) Прогнозы

Подключайтесь, смотрите, потом можно будет еще в комментариях обсудить поднятые вопросы)

Казалось бы, инструмент IceKube – что-то новое и интересное в мире Kubernetes Security, но как бы не так.

Тулза умеет искать возможные attack path в кластере от самых минимальных привилегий до cluster-admin. Результаты своей работы отображает в графовой БД – Neo4j. На этом моменте нельзя не упомянуть инструмент, о котором мы рассказывали совсем недавно, и который, очевидно, был взят за основу – KubeHound.

Суть работы у IceKube точно такая же, даже вектора attack path одинаковые и ничего нового авторы не придумали. Но всё-таки отличия у инструментов есть – написаны на разных языках и IceKube имеет пару правил, относящихся к Managed Kubernetes, а именно AKS и AWS.

Для тех, кто хочет детальнее изучить инструмент, посмотреть на примеры и ознакомиться с проблематикой – рекомендуем статью "IceKube: Finding complex attack paths in Kubernetes clusters" от авторов тулзы.

Так как нашей команде Luntry часто приходится участвовать в различных проектах по безопасности Kubernetes систем: аудиты, пентесты, архитектурные проекты. То приходится порой думать о некоторых моментах, к которым просто так не придешь, никогда об этом не задумываясь. Одним из таких последних моментов был момент, когда требовалось понять стоит ли определенные высокопривелигерованные микросервисы (там хороший SA) располагать в одном Namespace или расселить на разные. При решении этой задачи как раз и пригодился наш атакующий опыт.

Смысл заключается в том, что если у злоумышленника на Node есть возможность создать Pod в таком Namespace (где и эти высокопривелигерованные сервисы), даже с учетом того что стоит множества правильных политик PolicyEnginе (против Bad Pods и тд), то у него все равно остаётся возможность смонтировать внутрь такого Pod интересующий его SA из того же самого Namespace! Далее когда он смонтируется туда, то можно смело забирать его с Node ...

Как митигейшены можно сделать следующее:
1) Чтобы уменьшить риск компрометации, критичные сервисы разделать по Namespaces
2) Namespaces c критичными/инфраструктурными сервисами привязывать только к определенным инфраструктурным Nodes
3) Писать политики PolicyEngine, которые проверяют использование критичных SA, только в определенных сервисах

P.S. Еще была крутая идея для атаки - все это провернуть через StaticPod, но там нельзя ссылать на другие ресурсы (на тот же SA)…

P.S.S. Ближайшие дни мы на HighLoad++ 2023 Msk и будем рады пообщаться лично =)

Недавно давали интервью по поводу безопасности в Kubernetes и концепции ZeroTrust. Почитать можно тут, а свое мнение оставить в комментариях к данному посту ;)

Так предотвращать, дешевле чем расследовать =)

Всем хороших выходных!

Kubelet Serving Certificate Approver – репозиторий с контроллером, который аппрувит kubernetes-io/kubelet-serving CSR, используемый kubelet для обслуживания TLS endpoint. Проект поддерживает версии Kubernetes 1.22 - 1.28.

Контроллер может быть полезен, если:

- вы хотите установить безопасное общение с endpoint kubelet (с точки зрения СА)
- подписанные serving сертификаты рассматриваются сервером API как действительные сертификаты обслуживания kubelet
- не хотите использовать флаг --kubelet-insecure-tls во время установки metrics-server

К слову сказать, оригинальная идея принадлежит проекту kubelet-rubber-stamp, который не поддерживается уже 3 года.

Совсем недавно прошла конференция KubeCon + CloudNativeCon North America 2023 и уже стали доступны и слайды и видео на их канале. Как всегда там море всего интересного!

Пока отдельно выделим один доклад "A Wind of Change for Threat Detection" от ребят из Apple, посвящённый проблемам rule-based detections в runtime в контейнерных средах. Как мы и говорим уже не один год все идет к поведенческому анализу.

И отдельно стоит отметить в первые проходившую Multi-TenancyCon NA 2023, которая отдельно проводилась в эти же дни. И видно как тема правильной организации multi-tenancy становиться актуальной для большого числа компаний.

P.S. В комментариях пишите какие доклады больше всего понравились вам!

Заглянув в release notes к бета-версии Containerd v2, мы с радостью увидели изменение, запрещающее доступ к io_uring по умолчанию.

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

Помимо этого изменения, хотелось бы отметить ещё пару:

- Add support for userns in stateless and stateful pods with idmap mounts (KEP-127, k8s >= 1.27)
- Add support for user namespaces (KEP-127)

Наш хороший товарищ Павел Сорокин (вы могли его видеть среди докладчиков на нашей конференции БЕКОН) у себя на канале сделал замечательную серию очень технических постов про hostPID: true и --pid=host:

Часть 1
Часть 2
Часть 3
Часть 4

А именно он разбирается к каким последствиям может привести наличие данных параметров и какие механизмы безопасности (Yama, AppArmor) каким образом могут это ограничить.

Также можно вспомнить про замечательный репозиторий BadPods и там также глянуть эту тему ;)

В конце прошлой недели вышел Kyverno 1.11 с новыми возможностями:

1) Добавлен новый тип подправила validate.cel, позволяющий использовать выражения Common Expression Language (CEL) для проверки ресурсов.
2) Улучшения в Policy Report: теперь для каждого ресурса создается PolicyReport, который автоматически удаляется при удалении соответствующего ресурса. AdmissionReports и BackgroundScanReports теперь считаются эфемерными и очищаются после объединения в итоговые отчеты.
3) Обновления Notary: добавлена поддержка проверки аттестатов OCI 1.1.
4) Поддержка Cosign 2.0: теперь проверка Tlogs и SCTs включена по умолчанию и может быть отключена через атрибуты в политике.
5) Кэширование проверки образов для ускорения процесса.
6) Возможность очистки ресурсов через TTL label cleanup.kyverno.io/ttl. Присвоение метки ресурсу с необходимыми правами приведет к его удалению в указанное время.
7) Переработка CLI и новая схема тестирования.

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

Проект называется k8s-calico-networksets-controller и он по сути добавляет поддержку FQDN в NetworkPolicy от CNI Calico!

Вся магия происходит с помощью selector в NetworkPolicy с определённым label и через создание/обновление Calico NetworkSet.

Если вам не хватало поддержки FQDN в NetworkPolicy от CNI Calico, то это решение для вас)

P.S. Всем хороших выходных!

Напомним, что сегодня наша команда Luntry (достаточно в большом составе и оба авторы данного канала будут на сцене) будет на VK Kubernetes Conf! Там мы и доклад представим и в круглом столе про развитие Kubernetes поучаствуем (в следующем году ему будет 10 лет если отсчитывать от Initial release)!

Будем рады пообщаться лично =)

На недавно прошедшей конференции EnvoyCon был представлен довольно интересный доклад на тему security, а именно – Envoy Gateway End User Threat Model Report: Raising Awareness of Gateway API Security.

Также автор доклада поделился репозиторием созданным по мотивам доклада, где рассмотрел Compromised Proxy Scenario, Compromised Controller Scenario, нарисовал возможные деревья атак и приложил k8s ресурсы для воспроизведения своей демо из доклада

Мало кто знает, но в документации Google Cloud есть прям замечательная (и очень большая) библиотека правил для OPA Gatekeeper - их там порядка 90! При этом они идут с примерами как удовлетворяющих их ресурсов, так и нет (считай тесты).

Отличная библиотека для вдохновения и оценки собственного набора политик. При желании тоже самое можно перенести и на Kyverno.

С недавнего времени Kyverno теперь может валидировать не только Kubernetes, но и впринципе любые ресурсы. Мы уже рассказывали о возможностях Kyverno [1,2] и даже вкратце затрагивали проект json-validator, который скорее всего вылился в новый – kyverno-json.

Сейчас авторы предлагают использовать новый проект для валидации:

- Terraform files
- Dockerfiles
- Cloud configurations
- Service authorization requests

kyverno-json можно запускать как CLI, веб-приложение с REST API или использовать в качестве библиотеки Golang. Уже сейчас доступна небольшая библиотека политик для AWS, ECS и Dockerfile. Также есть возможность попробовать новый проект онлайн – по ссылке доступен playground.

Уже завтра стартует SOC Forum 2023, где наша команда Luntry представит 2 доклада. Также там у нас будет стенд с интересными подарками, которые можно получить за участие в небольшой игре/активности для которой мы приготовили вот такие карточки. Так что все кто будет на конференции - подходите, участвуйте, спрашивайте про безопасность контейнеров и Kubernetes!