Выбор правильной технологии, инструмента, решения является важной частью создания надежной системы. И если вы смотрите в сторону Service Mesh решений, то стоит начать с материала "Service Mesh Ultimate Guide - Second Edition: Next Generation Microservices Development". Первая часть выходила в феврале 2020.

Конечно, же вопрос security там также рассматривается ;)

Классный репозиторий для тех, кто хочет понять:
- Как определить, что попал в Pod обернутый Istio
- Как обойти/отключить sidecar от Istio
- Какие есть способы усложнить сделать это атакующему
- Какие best practices по Istio security есть

P.S. Самый забавный способ отключить sidecar как по мне это curl --request POST localhost:15000/quitquitquit

Inventory или asset management это база, фундамент, основа основ! Без понимания того, что и как у вас функционирует в инфраструктуре, окружении, Kubernetes кластере - любое закручивание гаек (security hardening) будет просто каплей в море. Атакующий всегда идет по пути наименьшего сопротивления и часто находит то, что вы забыли или банально не знали. Все думаю слышали: “Атакующему достаточно обнаружить один вектор, чтобы проникнуть в периметр. А защищающейся стороне надо найти все векторы, чтобы минимизировать риски.” Заниматься минимизацией рисков без полной картины невозможно.

С учетом микросервисной специфики и вообще текущих реалий нужно continuously inventory для continuously security.

Всем хорошей пятницы и выходных ;)

kdigger - новый инструмент, позволяющий понять, что код выполняется в контейнере в Kubernetes и с какими возможностями. Сами авторы его описывают как: Context Discovery Tool for Kubernetes. По сути, является идейным наследником amicontained.

Для того чтобы понять окружение инструмент умеет проверять:
- admission
- authorization
- capabilities
- devices
- environment
- mount
- pidnamespace
- processes
- runtime
- services
- syscalls
- token
- userid
- usernamespace
- version

kdigger, конечно, будет полезен на ранних стадиях как на pentest, так и на CTF, но автоматизировано взломать k8s он не поможет (для этого смотрите инструмент CDK). При этом учтите, что ряд команд имеют side effects, поэтому используйте с умом!

Для того чтобы поиграться с инструментом и попробовать все его возможности авторы создали даже отдельный Minik8s CTF с 3 задачками (+ есть прохождения)!

Небольшой анонс.

После завтра, а именно 13 октября в 19:00 (Мск) будет вебинар «Дыры и заборы: безопасность в Kubernetes», который является по сути предваряющим курс "Безопасность в Kubernetes" на площадке СЛЁРМ.

Я решил также внести свою небольшую, посильную лепту в этот образовательный проект для широкой аудитории. Не только же корпоративные тренинги читать =)

Kubernetes Cluster API достиг версии 1.0 и перешел в v1beta1, это означает, что теперь он официально production-ready! Для этого данному API понадобилось 3 года. Все это время над ним работали и внутри себя использовали ведущие IT компании - их use cases можно почитать в статье в блоге CNCF. При этом работа в Cluster API продолжает кипеть и идет работа над ClusterClass и Managed Topologies.

Данного API мы касались, обсуждая тему Multi-Tenancy. Оно, по сути, позволяет декларативно управлять Kubernetes, используя API для создания, конфигурирования и обновления кластеров.

Если вы привыкли под задачи команды или клиента на время или на всегда выделять целый изолированный Kubernetes кластер то, это может сильно упросить эту задачу.

P.S. Пример установки CNI Calico и Cilium с помощью ресурса ClusterResourceSet

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

Мне, на пример, понравился очень хорошо описанный с PoC тикет "Man in the middle leading to root privilege escalation using hostNetwork=true (CAP_NET_RAW considered harmful)", который ничего не получил ... Бага была классифицировано как provider-specific, сам автор показал успешность атаки в GKE и EKS. Автор данной багой хотел показать и убедить разработчиков Kubernetes убрать CAP_NET_RAW капабилити из дефолтных - очень благая цель! Он даже предложил workaround для использования ping через sysctl net.ipv4.ping_group_range, но это осталось без внимания …

