Недавно один мой товарищ спросил: а как посмотреть все встроенные Kubernetes Roles (те, что используются в RBAC)?

И я задумался как же действительно встроенные/стандартные Roles попадают в кластер и решил разобраться с этим вопросом. В итоге, все они вшиты в код (вот так это выглядит для версии 1.24) и никаких отдельно, лежащих или встроенных YAML!

Можно посравнивать файл "plugin/pkg/auth/authorizer/rbac/bootstrappolicy/policy.go" из разных версий и обнаружить что, от версии к версии он периодически претерпевает изменения, так что встроенные Roles не статичны, а порой изменяются.

На правах владельца канала позволю себе небольшую вольность в эту пятницу и рад сообщить, что наша молодая, небольшая команда Luntry из Санкт-Петербурга начинает потихоньку расширяться и искать новых коллег, единомышленников для развития нашего продукта! Если вам или вашим друзьям/знакомым интересная тема security и observability в современных микросервисных инфраструктурах, то это определенно к нам ;)

Мы в поисках:
- Go разработчиков
- Инженера техподдержки
- Frontend-разработчика (React.js)
- QA инженера (Python)
- С\С++\Rust разработчика

Мы работаем с: PostgreSQL, Linux, Kubernetes, eBPF, HighLoad и нетривиальными задачами.

Сами вакансии еще пока нигде не опубликованы - есть возможность откликнуться напрямую (@Qu3b3c или de@luntry.ru). Готовы рассмотреть специалистов разного уровня, главное чтобы нам было вместе по пути. ЗП по результатам собеседования.

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

Давненько я ничего не рекомендовал на посмотреть. Исправляюсь!

Стали доступны слайды и видео с SREcon22 Americas. Как написано в описании данного канала:"Ценим и любим reliability и security, а также observability." Поэтому я не разделяю надежность и безопасность, то и то сильно взаимосвязаны.

В программе конференции много интересного о Observability, Security, eBPF, Distributed Tracing и т.д.

В превью вы видите слайд из одного из докладов. Какого?! Думаю, тем кому интересно найдут самостоятельно ;)

CNCF Security Technical Advisory Group подошла к финальной стадии подготовки Cloud Native Security Controls Catalog, который представляет из себя как не трудно догадаться из названия перечень контролей и базируется на двух документах: Cloud Native Security Whitepaper (CNSWP) и Software Supply Chain Best Practices (SSCSP).

Весь процесс состоял из двух фаз - подробнее о них тут (1,2) и сейчас до 11 мая идет голосование, получение feedback. Также уже готов мапинг пунктов этого каталога на NIST SSDF (Secure Software Development Framework), а в будущем планируется и на CSA, FedRamp, SOX, GDPR и другие стандарты. А еще планируется перевод всего в машино читаемый формат (OSCAL, JSON и т.д.), а не как сейчас Excel табличка =)

Вчера с коллегами игрались с разными сканерами образов, что работают в Runtime. То есть реализованы как Kubernetes operator, начинают сканировать при deploy и никак не интегрируются с CI и ImageRegistry. Оказалось что у многих из них есть достаточно досадные пробелы/проблемы в работе:
1) Сканируются не все images из Kubernetes ресурса, а только первый
2) Сканируются не все типы containers: Containers, initContainers, ephemeralContainers и пропускаются образы (напоминает это)
3) Сканируют не все images, так как получают их не из Pods, а из вышестоящих сущностей и пропускают, то что добавляется через MutatingAdmissionWebhook (типа istio или vault)

P.S. Сейчас с коллегами продумываем свою систему сканирования образов и если у вас есть какие-то пожелания - пишите в комментариях ;)

Любопытная статья "Compromising Read-Only Containers with Fileless Malware", где авторы показываются, что это не останавливает злоумышленников с Fileless Malware.

Делая файловую систему невозможной для изменения, злоумышленник не может записать исполняемый файл своего вредоносного ПО на диск. Большинство атак основаны на записи файлов, но атакующий может и использовать Fileless Malware как часть своей атаки.

