Кстати, сегодня ровно 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 и т.д. !

Достаточно лаконичная картинка из статьи "How to Spot Gaps in Your Public Cloud Kubernetes Security Posture", отражающая различные области/аспекты ИБ для той или иной части Kubernetes кластера. На картинке отображено не все, но для старта самое то =)

P.S. Сегодня на DevOpsConf 2022 в 12:10 в зале ОргМет я выступаю с докладом "SOAR в Kubernetes малой кровью" - приходите и смотрите online.

"Bypassing Falco: How to Compromise a Cluster without Tripping the SOC" - наверно моя любимая презентация с KubeCon + CloudNativeCon Europe 2022.

Для тех, кто давно и активно занимается безопасность/пентестами/аудитами/... контейнеров здесь ничего нового - давно успешно применяют в работе ;) Но вот если вы еще верите в 2022 году в СИГНАТУРНЫЕ подходы, то вам это будет очень полезно посмотреть (слайды, видео).

Автор также выложил на GitHub весь исходный код, что он использовал, и готовый image со снипетами атак.

Также посмотрите мои прошлые посты (1,2,3) про обход правил Falco. Вообще это проблема любого rule/sigtnature-based решения ... Свой взгляд на эту проблему я подробнее раскрываю в докладе "Kubernetes: Observability важная часть Security" с Kuber Conf 2021.

P.S. Так пентестерам будет очень полезно посмотреть, как быть невидимыми для SOC ;)

На сайте DevOpsConf 2022 стали доступны все слайды конференция, включая мои по теме "SOAR в Kubernetes малой кровью". Начав с Kubernetes Policy Management Whitepaper и специализированных ресурсов PolicyReport и ClusterPolicyReport, я в ней показал как можно сделать SOAR (Security Orchestration, Automation and Response) в Kubernetes на двух фазах:
- Deploy - с помощью PolicyEngines
- Runtime - с помощью Agents и Responce Engines

В качестве Policy Engine я использовал Kyverno, так как он умеет проверять, изменять и создавать Kubernetes ресурсы. А в качестве Responce Engine я выбрал связку Argo Events и Argo Workflow, которые позволяют создавать playbooks любой сложности!

И, конечно, привел примеры нескольких playbooks, которые уже можно взять к себе на проработку ;)

Еще одна впечатляющая работа с Kubecon 2022 Eu - "Protect the Pipe! A Policy-based Approach for Securing CI/CD Pipelines" (слайды, видео). Главными героями (стек) в этой работе выступают:
- Tekton - Cloud Native CI/CD
- in-toto - framework to secure the integrity of software supply chains
- sigstore - new standard for signing, verifying and protecting software
- Kyverno - Policy Engine

Авторы выделяют дерево атак на Tekton Pipeline и потом защищают его с помощью упомянутых решений. Самое классное в этой работе то, что все это сопровождается live demo и при этом доступен весь исходный код! Tак что можно познакомится со всеми инструментами самостоятельно на minikube и создать реально защищенный pipeline по последнему писку cloud native моды!

Очень крутая статья `Kubernetes Ephemeral Containers and kubectl debug Command`. Из статьи вы узнаете:
1) Зачем вообще понадобились Ephemeral Containers - если вдруг вы еще не знаете
2) О существовании команды kubectl debug
3) О дефолтном поведении kubectl debug при отладке
4) Первый сценарий: kubectl debug в сочетании с shareProcessNamespace
5) Второй сценарий: kubectl debug с указанием конкретного conntainer в Pod
6) Третий сценарий: kubectl debug с копированием целевого Pod
7) И можно ли работать с Ephemeral Containers без kubectl debug

Ephemeral Containers - перешли в Beta и включены по умолчанию в 1.23, а появились в версии 1.18. Индустрия уже и отладочные образы (типа KoolKits) на разные случаи жизни подготовила.

Также не забывайте о них и при анализе безопасности своих микросервисов и окружения (а то бывает вот так).

Tetragon - eBPF-based Security Observability and Runtime Enforcement от создателей CNI Cilium. Это rule-based решение типа Falco, Tracee. При этом то, за чем следим описывается в отдельном Custom Resource - TracingPolicy.

Авторы как-то сделали явный акцент на обнаружении и предотвращение побегов из контейнеров и эксплуатации уязвимостей ядра.

И сразу несколько Linux-исследователей взялись за оценку подобного подхода и продемонстрировали обходы:
- Bypassing eBPF-based Security Enforcement Tools
- Tetragone: A Lesson in Security Fundamentals
- Tetragon: case study of security product's self-protection

Тул на самом деле интересный, правда требует тонкой (хирургической) настройки на уровне каждого syscall с его аргументами. Если вы пишете на eBPF (как мы в нашем решении), то там есть на что посмотреть в исходном коде - правда есть и вот такие вставки на assembler с исповедью разработчика)

Поиграться с ним можно в этой лабе.

P.S. К сожалению, часто при описании тулы, упоминаются фичи платной версии.