P.S. В CRI-O с версии 1.18 так и сделали, возможно когда-нибудь так сделают и в docker с containerd ...

Давненько не было облачных новостей - исправляем это упущение.

От команды Yandex.Cloud вышел официальный чеклист по безопасности (есть и не официальный)!

Мое внимание в первую очередь, конечно же, захватил раздел "Безопасность Managed Service for Kubernetes", где присутствуют такие пункты как:

- Шифрование данных и управление ключами/секретами
- Сетевая безопасность
- Аутентификация и управление доступом
- Безопасная конфигурация
- Сбор, мониторинг и анализ логов аудита
- Резервное копирование

Большинство инструкций можно на прямую посмотреть в соответствующем репозитории. Мне, например, очень понравилась инструкция "Анализ логов безопасности k8s в ELK" - там можно подсмотреть вещи и для разворачивания такого и у себя локально ;)

Также пообщавшись с ребятами из команды безопасности узнал, что не за горами появление аналога IMDSv2 для борьбы с SSRF атаками и механизма подобного Workload Identity из GKE или IRSA из EKS. Это все очень здорово!

В официальном блоге Kubernetes вышла статья "A Closer Look at NSA/CISA Kubernetes Hardening Guidance", которая является еще одним анализом, критикой, дополнением к нашумевшему документу Kubernetes Hardening Guidance от NSA/CISA.

В данном блоге прошлись по таким темам, как:
- Kubernetes Pod security
-- "Non-root" containers and "rootless" container engines
-- Immutable container filesystems
-- Building secure container images
-- Pod Security Policies
-- Hardening container engines
- Network Separation and Hardening
-- Network Policies
-- Resource Policies
-- Control Plane Hardening
-- Etcd
-- Kubeconfig Files
-- Secrets
- Log Auditing
-- Kubernetes API auditing
-- Streaming logs and auditing
-- Alert identification
- Upgrading and Application Security practices

Все очень грамотно и четко изложено и заключение очень правильное:"Finally, it is worth reiterating that not all controls in this guidance will make sense for all practitioners. The best way to know which controls matter is to rely on the threat model of your own Kubernetes environment."

Материал из разряда MUST READ!

Статья "A Practical Guide to the Different Compliance Kubernetes Security Frameworks and How They Fit Together"

Это сравнение популярных Kubernetes security и compliance фреймворков: чем они отличаются друг от друга, когда и что использовать, их основные цели и задачи, а также существующие вспомогательные инструменты для них.

В сравнении участвуют:
- CIS Kubernetes Benchmark - самый известный и у всех на слуху
- MITRE ATT&CK® Framework for Kubernetes - на самом деле тот что от Microsoft и уже обозреваемый мной
- PCI DSS Compliance for Kubernetes - притянут тут за уши, для привлечения внимания, так как в нем нет ничего Kubernetes специфик
- NIST Application Container Security Framework - это тот что NIST SP 800-190.
- NSA/CISA Kubernetes Hardening Guide - многострадательный документ, по которому уже прошлись раза два точно [1,2]

Тут мне на глаза попался Hype Cycle for Application Security 2021 от не безызвестной Gartner =)

Каждый для себя может тут найти близкие ему классы application security решений - для читателей же данного канала скорее всего самое актуальное это:
- Container and Kubernetes Security - по сути нашли свое место в этом мире
- Service Mesh - уже на спаде волны хайпа
- DevSecOps - тут я не уверен, что все до сих пор понимают, что это и как это делается IMHO =)
- Policy-as-Code - находится только в самом начале волны хайпа
- Chaos Engineering - очень большие ожидания на волне хайпа

Всем хорошей пятницы и выходных!

Kubernetes Security Checklist and Requirements

В канале было много того, что касается безопасности ванильного Kubernetes, но, когда дело доходит до составления перечня требований или чеклиста для аудита, так или иначе приходится тратить время для сведения всего этого воедино. Чтобы упростить эту задачу мы зарелизили собственный чек-лист безопасности k8s: Kubernetes Security Checklist and Requirements 🎉

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