Для демонстрации было взято следующее окружение:
- Redis как таргет
- coreutils как часть образа Redis
- CVE-2022-0543 Redis Lua Sandbox Escape and Remote Code Execution - выполнение любых команд через eval()
- spec:containers:securityContext:readOnlyRootFilesystem:true
- Отсутствие других механизмов безопасности

Для запуска вредоносного кода используется:
- /dev/shm (более известна как tmpfs) - для создания файлов в контейнере с read-only filesystem
- Утилита mktemp из GNU coreutils - для записи в /dev/shm
- DDexec для выполнения Fileless Malware

Моё IMHO - пример хороший, но многое что в нем хорошо подобрано - и тип уязвимости и наличие интерпретатора, и наличие дополнительных утилит в образе и т.д. Ну и само применение Fileless Malware при записи 2-х дополнительных файлов делают атаку не такой уж и fileless ...

В преддверии своего с коллегой выступления на HighLoad++ 2022 с докладом "eBPF в production-условиях" хочу поделится мнением о двух небольших pdf-ках (назвать их книгами язык не поворачивается - обе не более 70 страниц) про eBPF:
1) "What is eBPF?"
2) "Security Observability with eBPF"

Оба документа написаны разработчиками CNI Cilium и хорошо погружают в текущее состояние eBPF, так что свое знакомство с данной технологией можно начать с чтения/изучения данных док.
В обоих документах есть упоминание любопытного проекта Tetragon, но он до сих пор не доступен, но как появится я про него обязательно отдельно напишу.

P.S. Буду рад лично познакомиться и пообщаться на HighLoad, а также показать наш Luntry - у нас будет свой стенд =)

С выходом Kubernetes 1.24 многие писали о появлении там NetworkPolicyStatus для ресурса NetworkPolicy. И при этом никто внятно не писал что это, для чего, как может быть полезным и как устроено...

Наша команда в преддверии выступления про NetworkPolicy - решили разобраться с этим нововведением не по анонсу, а по реальному запуску Kubernetes 1.24. В результате имеем следующее:
- NetworkPolicyStatus по сути предоставляет единый для всех CNI интерфейс
- По сути это поле status в NetworkPolicy и содержит в себе conditions (поля на скриншоте)
- Скорее всего должен позволить отслеживать ошибки при использовании NetworkPolicy
- Пока ни один CNI туда ничего не пишет

Все в принципе и логично ведь реализация NetworkPolicy лежит на CNI и тут все будет зависеть от конкретной реализации CNI. Если верить данному KEP, то с версии 1.25 вроде как Calico и Cilium начнут использовать это поле, но посмотрим ...

Ваш Kubernetes работает на Cgroup v1 или на Cgroup v2?

Нет?! Не знаете?! А зря ...

В статье "Five Things to Prepare for Cgroup v2 with Kubernetes" авторы рассматривают:
- что такое Cgroup v2
- что это дает Kubernetes
- и как подготовить Kubernetes для запуска на Cgroup v2

Из некоторых преимуществ они выделяют:
- Container-aware OOM killer
- Rootless Kubernetes components (уже писал об этом тут)
- Complete utilization of eBPF

В общем с переходом на вторую версию и обслуживание и безопасность Kubernetes можно хорошенько подтянуть ;)

Крутая статья "Digging Into Runtimes – runc" про референсный Low-level runtime - runc.

MUST READ для всех кто работает с контейнерами и хочет понимать что такое контейнеризация на самом деле. runc это самый популярный Low level runtime и он точно есть в вашем Kubernetes ;)

В статье рассматриваются следующие аспекты работы runc:
- Generating an OCI configuration
- Creating root container
- Configuring runc-init with network interface
- Starting the root container
- Writable storage inside a container
- Pause and resume a container
- Inspect the current state of a container
- Checkpoint a container
- Executing a new process in an existing container
- Hooks
- Updating container resource limit
- Creating rootless container
- A word on security