Если у атакующего в контейнере есть капабилити CAP_SYS_ADMIN или он находится в привилегированном контейнере (securityContext.privileged:true), то для побега из контейнера ему даже не требуется никаких уязвимостей! Пускай у вас там хоть все запатчено и перепатчено =)

Одним из подобных векторов, о котором мы сегодня поговорим, является использование Usermode helper programs. Таких программ порядка десятка и почти все можно использовать для побега из контейнера, так как при срабатывании того или иного события эти программы выполнится на хостовой ОС.

Самой известной такой программой является release_agent. О данной программе есть куча статей и данную технику можно встретить во множестве тулов и эксплоит паках.

Но есть, на пример, и такая как (менее известная) core_pattern — вот как раз про нее и рассказывается в статье "Escaping privileged containers for fun", которую я рекомендую почитать. Техника очень проста и стабильна ;)

P.S. Еще можете посмотреть такой кейс с core_pattern

Молодой PolicyEngine под названием Kubewarden на днях отпраздновал выпуск версии 1.0.0!

Я за ним мало слежу и вообще не встречал его среди клиентов (но судя по опросу на канале он используется). Но тут при чтении данного анонса мой взгляд зацепился за строчку "Reuse your existing Open Policy Agent / Gatekeeper policie". Ранее я думал, что там политики можно писать только на Rust, Go и Swift. То сейчас (с какого-то момента) можно переиспользовать те же политики от OPA Gatekeeper или просто писать на Rego (я и таких фанатов знаю).

Какой смысл писать политики на Rego тут, а не в OPA Gatekeeper (и то без мутаций)?! Я честно кроме выгоды от переносимости Wasm больше не увидел ... Написание политик на высокоуровневых языках (Rust, Go и Swift) еще понятна - там мы получаем всю их мощь, включая гигантский набор библиотек (по статистике, анализу, ML, готовых API в другие системы и т.д.).

Сегодня в фокусе нашего внимания статья "How to secure Kubernetes ingress?". Статья очень базовая - но кому мешало знание базы?! Для примера там раcсматриваются Ingress controller на базе Nginx и cert-manager. А далее по шагам разбирается:
- Конфигурирование controller для работы с SSL
- Создание Secret с информацией о сертификате
- Добавление в Ingress ресурс информации о TLS
- Приобретение SSL сертификата и настройка cert-manager

При этом не забывайте, что можно одновременно использовать несколько Ingress controller и , конечно, о необходимости их своевременно обновлять ;)

На днях обновление получил документ "Cloud Security Technical Reference Architecture" от организации Cybersecurity and Infrastructure Security Agency (CISA). Полностью документ я еще не изучил, но беглое чтение по диагонали показало его интересность.

Я выделил несколько ключивиков, по которым вы можете определится стоит вам его изучать или нет.
- Continuous Monitoring
- Incident Handling
- Authorization Boundary
- Infrastructure as Code
- DevSecOps
- ZeroTrust
- Cloud Migration
- Cloud Security Posture Management (CSPM)

Слово Kubernetes там не упоминается ни раза =)

В моих книжных рекомендациях пополнение! Теперь к вот этим трем [1,2,3] добавилась еще одна книга - "Hacking Kubernetes: Threat-Driven Analysis and Defense".

Что-то особенное в ней выделить сложно - она просто хорошая, актуальная, обзорная книга по вопросам безопасности Kubernetes. Так как тем рассматривается очень много, на какую-то глубину она претендовать не может. Так что бывалым можно часть книги смотреть по диагонали, а новичкам прям должна зайти - тут все от основ до продвинутого уровня.

Особое внимание можно обратить на такие главы как:
- Applications and Supply Chain
- Hard Multitenancy
- Policy
- Intrusion Detection

Приятного чтения)

Я уже писал, что веду 3-х дневное обучение "Cloud Native безопасность в Kubernetes".

И вот недавно на одном из таких тренингов, один из участников (респект тебе) сделал вот такой замечательный MindMap по его итогам! Выкладываю его с разрешения его создателя. Сначала я хотел внести туда какие-то свои мысли, корректировки и дополнения, а потом решил, что так будет даже лучше (или мне просто пока лень) показать, как видят материал участники! То есть тренинг "Cloud Native безопасность в Kubernetes" глазами его участников.

Думаю, что данный MindMap будет полезен многим ;)

Изучайте новое, от теории переходите к практике, не бойтесь не понятного! Чем больше в сообществе, в индустрии будет грамотных специалистов, тем лучше будет нам всем!

В официальной документации Kubernetes в разделе Security появился целый новый подраздел о "Multi-tenancy", объясняющий данную концепцию. Тема сейчас для многих очень актуальная.

Оттуда вы узнаете о:
- Use cases
- Terminology
- Control plane isolation (Namespaces, Access controls, Quotas)
- Data Plane Isolation (Network isolation, Storage isolation, Sandboxing containers, Node Isolation)
- Additional Considerations
- Implementations (Namespace per tenant, Virtual control plane per tenant)

Все очень хорошо описано и систематизировано. И не забываем и про прошлые посты [1,2,3,4,5] и опрос на эту тему, которые помогут сложить картину еще более четко о Multi-tenancy.