Коротенькая блоговая запись с говорящим названием "Fun with CRDs - Overwriting core types".

Вы, наверное, уже поняли автор задался вопросом что будет если создать с помощью CRD тип ресурса из Core API. В качестве пример автор берет ресурс NetworkPolicy из networking.k8s.io.

Как по мне хорошая и легкая тема для этой пятницы ;)

P.S. Спойлер: Core API нашего любимого Kubernetes вы не сломаете, но вот часть инструментов, работающих с ним вывести из строя можно =) Так что следите за тем кому вы даете в RBAC возможность создавать CRD.

Нашел очень достойную подборку разных техник побега из контейнера с примерами и описанием, среди которых:
- CVE (уязвимости container runtime и linux kernel)
- Exposed Docker Socket
- Excessive Capabilities
- Host Networking Driver
- Sensitive Mounts

Это актуально и для Kubernetes. Для пентестеров будет полезно знать, как можно нарушить изоляцию контейнеров, а для security team, что надо харденить.

Совсем недавно пришлось немного поработать с таким Container Runtime для Kubernetes как kata-containers. Если кто не слышал о таком, то его отличительной чертой является то, что вместо классического Linux контейнера, он запускает microVM и базируется на Kernel-based Virtual Machine (KVM).

Что важно о нем знать:
1) На выбор он предлагает аж 4 hypervisor: ACRN, Cloud Hypervisor, Firecracker и QEMU.
2) Если хотите с этим работать в VM (касается сразу всех managed Kubernetes), то должна быть активирована nested virtualization. И этого я не нашел ни у кого в managed k8s услугах.

Как можно поиграться с этим дома на VM или на bare metal в AWS или GCP можно посмотреть в статье "Setting up a Development Environment for Firecracker".

Так что будьте внимательны если засматриваетесь на данный Container Runtime и помните что можно работать сразу с несколькими рантаймами.

P.S. Напомню про пост про побег из Kata ;)

Это прошло как-то мимо меня, но у Falco появился конкурент в лице инструмента Tracee, который также базируется на eBPF и на правилах. Правила только пишутся на языке Rego (тот же что используется и в OPA).

О запуске в Kubernetes можно почитать в серии статей [1,2]. Правил пока немного и по мне они пока более простые, но при этом смапленные на "MITRE ATT&CK".

Хотя правила такие же бестолковые и требуют хорошей ручной доработки (которую все равно можно легко обойти). На пример, правило про K8S Service Account Token, требует, чтобы вы прописали все имена процессов, которым это разрешено. Для обхода достаточно залить свой файл с именем kube-proxy или coredns =) Есть правила которые почти как под копирку взяты из Falco - на пример про shell [1,2].

Также есть собственная утилита для алертинга Postee, аналог Falcosidekick. При этом можно сообщения слать сразу на второй, что может упростить использование этих двух решений одновременно, если кто-то так захочет.

На просторах GitHub нашел наиинтереснейший проект с Jupyter notebooks для Kubernetes Security trainings!

Описание самого тренинга можно посмотреть в этом файле и состоит он из трех частей:
- Introduction
- Networks
- Hardening Kubernetes

Все происходит в Jupyter notebooks (это бомба) и крутиться на minikube. Несколько сценариев можно посмотреть в вебинаре автора "Kubernetes Security: Hacking Containers". Там он, на пример, показывает (достаточно своеобразно) как можно обойти ограничения Istio Egress Control, через переопределение iptables (как тут).

В общем, если хотите дома просто попрактиковаться в безопасности Kubernetes это хороший старт!

Как всегда, по пятницам в преддверии выходных я стараюсь сделать максимально легкий, развлекательный пост или устроить какой-нибудь опрос.

И в этот раз хочется узнать почему некоторые люди говорят: "Kubernetes дырявый", "Kubernetes не безопасный" и т.д. Лично я так не считаю, и хотел бы понять какие мысли, факты в это вкладываются.

Можете написать почему (не вы а) ваш друг/товарищ так считает или где-то слышали такое мнение ;)

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

