Ребята из 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. (Я не говорю уж о способах, которые это делают совсем не явно для инфраструктуры)

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

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

Конкурс!

14 июня на конференции DevOpsConf 2022 в Москве я выступлю с докладом "SOAR в Kubernetes малой кровью". Благодаря организаторам у меня появилось возможность разыграть 1 online билет!

SOAR расшифровывается как Security Orchestration, Automation and Response. Это такой класс ИБ решений, который предназначен для оркестрации систем безопасности - автоматизировать типовые сценарии реагирования на события ИБ. Я данную тему поднимал уже не однократно [1,2,3,4,5].

На мой скромный взгляд в Kubernetes на базе его концепций (reconciliation loop, декларативная природа и т.д. ) можно построить не только self-control, self-healing, но и self-defence систему.

В комментариях для данного поста напишите сценарий в области ИБ в Kubernetes, который бы вам хотелось бы (или он уже у вас реализован) обрабатывать автоматизировано: случилось что-то и на это последовала какая-то реакция. Варианты принимаются до 03.06.2022. Выбирать буду я на свой субъективный взгляд ;)

Trivy Operator PolicyReport Adapter - проект, предназначенный для перевода CustomResources от Trivy Operator (Не понял чем он отличается от Starboard-operator) в унифицированный формат PolicyReport и ClusterPolicyReport от Kubernetes Policy Working Group. Это позволяет использовать проект Policy Reporter для работы с различными результатами политик и сканов.

Таким образом в одном интерфейсе можно работать с:
- VulnerabilityReports
- ConfigAuditReports
- CISKubeBenchReports
- ComplianceReports
- И результатами работ того же Kyverno.

Все декларативно и при этом в одном интерфейсе.

Крутой GitHub репозитарий "Software Supply-Chain Security Reading List" - в общем все о Supply-Chain Security. Содержит следующие разделы:
- Policy - где это вообще требуется и описывается
- Incidents/Threats - уже случившиеся инциденты
- Solutions - решения из данной области
- Organizations - организации, занимающиеся данным вопросом
- Background - полезные материалы для понимания данной области
- Reports and summaries - различные документы и отчеты по данной теме

Тема хоть для многих и не столь актуальная сегодня (ввиду текущего уровня зрелости ИБ), но явно таковой станет.

Недавно мы с коллегой выступали на конференции с докладом "NetworkPolicy — родной межсетевой экран Kubernetes". Сейчас доступна запись и можно изучить ее и разобраться чем отличаются и что могут Native и Custom NetworkPolicy на базе Calico и Cilium.

+ раз и навсегда понять зачем не нужно в Kubernetes городить своих огородов из разных костылей и искать железку в стойку ;)

Приятного просмотра!

Если вы планировали провести эти выходные с пользой, то как раз для вас CNCF выложил записи докладов (+ слайды) с недавно прошедших своих сессий:
- KubeCon + CloudNativeCon Europe 2022
- ServiceMeshCon EU 2022
- Kubernetes on Edge Day EU 2022
- Kubernetes Batch + HPC Day EU 2022
- Cloud Native SecurityCon EU 2022
- Kubernetes AI Day EU 2022
- Cloud Native Wasm Day EU 2022
- FluentCon EU 2022
- KnativeCon EU 2022
- GitOpsCon EU 2022
- Cloud Native Telco Day EU 2022
- PrometheusDay EU 2022
- Cloud Native eBPF Day EU 2022

Обратите внимание, что доклады на тему security были не только на Cloud Native SecurityCon, но и в основной программе, и в других сессиях ;)

Наиболее интересные на мой взгляд доклады по security я выделю отдельно.

Документация Kubernetes это все-таки кладезь полезных материалов. Сегодня хочу подсветить недавно появившуюся страничку "Role Based Access Control Good Practices". Она содержит:
- General good practice
- Kubernetes RBAC - privilege escalation risks
- Kubernetes RBAC - denial of service risks

Обязательно к чтению!

Mind map для Linux privilege escalation. Может быть полезно если нужно поднять привилегии в контейнере ;)

Кстати, сегодня ровно 8 лет с первого коммита в Kubernetes https://github.com/kubernetes/kubernetes/commit/2c4b3a562ce34cddc3f8218a2c4d11c7310e6d56 !

Не многие знают, но я периодически провожу тренинг "Cloud Native безопасность в Kubernetes" — это 3-х дневное обучение для компаний. Это теоретический курс, который покрывает абсолютно все аспекты безопасности Kubernetes, но обратной стороной его всеобъемлемости является отсутствие практики.

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

Какие основные идеи мы туда закладываем:
- Обучение без учителя (задания и прохождения в одном флаконе для спокойного самостоятельного изучения)
- Упражнения на все темы какие только возможны в области безопасность Kubernetes
- Упражнения на атаку и защиту
- Знакомство со множеством OpenSource проектов
- Minikube в несколько Nodes (ничего ставить не надо)
- CNI на выбор calico и cilium (важно для темы NetworkPolicy)

Мы рассчитываем все завершить к концу 3-4 квартала этого года. Будем рады услышать любые идеи и предложения!

Совсем недавно я с коллегой выступал на конференции HighLoad++ Foundation 2022 в Москве с докладом "eBPF в production-условиях". Сейчас хочу поделится слайдами и видео с нашего выступления. По теме безопасности eBPF мы рассмотрели такие аспекты как:
- Safety и security eBPF
- BPF_LSM
- Уязвимости в подсистеме eBPF
- Вредоносный код на eBPF
- capability для работы eBPF
- Подпись eBPF программ

В комментариях можно, как всегда, поспрашивать вопросы по данной теме! В нашем решении мы активно используем eBPF, так что знаем о нем не понаслышке.

Отличный лооонгрид "Cracking Kubernetes RBAC Authorization Model". Если вы хотите из одной статьи узнать, что и как там устроено в Kubernetes RBAC, то это то, что вам нужно! Проще сказать, чего там нет по данной теме: специфика verb, моменты с Aggregated ClusterRoles и subresources. Ну и вопрос повышения привилегий (1,2,3,4,5) остается за рамками данной стать. Все остальное есть и продемонстрировано очень хорошо!

Скорее всего о том, что можно назначать запуск определённых Pods на определенных Nodes (с помощью тех же NodeSelector, nodeAffinity) вы в курсе. И о том, что в этом задействованы Node labels вы также в курсе.

Но в курсе ли вы о том, что на базе этого для правильной реализации концепции Node isolation/restriction необходимо использовать labels с определенным prefix?!

node-restriction.kubernetes.io/ - специализированный prefix в сочетании с NodeRestriction admission plugin предотвращает от настройки и модификации kubelet данного label!

Таким образом, атакующий, попавший на Node, не может модифицировать такой label и тем самым заставить определённые Pods запустить на себя. На пример, в инфраструктуре есть Node с лейблом type, который может принимать значения frontend, backend, pci-dss. Атакующий, попав на frontend не сможет заставить запускаться на ней Pods с pci-dad.

По данной теме посмотрите еще данный пост.

P.S. Сегодня первый день DevOpsConf 2022 - буду рад пообщаться лично, пообсуждать Luntry, Kubernetes и т.д. !