Последние два раздела заслуживают особого внимания с точки зрения ИБ (хотя там все так или иначе касается изоляции и безопасности).

Все это сопровождается примерами и кодом.

По результатам вчерашнего опроса большинство опрошенных так или иначе для реализации Multi-Tenancy в Kubernetes используют подход Namespaces as a Service. Определённо, что для его грамотной реализации нужно использовать и управлять NetworkPolicy для сетевой изоляции и сегментации. Все ли у вас с этим хорошо?)

Одним из примеров/референсов может служить материал из статьи "Managing Network Policies for namespaces isolation on a multi-tenant Kubernetes cluster". В их случае они используют Hierarchical Namespace Controller (HNC) в сочетании с Terraform. При этом у них есть деление на компании, команды и сервисы.

Kubernetes CNI, работающие на базе iptables, при реализации NetworkPolicy используют тот же iptables, который понятно, как работает. А задумывались ли вы как NetworkPolicy реализуются в CNI что базируются на eBPF (тот же Cilium)?!

В статье "Cracking Kubernetes Network Policy" рассматривается как за менее чем 100 строчек на eBPF можно сделать простейшую реализацию NetworkPolicy! По сути, это скелет того, что доведено до ума в Cilium. В итоге очень крутой лонгрид с кишками сетевой работы!!!

MUST READ если хотите понять, как реализуются и работают NetworkPolicy на уровне eBPF.

P.S. А сегодня в 15:00 в зале «Селигер» на PHDays мы с коллегой расскажем доклад “NetworkPolicy — родной межсетевой экран Kubernetes” – приходите, слушайте или смотрите online.

Ребята из Trip.com в статье "First Step towards Cloud Native Security" делятся своим опытом работы с CiliumNetworkPolicy для контролирования доступа на L3/L4 как в Kubernetes, так и в legacy инфраструктуре. При этом они рассматривают следующие моменты характерные для крупных развертываний:
1) Управление политиками в условиях разных доступов и знаний у infra, dev, sec teams
2) AuN и AuZ при манипулировании политиками
3) Обработка cross-boundary доступов в Kubernetes multi-cluster
4) Управление legacy нагрузкой (на пример VM/BM/non-cilium-pods)
5) Вопрос производительности (Performance)
6) Logging, monitoring, alerting, observability и т.д.

Отдельно выделю - у ребят много кастома для решения этих моментов:
- Собственный kubernetes operator для поддержки multi-cluster
- Собственный Custom Resource - CiliumExternalResource (CER) похожий на CiliumExternalWorkload (CEW) для поддержки legacy инфраструктуры
- Использование dataplane-независимого ресурса AccessControlPolicy
- В CD платформе идет апрув запроса по цепочке: запрашивающая сторона, владелец ресурса и команды ИБ
- Обход ограничений идентификаторов через security relevant labels
- Кастомные патчи для Cilium для аудита политик и т.д.

P.S. Забавный факт сетевая обработка пакетов в Cilium идет быстрее если используется NetworkPolicy - без нее цепочка обработки длиннее ;)

KoolKits — это набор специализированных образов, базирующихся на ubuntu:20.04 и содержащих около 60 инструментов отладки, для интерактивной отладки distroless (и не только) образов с помощью команды kubectl debug, которая завязана на Ephemeral containers.

На текущий момент есть поддержка:
- Node.js
- Python
- Java
- Go

Напомню, что Ephemeral containers в Alpha с 1.18 и в Beta с 1.23, где включены по умолчанию. Мотивация использования этого достаточно понятная. С точки зрения ИБ – уменьшаем attack surface и пространство для маневров атакующим, с сохранением удобства работы нашим разработчикам.

Сами авторы говорят, что они вдохновлялись такими проектами как kubespy и netshoot.

Давненько я не выступал в Санкт-Петербурге - все в Москве, да в Москве ...

Исправляюсь и выступлю 28 мая на митапе Three Amigos Talk с названием "Интегрированная безопасность в разработке, или Соблюдай технику безопасности!" у своих друзей из Ak Bars Digital. Речь на митапе пойдет как не трудно догадаться об интеграции безопасности в разработку - программа интересная!

