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

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

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

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

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

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

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

В конце прошлой недели вышел 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 и новая схема тестирования.

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

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

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

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

Заглянув в 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)

Совсем недавно прошла конференция 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. В комментариях пишите какие доклады больше всего понравились вам!

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 года.

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

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

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

Так как нашей команде 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 и будем рады пообщаться лично =)

Казалось бы, инструмент 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" от авторов тулзы.

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

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

Статья с говорящим названием "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 ;)

В Москве прошел 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 ;)

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

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

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

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

Совсем недавно 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мерджат или точно также ответят?)