В официальной документации Kubernetes появилось 3 новых раздела посвящённых PodSecurity Admission Controller (замена PSP для тех, кто запамятовал):
1) "Enforce Pod Security Standards by Configuring the Built-in Admission Controller" - про настройку этого Admission Controller
2) "Enforce Pod Security Standards with Namespace Labels" - о том как правильно работать с labels для namespaces для работы данного механизма
3) "Migrate from PodSecurityPolicy to the Built-In PodSecurity Admission Controller" - как правильно перейти с PSP (если вы его сейчас используете) к PSA

Ознакомившись с ними, я как-то даже более сдержаннее начал относится к данной замене (раньше вообще ее не понимал). Возможно это действительно неплохой механизм, который прямо автоматом можно накручивать на только что созданный кем-то namespaces в каком-нибудь dev/test/stage кластере, не переживая во всех (в каких?) ли Rego и YAML правилах от Policy Engines нужно вносить какие-то правки/уточнения. Но все также это не отменяет и не заменяет использование Policy Engines.

У Policy Engine под названием Kyverno появился новый тип правил под названием "Verify Images" - как не трудно догадаться из названия данный тип правил нужен для проверки сигнатур образов, а также что менее очевидно заменять tag на digest образа (зачем это - я писал тут).

Под капотом для верификации сигнатур образов контейнеров используется крутой проект Cosign.

По мне очень простая и удобная реализация получилась у ребят:
0) Генерируете ключи с помощью cosign
1) В pipeline с помощью cosign подписываете образа
2) Создаете Kyverno ресурс ClusterPolicy (YAML) с правилом внутри verifyImages, указав к каким образам контейнеров, какой ключ при проверки применять.
3) Применяете созданный ресурс в кластере

Можно ли проще?)

На днях обновился популярный инструмент для проведения пентеста Kubernetes инфраструктуры - речь идет о Peirates (его и злоумышленники любят).

Основные нововведения этого релиза возможность автоматизировано собрать Secrets с файловой системы Nodes. А именно он лезет в /var/lib/kubelet/pods/. Вручную это делать - достаточно муторная и неприятная задачка ... Естественно так или иначе сначала нужно попасть на эту Node ;)

Также вторая это фича "Enumerate services via DNS" - реализуется через запрос SRV записи any.any.svc.cluster.local (об этом мы уже писали). Мы уже с вами знаем как DNS всемогущ в Kubernetes =)

Все написано на Go сами собираете называете как-то в духе "nginx", "kubelet", "runc" и передаете горячий привет сигнатурным движкам ;)

На днях CNCF опубликовала очередной [1,2,3,4,5,6,7,...] сторонний security аудит для одного из своих проектов - на этот раз для Flux (вторая версия).

В итоге по результат работы в отчет попало 22 найденные проблема:
- 1 high severity
- 3 medium severity
- 13 low severity
- 5 informational

На High проблему завели CVE-2021-41254: Privilege escalation to cluster admin on multi-tenant Flux. Почитайте тикет на данную CVE - там достаточно забавный, классический command injection =)

Интересно что для тестирования проекта использовали OSS-fuzz для фазинга проекта!

И опять сегодня про PodSecurity Admission Controller.

Стало известно, что он переходит в стадию beta и будет включен по умолчанию с версии Kubernetes 1.23 (то есть уже в следующей новой версии).

При этом его уже можно спокойно поставить и на более старые версии хоть сейчас! Он красиво оформлен в виде отдельного Admission Webhook - берем и ставим =)

Я думаю, что подавляющее большинство читателей данного канала не знают, чем я занимаюсь все свое основное время - я никогда не писал об этом на канале.

Мы с командой (всем привет - вы крутые!) разрабатываем решение для observability в Kubernetes под название Luntry. Наш девиз: "Нельзя сделать надёжным и безопасным то, что скрыто от ваших глаз".