Мой доклад называется «Shift Left Everywhere Security в каждый дом» и в нем я хочу подсветить один очень важный момент о котором часто забывают при внедрении у себя DevSecOps практик ;)

Регистрация и подробности всех докладов тут. Формат online + offline.

Как всегда, буду рад пообщаться!

Исследование "Kubernetes Privilege Escalation: Excessive Permissions in Popular Platforms". В нем авторы решили взять разные популярные решения (AKS, EKS, GKE, OCP, Antrea, Calico, Cilium, WeaveNet) - и посмотреть, как у них обстоят дела с правами.

По итогу:
- В 62.5% есть DaemonSets с мощными правами
- И в 50% побег из любого контейнера на Node приведет к полной компрометации кластера

Также они релизнули rbac-police, которая с помощью самобытных правил на Rego позволяет идентифицировать мощные права и пути повышения привилегий в Kubernetes кластере. Часть этих правил они еще добавили в Checkov, а еще в папке prevent они выложили пару политик для OPA Gatekeeper.

Я долго ломал голову почему нельзя было все эти правила сразу оформить в виде политик для Policy Engine - ведь так наиболее правильно и полезней, да и трудностей сделать это никаких нет. И потом понял, что rbac-police это развитие sa-hunter, который является скриптом для пентестеров!

Несколько дней назад стал доступен документ "Cloud Native Security Whitepaper" версии 2! Напомню, что версия 1 была выпущена в ноябре 2020. Это время индустрия не стояла на месте, а активно развивалась и документ требовал обновлений. В итоге, в него были добавлены следующие разделы:
- Threat Matrix for Containers
- Use case: Ransomware
- Secure Defaults
- Supply Chain Security
- GitOps
- Security Stack
- Use case: Securing Financial Institutions under EU regulations
- SSDF v1.1 Mapping (Secure Software Development Framework)

Если вы не знакомы с данным документом, то я настоятельно рекомендую вам исправить это недоразумение ;)

KubeClarity - инструмент для обнаружения и управления Software Bill Of Materials (SBOM), уязвимостей в образах контейнеров и файловой системы.

Cканы можно запускать как и для всего кластера, так и только в определённых namespaces. Есть фильтры при отображении результатов сканирования. Есть возможность делать сканы в private registries (aws, google cloud).

CLI несколько расширяет функциональность – можно использовать несколько сканеров (сейчас поддерживается Grype и Dependency-Track, обещают добавить поддержку и других), можно использовать разные генераторы SBOM (сейчас поддерживается Syft и Cyclonedx-gomod, обещают добавить поддержку и других)

Также есть интеграция с CIS Docker Benchmark, но в UI результаты посмотреть нельзя (есть в планах roadmap).

Есть ограничение – не поддерживается Docker Image Manifest V 2, Schema 2. А в качестве недостатка – сканер порождает Jobs не в своем namespaces, а там, где развернуто приложение …

Дискуссия!

По идее на прямую доступ к Kubernetes API никто не имеет (либо пользуются этим в исключительных случаях) и раскатывают все через Git (GitOps, GitOps operatos и т.д.). В общем Git является источником правды (root of trust). Хочешь что-то изменить - закомить сначала в Git, пройди все pipelines и только тогда попадай в Kubernetes.

Но в вопросах безопасности порой чрезвычайно важна скорость реакции, что приводит к необходимости обхода стандартных путей или их сокращению. И как следствие ломается концепция root of trust ... И системы становится в некотором плавающем, неопределенном состоянии, непонятным для всех команд, кто не в курсе этого (Dev, Ops, SRE и т.д.).

Например, в обход Git выкатили/изменили/откатили/... NetworkPolicy или политику PolicyEngine. (Я не говорю уж о способах, которые это делают совсем не явно для инфраструктуры)

Безопасность должна обеспечивать непрерывность работы бизнеса, а не палки в колеса.

Как вы думаете как это должно выглядишь правильно ?