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

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

В этом году на 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.

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