Решаемые нами проблемы выходят далеко за рамки решения security вопросов (поэтому я особо о нем и рассказывал), но и их мы тоже покрываем. На пример, обнаруживаем аномалии в поведении микросервисов, ищем unused/orphan ресурсы, позволяем автоматически генерировать NetworkPolicy ресурс с карты сетевого взаимодействия. При этом для все этого это не требуется никаким образом модифицировать окружение и сервисы! Для чего-то мы используем eBPF (теперь стало понятнее почему я активно освещаю данную тему). Так или иначе каждый день мне приходиться смотреть на Kubernetes со сторон: защиты/атаки и разработки (внутреннего устройства).

Всегда рад рассказать, показать нашу разработку и получить предложения, критику, пожелания =)

P.S. Так по мере нововведений буду с вами делиться разными интересными нашими достижениями.

Отличная статья "Detection Engineering for Kubernetes clusters" от известной аудиторской компании. Статья состоит из 3 частей:
1) Что такое Kubernetes для Detection Engineering специалиста
2) Что такое Detection Engineering для Kubernetes специалиста
3) Detection Engineering в Kubernetes

Среди рассматриваемых способов детектирования:
- Signatures
- Behaviours
- Anomalies

В статье все крутиться вокруг анализа событий Kubernetes Audit Log (и только стадия privilege escalation), события/действия/активности внутри контейнеров (runtime) в рамках данной статьи не рассматриваются.

Таким образом, из-за отсутствия анализа runtime тема раскрыта примерно на 50%, при этом как по мне из этого еще 40% можно заранее предусмотреть в политиках от Policy Engine, чтобы уменьшить логирование и сразу сделать prevention и вот получаем 10% действительно актуального. Например, я очень рад, что не забыли сказать про SelfSubjectAccessReview о котором я уже писал на канале.

И очень хорошее уточнение: "Some managed platforms will not let you customise the audit logging, but it still needs to be enabled. From a security perspective certain misconfiguration, such as unauthenticated access to Kubelets, would allow an attacker to bypass the API server, making these logs redundant and therefore bypassing all our detections."

25 ноября в 17:00 (MSK) буду участвовать в вебинаре "Новые вызовы при работе с Kubernetes и как их преодолевать." на площадке СЛЁРМ.

Рассмотрим какие вызовы встают перед компаниями, которые только начинают или уже используют Kubernetes. Посмотрим на это все со стороны разных департаментов: Management, Dev, Ops/SRE, DecSecOps, Security teams. А при рассмотрении различных кейсов коснёмся таких тем как troubleshooting, root cause analysis, optimizations, security и как их можно решить это сторонними OpenSource решениями и решением Luntry.

Будет 4 кейса, буде много live demo и я впервые на большую аудиторию покажу Luntry =)

Недавно прочитал книжку "Kubernetes Security and Observability" (2021).

На обложке сразу красуется пометка "Compliments of Tigera" (а в ранних версиях "Sponsared by Tigera"). Поэтому сразу скажу, что в книге много рекламы Calico Enterprise

Но я расскажу о том, что мне понравилось:
1) Объяснение того, чем подход к обеспечению ИБ в Kubernetes отличается от других систем - очень для многих это будет полезно, так как большинство как я вижу пытаются “натянуть сову на глобус", то есть применить те же подходы что применяли, на пример, в Windows сетях.
2) Объяснение того зачем и почему нужно observability для security и какое оно вообще — это не только logs/metrics/traces.
3) Рассказ о том, как работает сеть в Kubernetes при тех или иных конфигурациях.
4) Описание сути ресурса NetworkPolicy.
5) Глава "Threat Defense and Intrusion Detection" – там есть интересные идеи.

В некоторых вопросах они перегибают палку, специально все сводя к сетевой активности, хотя это можно решить проще другими способами

Чтобы сохранить баланс сегодня немного поговорим о коммерческой версии Isovalent Cilium Enterprise на базе статьи "Detecting a Container Escape with Cilium and eBPF".

