На канале я уже не однократно писал об инструментах, которые упрощают процесс проведения пентеста контейнерных окружений: 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. Они на самом деле все отличаются как по формату, так и по возможностям.

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

В этом году на Ekoparty Security Conference 2021 была отдельная секция DevSecOps Space и там есть множество любопытных докладов:

- "Detection and Reaction to threats in Kubernetes with Falco and a FaaS"
- "Istio Service Mesh Security"
- "Kubernetes Native Policy Management with Kyverno!"
- "An Introduction to Container Hacking"

Я лично еще не все посмотрел и перечислил только те что меня заинтересовали.

P.S. Учтите что конференция аргентинская и ряд докладов на испанском =)

Хорошая статья "Примеры выполнения требований ГОСТ Р 57580.1-2017 в средах контейнерной оркестрации на базе Kubernetes" от моего хорошего товарища.

ГОСТ Р 57580.1-2017 - это Национальный стандарт Российской Федерации. Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер.

А у кого-нибудь есть подобный playlist, но для Kubernetes ?)

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

Команда Google Cloud поделилась деталями об обнаруженной ими CVE-2021-25741 (у меня по патчу восстановить идею атаки не получилось) в статье "Exploring Container Security: A Storage Vulnerability Deep Dive". В статье рассматривается:
- как subpath storage system работает
- обзор самой уязвимости (отсылка к CVE-2017-1002101)
- как нашли первопричину и зафиcили ее.

В CVE-2021-25741, атакующий может создать symbolic link с mounted emptyDir на root filesystem на node (/) и kubelet, проследовав по данной symbolic link возьмет и смонтирует host root внутрь контейнера!

9 декабря 10:00 MSK (Online) состоится VK Kubernetes Conference!

И там мне посчастливилось в очень крутой компании выступить с докладом "Kubernetes Resource Model (KRM): Everything-as-Code". Буду про YAML рассказывать и то как на него Dev, Ops и Sec командам нужно правильно смотреть в Kubernetes =)

Регистрация открыта ;)

Задумывались ли вы когда-нибудь как у облачных провайдеров в managed Kubernetes решается к каким облачным сервисам тот или иной Pod имеет доступ, а к каким нет? Если вопрос у вас такой проскакивал, то для вас статья "IAM roles for Kubernetes service accounts - deep dive". В статье все на примере с AWS, но подобное есть уже и у других облачных провайдеров (у российских пока нет):

1) AWS: IRSA (KSA↔️IAM Role) - ServiceAccount annotation eks.amazonaws.com/role-arn
2) Google: Workload Identity (KSA↔️GSA) - ServiceAccount annotation iam.gke.io/gcp-service-account [1]
3) Azure: AAD Pod Identity (KSA↔️AAD) - Workload label aadpodidbinding (Preview статус)

Как вы можете заметить по описанию реализации связей и воплощению они все отличаются от провайдера к провайдеру ...

Вот и состоялся релиз Kubernetes 1.23 с кодовым названием "The Next Frontier"!

О том что там появилось можно посмотреть как на странице релиза или официальном блоге, так и на разборах разных вендоров [1,2]. С точки зрения ИБ я бы выделил следующие вещи:

0) Соответствие Software Supply Chain SLSA Level 1 в Kubernetes Release Process
1) PodSecurity Admission - перешел в Beta и включен по умолчанию. Об этом я писал ранее.
2) IPv4/IPv6 Dual-Stack Support - перешла в GA. Видео с Kubecon NA 2021 об этом.
3) Ephemeral Containers - перешли в Beta и включены по умолчанию. Об этой фиче я писал еще при появлении ее в версии 1.18.

В комментариях вы можете написать, что порадовало больше всего лично вас в этом релизе ;)

Совсем недавно в рамках SANS Blue Team Summit 2021 был представлен доклад "DeTT&CT(ing) Kubernetes ATT&CK(s) with Audit Logs" и сейчас доступны как слайды, так видео выступления.

По мне данный материал более наглядно (с примерами и привязками к техникам из MITRE ATT&CK) дополняет работы "Detection Engineering for Kubernetes clusters" и "Threat Hunting with Kubernetes Audit Logs", о которых я писал ранее.

В конце, автор еще немного показывает, как со всеми этими логами можно работать в Splunk.

Очень простенький сайт для расчета uptime и downtime с соответствующим SLA. Позволяет перевести магию девяток в конкретные временные интервалы в месяцах, днях, часах и т.д.

У кого как вообще обстоят дела с этим ?)

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

Уже несколько дней все security сообщество только и обсуждает Log4Shell уязвимость в библиотеке log4j.

Давайте с вами тоже на это посмотрим, но:
1) в контексте Kubernetes
2) с использованием технологии eBPF
3) с применением классного инструмента Pixie

Все это есть в статье "Did I get owned by Log4Shell?" ;)

Ну а так по мне используйте NetworkPolicy + AppArmor в Kubernetes и подобные 0day вам будут не страшны!

Проект Kubernetes Security Profiles Operator не стоит на месте и активно развивается. Что очень сильно меня радует, так как это мой самый любимый Kubernetes operator [1,2] в теме security и самый мощный в данной области по моему мнению. В ближайшем, будущем он может быть знатным killer'ом коммерческих решений. Так как даст возможность делать detection и prevention стандартными средствами Linux и Kubernetes. При этом сами политики/профили и их связи с workloads имеют отражение как в отдельных Custom Resources, так и связях с нативными ресурсами, что позволяет Dev, Ops и Sec командам всем вместе видеть реальную, текущую картину того, как ограничено в работе приложение в YAML файлах - Security as Code.