Кстати, есть также версия на русском.

#k8s #ops

На прошлой неделе отгремели KubeCon + CloudNativeCon North America 2021.

В этот раз тема безопасности раскрывалась не только в основной программе, но еще и в нескольких привычных, так и новых мини конференциях:
- Cloud Native eBPF Day
- Production Identity Day
- Supply Chain Security Con
- Cloud Native Security Con

Информации очень много - буду постепенно по мере ее изучения делиться с вами. Если есть какие-то пожелания/предпочтения, то пишите.

Стали доступны слайды очень классного доклада "Command and KubeCTL: Solar Wind’d Edition" о котором я писал некоторое время назад.

Смысл в том, что демонстрируется как атакующий может незаметно и полностью скомпрометировать Kubernetes кластер в окружении, где есть и используются NetworkPolicy, Private registry, OPA Gatekeeper, Vault, Falco!

Отдельно выделю 10 слайд "Challenges of Pentesting K8s". Мне тут очень понравился пункт "Learning the nuances of these systems is an investment" - это мало кто пытается сделать и из-за этого и появляются такие misconfigurations. Существует много разных, хороших инструментов, но их мало просто установить их еще надо правильно настроить и обслуживать.

Замечательная исследовательская статья "Abusing Registries For Exfil And Droppers", которая показывает, как пентестеры и злоумышленники могут использовать image registry для:

1) Arbitrary Blob Storage - использовать как секретное место хранения для чего-либо.
2) Exfiltration channel - использовать как канал коммуникации между различными средами и извлечения информации из инфраструктуры.

Конечно, это не массовый случай и требует прав записи в registry, но ситуации бывают разные, на пентестах можно встретить что угодно) Иметь ввиду такую возможность пентестерам будет полезно.

Для проведение данных манипуляций можно использовать инструменты dxf и scopeo.

В заключении статьи без внимания не остается и вопрос защиты с помощью Garbage Collection и Logging действий.

Продолжим атакующую тематику.

Если вы задавались вопрос что такое в Threat matrix for Kubernetes в тактике Persistence означает техника Malicious Admission Controller, то статья "Creating Malicious Admission Controllers" даст вам короткой и простой ответ, да еще с примером кода на Go ;)

Да, это уже post-exploitation фаза и атакующему вообще не всегда требуется закрепляться в чужой инфраструктуре, но это возможно и делается не сложно. При этом если мне не изменяет память, то ни одно средство защиты для Kubernetes на текущий момент вообще не смотрит за наличием/появлением MutatingAdmissionWebhook. И это по идее не удивительно - сигнатуру на это не напишешь, а по умолчанию это ничего плохого не означает - те же Istio, Linkerd, Kyverno используют данный механизм.

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

sk8s game !!!

Не бойтесь ничего нового, учитесь, развивайтесь и все вам будет по плечу ;)

Всем хорошей пятницы и выходных!

CVE-2021-25742: Ingress-nginx custom snippets allows retrieval of ingress-nginx serviceaccount token and secrets across all namespaces

Уровень: High (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:L)

Пользователь в Kubernetes с правами на создание Ingress ресурсов, может создать его со специально заданным custom snippet и получить доступ к serviceaccount token от ingress-nginx, а далее с его помощью уже получить доступ ко всем секретам во всех namespaces (при условии дефолтного RBAC у ingress-nginx). Ну естественно можно и другие вещи творить с этим serviceaccount token.

Оказывается (я лично не знал) в аннотациях custom snippet пользователь может задать произвольный код, который будет выполнен Nginx через Lua!

Это наиболее критично для multitenant окружений, где non-admin пользователи имеют права на создание Ingress ресурсов.

Для защиты надо:
1) обновить ingress-nginx до версии >= v0.49.1 или >= v1.0.1
2) выставить allow-snippet-annotations в ConfigMap в значении false

На счет эксплуатации пишут, что она: "Exploitation isn't that difficult, just takes a little fiddling."