Рассматривается 3 этапа атаки:
1) Запуск Privilaged Pod + hostPID + hostNetwork -> exec bash -> и побег через nsenter - честно говоря детский сценарий и чтобы это предотвратить и обнаружить даже eBPF не нужен.
2) Запуск Static Pod в несуществующем namespace для сокрытия его от Kubernetes API Server - техника интересная
3) Выполнение вредоносного python скрипта в памяти — и на хосте того же самого (обнаружения) можно добиться и с помощью SysmonForLinux

Как и при описании Calico Enterprice мне тут не нравится то, что они напрочь откидывают мысль о более простом, правильном способе решении проблем, что они предлагают рассмотреть, а все сводят только к себе. Банальные политики Policy Engines их кейсы решат без проблем.

Лично для меня это вообще перебор и не задача CNI этим заниматься ... Лучше бы NetworkPolicy развивали и упрощали свои.

На канале я уже не однократно писал об инструментах, которые упрощают процесс проведения пентеста контейнерных окружений: CDK, kdigger, Peirates, BOtB, DEEPCE, kubesploit и другие.

И сегодня расскажу еще об одном - ctrsploit!

Можно задаться вопросом зачем еще один инструмент?! Сами авторы данного инструмента отвечают на этот вопрос так: "It's a weapon, not only a proof of concept tool." Они не довольны качеством и стабильностью других решений и написали свой.

Набор команд и возможностей правда хороший:
1) Анализ окружения: тип контейнера, тип graphdriver, информация о cgroups, capabilities, seccomp и apparmor
2) Эксплоиты: CVE-2021-22555 и побег через release_agent в двух вариациях
3) Вспомогательные эксплоиты: CVE-2021-3493 (Ubuntu OverlayFS Local Privesc)

Но в других инструментах есть и свои самобытные фичи, так что не надо сбрасывать их со счетов. Интересно когда кто-нибудь возьмет и объединит все в один проект?)

Пару недель назад вышла новая версия Gatekeeper v3.7.0! Я там выделю 3 основных нововведения:
1) Mutation возможность перешла в статус Beta
2) Gator CLI в alpha для тестирования constraint templates и constraints без Kubernetes
3) External Data для валидации в статусе alpha

Если первые два нововведения уже давно есть в Kyverno, то вот третье выглядит очень перспективно по сравнению с тем, что сейчас позволяет Kyverno: в качестве внешних источников данных только ConfigMaps и Kubernetes API Server. А эта же фича в Gatekeeper позволяет задать любой URL!

В качестве примера посмотрите статью "Verifying container signatures on Kubernetes with Gatekeeper" и код cosign-gatekeeper-provider, где это используется, а также показывается связка с cosign. По сути, такое же было в моем посте про Kyverno и cosign.

Также в статье упоминается Cosigned Admission Webhook от самого sigstore, так что можно просто реализовать проверку подписи образов без использования этих Policy Engines.

Потом думаю таким же способом через External Data реализуют и проверку SBOM для образов для повышения безопасности supply chain.

Для тех, кто хочет посмотреть, что там с Mutation ресурсов, то есть статья "Mutating Kubernetes resources with Gatekeeper".

Очень классные нововведения ждем, когда они доберутся до GA, а так если будете их использовать, то не забывайте их отдельно включать и что они пока не рекомендуются для использования в production.

Запись моего вебинара "Новые вызовы при работе с Kubernetes и как их преодолевать", где я в режиме live демонстрирую как сотрудники департаментов Management, Dev, Ops/SRE, DecSecOps, Security могут решать задачи связанные с troubleshooting, root cause analysis, optimizations, security с помощью OpenSource решений и нашим Luntry.

Что касается security задач - я показал, как можно обнаруживать аномальное поведение внутри контейнеров (может быть спровоцировано эксплуатацией 1day или 0day уязвимостей или запуском вредоносного кода в контейнере) и как можно автоматически генерировать ресурс NetworkPolicy.

Пока что Luntry умеет генерировать только классическую NetworkPolicy, но в декабре мы добавим генерацию NetworkPolicy в соответствующих форматах, реализуемых в CNI Calicо и Cilium. Они на самом деле все отличаются как по формату, так и по возможностям.

Всех с международным днём защиты информации ;)