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

Компания GitLab зарелиза забавный внутренний проект Package Hunter. Задача которого заключается в обнаружении вредоносных зависимостей в коде через динамический анализ. А именно под капотом у него находится Falco. В общем если во время работы Falco ничего не обнаружит по своим сигнатурам ничего криминального, то считается что вредоносных зависимостей в коде нет ... Так можно это все встроить прозрачно в свой CI.

Обойти такой метод проверки вредоносному коду ничего не стоит:
1) Запуститься только при определенных действиях (На пример, при соединении к приложению)
2) Запуститься через какое-то время или при наступлении какого-то времени

Но, конечно, что-то такое что работает тупо в лоб - данный инструмент может.

И снова один из читателей канала поделился интересным фактом из Kubernetes безопасности.

В CNI Cilium в заголовке пакетов добавляется информация об identity контейнера, что передает данные! При этом разработчик признают, что это security sensitive information и рекомендуют:
1) Либо шифровать весь трафик
2) Либо относится к своей сети как к доверенному окружению (Облака?!) (то есть некоторые модели нарушителя просто не рассматривать)

Это фигурирует только в документации от версии 0.8, а далее этот момент полностью пропал из документации ... Но на практике так все и продолжает работать (опросил ряд компаний)!

Я думаю, что наличие такой default капабилити у контейнеров как CAP_NET_RAW [1,2,3] - открывает атакующим множество интересных атак и это достойно отдельного исследования ;)

С наскоку забуриться в исходный код Cilium и найти эту часть там у меня не получились. Может кто уже копал в этом направлении или хочет к этому присоединиться?

P.S. Может и в правду сделать рубрику #читателипишут ?!

А сегодня поднимем тему шифрование трафика в кластере Kuberneres между Pods. Это может потребоваться как для соответствия каким-нибудь compliance, так и в условиях работы в недоверенном окружении. Я выделил 3 способа (если я что-то забыл пишите в комментариях):

1) На уровне CNI плагинов (Calico, Cilium) с помощью:
- IPSec
- Wireguard
2) На уровне Service Mesh (Istio, Linkerd) с помощью:
- mTLS
3) На уровне ваших приложений с помощью:
- SSL/TLS протоколов

Заметьте что от реализации к реализации в разных CNI есть поддержка разных фич Wireguard.