И так в данный operator недавно добавили помимо поддержки seccomp еще и отдельные Custom Resources для AppArmor и SeLinux профилей! Там еще не все завершено (текущее состояние отражено на скриншоте), но с какими темпами сейчас там идет работы я уверен, что скоро все доведут до ума!

KubeArmor еще один проект, который двигает направление Security as Code, как и Kubernetes Security Profiles Operator.

Авторы данного проекта позиционируют его как Cloud-native Runtime Security Enforcement System. Под капотом у проекта LSM хуки и для обработки системных вызовов используется известный проект Tracee, который для своей работы использует eBPF.

Так проект позволяет в YAML ресурсах определять политики того, что может и не может делать контейнер (с процессами, файлами и сетью) в Kubernetes.

Проект пока очень молодой и на тестах показал себя сыроватым, но очень амбициозным! Так я очень жду, когда они добавят поддержку LSM eBPF (KRSI). Так это еще один потенциальный killer для коммерческих security решений в области detection и prevention.

P.S. Напоминает проект bpfbox.

Продолжим тему Runtime Security в Kubernetes и сегодня хотелось бы привлечь ваше внимание к интересному PR для проекта falcosidekick, который является по сути прослойкой между Falco и другими система для оповещения.

И так речь пойдет о "WIP: Adds policy report output support for falcosidekick #256" и означает поддержу ресурсов из wgpolicyk8s.io/v1alpha2: ClusterPolicyReport и PolicyReport, над которыми работает Policy Working Group (об этом я писал ранее).

Таким образом еще один проект двигается в направлении Seurity as Code! Все в одной системе, все связано и прозрачно для всех ;)

Ну и пятницу закончим темой что не давала многим покоя всю эту неделю.

Грамотно используйте все встроенные возможности Kubernetes и Linux и будет вам счастье!

Повторю в сотый раз - стройте безопасность микросервисных приложений в Kubernetes от себя, а не от потенциальных возможностей атакующих - в такой игре вы всегда на шаг позади. Понимание себя дает вам возможность быть готовым и защищенным и к 0day уязвимостям.

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

Опубликовано видео моего выступления "Kubernetes Resource Model (KRM): Everything-as-Code" с VK Kubernetes Conference, которая прошла 9 декабря 2021 года.

Именно так я (и многие в индустрии) видят правильное использование Kubernetes, которое позволяет на максимум раскрыть его возможности.

Доклад не про безопасность, но все это справедливо и для безопасности:
- Security as Code
- Policy as Code
- Compliance as Code

На мой взгляд только так можно достичь высокого уровня безопасности в условиях:
- частых и постоянных изменений микросервисов,
- разительной разницы в количестве между разработкой и ИБ,
- нескончаемых патчей 1day и 0day уязвимостей,
- набирающих обороты атак на supply chain.

Старые подходы являются реактивными, пришло время проактивных.

Один из читателей канала подсветил один очень интересный момент касательно Policy Engines и subresources. Этим бы я и хотел сегодня с вами поделиться ;)

Как вы знаете все в Kubernetes это YAML и все YAML проходят через mutating и validating admission controllers, на которых и базируются Policy Engines. Но есть и исключения в виде subresources:
- pods/exec
- pods/attach
- pods/log
- pods/portforward

На просторах сети можно встретить информацию, что их нельзя обработать как другие ресурсы. И я тоже так думал....

Но оказывается они идут через операцию CONNECT (не CREATE, UPDATE) в виде ресурса PodExecOptions, дочерним для Pod, и это можно обработать! Посмотрите:
1) Политика для Kyverno (для Gatekeeper должно тоже работать)
2) Статья "Using K8s Admission Controllers to Detect Container Drift at Runtime" с самописным admission controller (исходный код)

P.S. Ну и про корректный RBAC не забывайте!

P.S.S. Когда-то еще был DenyEscalatingExec ...

Вокруг моего любимого Security Profiles Operator все больше новостей и движухи!

Так за последнее время вышло:
1) Отдельное выступление "Enhancing Kubernetes with the Security Profiles Operator" с KubeCon EU 2021про него
2) Статья "What's new in Security Profiles Operator v0.4.0" в официальном блоге Kubernetes
3) Статья "Secure your Kubernetes deployments with eBPF" на портале Red Hat Developer

Если вы все еще задаетесь вопросом когда это вообще может пригодится, то посмотрите раздел User Stories из документации проекта и все точно станет на свои места =)

Если вы вдруг захотите самостоятельно разработать решение по аутентификации для компонентов вашей системы (workload identity), то не спешите все делать с нуля!

Уже в CNCF существует стандарт SPIFFE (Secure Production Identity Framework For Everyone). Там описывается 3 вещи:
1) SPIFFE ID - уникальный ID для аутентификации
2) SVID (SPIFFE Verifiable Identity Document) - проверяемое криптографическое представление для SPIFFE ID
3) Workload API - для работы с этим всем

Стандарт используется в Kubernetes, Docker, Istio, Consul, Dapr и многих других проектах.

При этом есть и референсная реализация данного стандарта в проекте SPIRE (SPIFFE Runtime Environment). Состоит из 2-х частей:
1) Server - является signing authority и реестром идентификаторов
2) Agents - часть workload для предоставления SPIFFE Workload API

И помните как и в любых реализация любых стандартов есть ошибки. Что и показал 3rd party security audit данного проекта (SPIRE).