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

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

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

В этом году на 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! Все в одной системе, все связано и прозрачно для всех ;)