Копаясь в заметках встреч Policy Working Group, можно найти упоминание документа от Department of Defense (DOD) про "Zero Trust Reference Architecture" с пометкой "has similar concepts for policy" и картинкой из него (в превью данного поста). Поэтому можно судить к чему стремится данная группа при разработке Policy - SOAR (Security Orchestration, Automation and Response)!!!

Еще выжимка оттуда: "Policy Engine & Automation (SOAR): These terms are used to define technologies that handle threat management, incident response, policy enforcement and security policy automation. A Zero Trust Architecture will require dynamic policy enforcement and automation. SOAR will work in concert with analytics and policy engines to develop confidence levels and automate the delivery of policy to enforcement points."

В общем, автоматизация на любые ИБ моменты ;)

Давайте рассмотрим проект, которым уже многие компании у себя закрыли ряд моментов с ИБ. Речь пойдет про Starboard. Он автоматически создает/обновляет security отчеты для того или иного компонента (ReplicaSet, Node и т.д.) при его появлении/изменении. Под капотом у него:
- Vulnerability Scanners: Trivy
- Сonfiguration checkers: Polaris или Conftest
- CIS Kubernetes Benchmark: kube-bench
- Kubernetes cluster pentest: kube-hunter


Речь о нем сегодня не случайно - он как раз является ярким представителем, когда инструменты завернуты в Kubernetes operators (хотя есть и реализация CLI), а результаты работы в виде Custom Resources (на смену которым и должны прийти ClusterPolicyReport и PolicyReport):
- VulnerabilityReport
- ConfigAuditReport
- CISKubeBenchReport
- KubeHunterReport

А далее эти отчеты вы уже можете обрабатывать (сами автоматически считать риски, критичность и создавать тикеты, автоматически реагировать т.д.) и выводить как вашей душе угодно (Grafana и т.д.).

Давайте подытожим сегодня мое виденье о правильном и/или будущем подходе к ИБ в Kubernetes, которое я связываю с OODA loop:

1) Наши любимые инструменты проверок обернуты в Kubernetes operator и автоматически запускаются при появлении/изменении того или иного Kubernetes ресурса, за анализ которого они отвечают.
2) Результат анализа записывается в отдельный унифицированный отчет в виде Kubernetes resource.
3) Специальный Kubernetes operator выполняет роль SOAR (Security Orchestration, Automation and Response) и автоматически реагирует на появлении/изменение отчета анализа на шаге 2.

Тем самым мы получим быструю, автоматическую реакцию на тот или и ной инцидент или нежелательное изменение. При этом можно сказать, что мы приблизим скорость работы отдела ИБ к скорости выкатки новых фич разработки - их скорости должны соответствовать друг другу, а не тормозить процесс.
Также определенные рутинные задачи по ИБ уйдут в прошлое (автоматизация playbooks).

А в качестве пятничного поста я порекомендую (кому интересно) за выходные посмотреть свежее выступление "ATT&CKing Kubernetes: Technical deep dive into ATT&CK for Containers" с конференции Pass the SALT 2021. По сути, оно состоит из примеров, в основном из ITW (In The Wild) кейсов, которые смапленые на матрицу ATT&CK для контейнеров. Также стоит предупредить, что выступление не полное и докладчик не расскажет про защитные меры, так как не уложился в тайминг =)

Одним из двигающих/приоритизирующий механизмов развития NetworkPolicy являются так называемые User Stories - где пользователи описывают, свои истории/ситуации, с которыми они сталкиваются и им их хотелось бы решить относительно стандартной NetworkPolicy (не забываем, что у разработчиков CNI есть и кастомные реализации).

Этот список сейчас будет полезен всем по 2 причинам:
1) Вы узнаете какие возможности только появятся в NetworkPolicy
2) Вы узнаете какие сценарии прямо сейчас вы не сможете реализовать

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

file-integrity-operator - еще один интересный operator с открытым исходным кодом, который используется в RedHat OpenShift. Узнал я о нем недавно, благодаря посту про Kubernetes operators - спасибо за наводку ;)

Он, что логично, позволяет проверять целостность файлов на Node с определенной периодичностью. Для некоторых систем или в соответствии с некоторыми compliance такое может требоваться (типа требований 10.5.5 и 11.5 в PCI DSS) и тут как раз этот operator поможет. В коммерческих решения такая функциональность обычно называется как File integrity monitoring (FIM).

Выполнен о тут в виде DaemonSet в котором запускается привилегированный контейнер с проектом AIDE (Advanced Intrusion Detection Environment), который также имеет открытый исходный код.

Для работы вам помимо самого file-integrity-operator потребуется описать его Custom Resource типа (kind) FileIntegrity (там описывается, где запускаться через nodeSelector, с какой частотой gracePeriod и т.д.) и непосредственно конфиг для AIDE, который выглядит примерно так (что сканировать, а что нет и т.д.).

Результат будет в отдельном специальном ресурсе FileIntegrityNodeStatus (вспоминаем тут тему про отдельный тип ресурсов для Policy), а в процессе работы создаются соответствующие Events ресурсы о продвижении сканирования.

Ни одно серьезное приложение сегодня уже не обходится без сервиса хранения данных. И естественно данный сервис или скорее данные находящиеся там являются чаще всего целью для плохих парней. О защите данного сервиса много говорится и в документе "Cloud Native Security Whitepaper" в разделе "Storage". И вот Microsoft выпустила еще и свою "Threat matrix for storage services". Видимо им очень это понравилось делать самостоятельно без организации MITRE, как они уже делали для Kubernetes.

В матрице, конечно, просматривается некоторый ориентир на специфику Azure, но как база подойдет как для любых managed инсталляций, так и onprem. Помним об обилие решений в категории Cloud Native Storage в CNCF Cloud Native Landscape и то что каждое из этих решений обладает своими механизмами, настройками безопасности, которые требуют правильной конфигурации.

Поговорим сегодня о таких Kubernetes ресурсах как Endpoint и EndpointSlice, а точнее о целых двух новых уязвимостях, связанных с ними.

CVE-2021-25737: Holes in EndpointSlice Validation Enable Host Network Hijack
Уровень Low (CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N)

Краткая суть: "user may be able to redirect pod traffic to private networks on a Node.". Пользователь, конечно, должен иметь права на работу с данным типом ресурса. При этом подобное для Endpoint закрыли, а про EndpointSlice забыли.

Помимо обновления kube-apiserver для митигийшена/закрытия данной проблемы можно использовать policy engine, который предотвращает создание endpoint с адресами в диапазонах 127.0.0.0/8 и 169.254.0.0/16.


CVE-2021-25740: Endpoint & EndpointSlice permissions allow cross-Namespace forwarding
Уровень Low (CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N)

Краткая суть: "that could enable users to send network traffic to locations they would otherwise not have access to via a confused deputy attack."

При этом на это патча нет и не будет и митигейшен заключается только в ограничении доступа к данным ресурсам! (как это закрыть в будущем будет вестись отдельное обсуждение в сообщесте) А да и данному недостатку подвержены все версии Kubernetes. Для обнаружения уязвимых к данному сценарию Services - нужно найти их все с пустыми selector.

Также в описании CVE говорится, что подобная атака возможно и с Ingress, но тут нужно проверять это для каждой реализации отдельно …

Интересный OpenSource проект с GitHub под названием Kubernetes RBAC Model. Это вам может пригодится для быстрой организации multi tenant и multi project RBAC в Kubernetes.

По сути, это набор разноправных готовых Role и RoleBinding для различных проектов, окружений.

Так вы сможете быстро сгенерировать Role:
- cluster-admin
- admin
- dev
- viewer
- bot

Для окружений:
- Dev
- QA
- Stage
- Prod

с разными правами.

А свои корректировки, правки очень просто можно внести в исходный код на CUE.

Достаточно недавно один из моих самых любимых/интересных/перспективных/... Kubernetes operators под названием The Kubernetes Security Profiles Operator получил серьезные обновления.

Огромная работа была проделана в направлении автоматического создания/записи seccomp профиля для нужного Pod. Технически это реализовано с помощью двух механизмов доступных на выбор: oci-seccomp-bpf-hook или через оценку auditd или syslog файлов. Как это все просто сейчас выглядит можно посмотреть в данном видео. Но не забываем о покрытии ПО тестами, чтобы получить максимально полную, правильную картину для профиля!

Таким образом на сегодняшний день данный Kubernetes operators в своем арсенале имеет:
- SeccompProfile CRD для хранения seccomp профилей
- ProfileBinding CRD для связывания профилей и Pods
- ProfileRecording CRD для записи seccomp профиля с Pods
- Синхронизацию seccomp профилей на всех Nodes
- Проверку Nodes на поддержку seccomp
- Поддержку метрик для Prometheus

Очень рад как развивается данный инструмент)

В 2019 году на конференции KubeCon сотрудник U.S. Air Force и Department of Defense (DoD) выступил с любопытным докладом "How the Department of Defense Moved to Kubernetes and Istio".

Как оказалось подход DoD к работе с Kubernetes представлен не только в этом выступлении, но и в целой серии публичных документов. Среди них наиболее близким к тематике канала является документ "DoD Enterprise DevSecOps Reference Design: CNCF Kubernetes" от 2021 года. По сути, документ рассказывает о том, как они подходят к безопасности с использование Kubernetes - для ознакомления он точно MUST READ! Его можно разбить на море отдельных постов, но я выделю несколько на мой взгляд ключевых моментов:

1) Containerized Software Factory - все включая CI/CD pipline контейнерезировано и запущено в Kubernetes, чтобы ко всему применять одни и те же подходы по защите и контролю контейнеров и уменьшить blast radius.
2) Sidecar Container Security Stack (SCSS) - ничему не доверяем и в каждый Pod инжектим sidecar с кучей функций по security, logging, telemetry и т.д. для ZeroTrust.
3) Service Mesh - покрывает все для контроля и распределения всего east-west трафика.
4) Locally Centralized Artifact Repository - централизованное локальное хранилище для всех артефактов с пройденным hardening'ом.

И еще там многое всего другого интересного: IaC/CaC, GitOps, SOAR и т.д.

Все это впечатляет конечно!

Немного продолжу вчерашний пост, связанный с документом от DoD. В презентации "How did the Department of Defense move to Kubernetes and Istio?" на 24 слайде про "Key “DevSecOps”Ingredients" в самом низу есть очень интересный пункт:

Chaos engineering: Dynamically kills/restarts container with moving target defense.

Думаю, что большинство читателей если и слышали про Moving target defense (MTD), то лишь в контексте теории игр. Но на самом деле этот подход используется и в ИБ.

Смысл заключается в том, что ПО/контейнер время от времени меняется, сохраняя общую работоспособность системы.
По сути, его задача "исправить" статичность систем, которые мы защищаем. Так атакующий может получить знания, проанализировать их, подготовится и провести атаку, а с MTD имеющиеся у него знания за время подготовки просто станут не пригодными. Тем самым немного нивелируется позиция, что атакующий находится на шаг впереди.

Образно представьте игру морской бой, где после каждого вашего выстрела противник еще и корабли переставляет - согласитесь не просто выиграть в таких условиях)

Так и в их концепции при Chaos engineering они перезапускают контейнеры (возможно и Node) тем самым атакующему и закрепится сложно в системе и провести хорошую целенаправленную атаку.

P.S. Рекомендую по теме еще почитать академическую работу "Moving Target Defense Using Live Migration of Docker Containers" (внутри используют классный проект CRIU).

Вчера друзья скинули новость с громким заголовком "New Attacks on Kubernetes via Misconfigured Argo Workflows".

Что под этим скрывается?

Если взять Argo Workflows и сделать его доступным из сети интернет без аутентификации, то атакующий, используя его, может запустить в инфраструктуре жертвы майнер ...

Мои мысли на этот счет:
1) Если обратится к матрице ATT&CK для Kubernetes, то это относится к Initial access -> Exsposed sensitive interface.
2) Раньше все подобное писали про Kubernetes Dashboard, но сейчас этим никого ни удивить и начали писать про сторонние решения с WEB-интерфейсом и возможностью запуска контейнеров в тех или иных Custom Resources. В портфели у Argo есть еще парочка таких проектов и ждем статьи про них)
3) Статья от антивирусного вендора и по мне там больше внимания уделено самому майнеру, который они успешно смогут по их заявлениям поймать. Что меня невольно наталкивает на мысль что это может быть чистой воды PR ход.
4) Скриншот с одиноко запущенным Pod’ом с майнером внутри смотрится как-то не очень правдоподобно ...
5) Выставить данный WEB-интерфейс наружу в сеть интернет, надо еще запарится как по мне =)

В общем, не забываем про аутентификацию, принцип наименьших привилегий и контроль north-south трафика ;)

Сегодня планировал опубликовать совсем другой пост. НО не могу пройти мимо этого прекрасного “патча”, представителя принципа security through obscurity ведь основная проблема не закрыта - Kubernetes dashboard так же доступен, на что и указывают в комментариях.

По классификации ATT&CK для Kubernetes все как и во вчерашнем посте.

Если после прочтения постов о подходе DoD к безопасности инфраструктуры Kubernetes и приложений задумались о таком же, то нужно чтобы все работало в Kubernetes =)

Вас это может пугать или озадачивать как это вообще может выглядеть, разворачиваться, работать и т.д. Не пугайтесь есть вариант это достаточно быстро попробовать самим!

Специально для CloudNative Days Tokyo 2020 ряд специалистов сделало проект Kubernetes-native Testbed. Как вы уже наверно поняли еще по скриншотам - они взяли и сделали сборку, где все включая СI\CD окружение запущено в Kubernetes. Более подробнее о данном проекте можно прочитать в их статье "Kubernetes-native testbed OSS for modern cloud native architecture".

Все на Kubernetes operators, Custom resources - в общем мне нравится данный проект. Чего не хватает можно легко докинуть теме же Kubernetes operators, что мы рассматривали недавно: Starboard, Kubernetes Security Profiles Operator, file-integrity-operator, Compliance Operator и т.д., сделав основу для SOAR ;)

29 июля в 19:00 (по Мск) в рамках [ Online Monitoring Meetup ] от MONHOUSE я выступлю с докладом "Kubernetes: Observability — важная часть Security". Для тех, кто не знает MONHOUSE это сообщество, где собираются люди и знания по вопросам мониторинга и автоматизированного управления.

В рамках своего выступления я хочу показать, что направление observability шире, чем многие на него привыкли сейчас смотреть. А именно как observability способно помочь значительно повысить уровень безопасности в Kubernetes кластерах. А также еще раз убедить в том, что нельзя сделать надежным и безопасным то, что вы не видите и не контролируете.


Мои основные тезисы:
- Неразрывная связь security и reliability
- Observability это не только логи, метрики и трейсы
- "Complexity is the worst enemy of security, and our systems are getting more complex all the time.", Bruce Schneier
- "Scientia potentia est"
- Observability для Continuous inventory и Continuous security profiling

Регистрация тут!

В начале июля вышел крутой writeup под заголовком "CVE-2021-22555: Turning \x00\x00 into 10000$" про уязвимость на heap в Linux Netfilter. Чем она примечательна:

1) Ей 15 лет - только представьте какое покрытие: с 2.6.19 до 5.15! Обновляйте Nodes ...
2) Позволяет обойти все современные security mitigations (SMAP/KASLR/SMEP) и выполнить произвольное выполнение кода в ядре.
3) Для демонстрации автор выбрал нарушение Kubernetes POD isolation на кластере kCTF (о нем я уже писал)

Для успешной эксплуатации уязвимости атакующему нужно CAP_NET_ADMIN capability внутри контейнера. Ну и, конечно, отсутствие AppArmor/SeLinux/seccomp профилей. Также атакующему на руку сыграет то, что вы не видите, то, что происходит внутри ваших Pod'ов - недостаток observability.

В заголовочную картинку я вынес payload, который непосредственно позволяет сделать container escape. Вот такой он маленький, простенький и при том универсальный.

Автор также выложил и PoC эксплоита - MUST HAVE для всех пентестеров ;)

Продолжим тему уязвимостей и сегодня рассмотрим "старую", но интересную уязвимость в самом Kubernetes под идентификатором CVE-2020-8562. Детальное описание эксплуатации данной уязвимости опубликовали совсем недавно в статье "Kubernetes Vulnerability Discovered That Allows Access to Restricted Networks (CVE-2020-8562)".

Основное:
1) Проблема скорее актуальна для облачных провайдеров, предоставляющий услугу managed Kubernetes (без доступа к control plane)
2) Патча не планируется - только временный mitigation
3) Известна с апреля 2020, а широкой аудитории с мая 2021
4) Уязвимость позволяет http(s) proxy доступ к kube-apiserver localhost и linklocal (cloud metadata)
5) Для атаки атакующий должен уметь создавать фейковую Node, которая будет иметь произвольный сетевой адрес

IMHO это отличный пример, когда, посмотрев на систему под определенным углом (в определенной модели угроз, модели злоумышленника) можно найти очень интересные вещи. И кто знает сколько подобных уязвимостей еще есть в облаках?!

Легкий пятничный пост про сетевую безопасность в Kubernetes =)

Также это тонкий намек, что на следующей недели много поговорим про NetworkPolicy, ServiceMesh (Istio), Egress Gateways и моменты связанные с сетью.

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

P.S. А для тех кто и в пятницу хочет хардкора, то обратите внимание на тему DNS-туннелей и тулзы типа DNSStager, которые позволяют вольготно себя чувствовать атакующим в Kubernetes и не только сетях.

В одном из предыдущих постов я уже писал, что SIG Network работает над нововведениями в NetworkPolicy среди которых и ClusterNetworkPolicy (CNP).

За обсуждением этого можно понаблюдать как в видео формате (прошедшего митинга), так и в отчете группы.

Наиболее интересное это:
- KEP-2091: Add support for ClusterNetworkPolicy resources
- Презентация "CNP: User stories + Samples" с кучей примеров

Помимо этого, в глаза бросается такое нововведения как:
- Появление поля action с возможными значениями Allow, Deny, Empower - раньше все политики работали только по принципу Allow.

Также идет обсуждение о "Numerical Priority System" как в CNI Antrea от VMware.

Весь сетевой трафик в Kubernetes можно разделить на две категории:
1) East-West - трафик внутри K8s кластера
2) North-South - трафик, входящий и исходящий в K8s кластер

Внутри они делятся на Ingress и Egress, соответственно к Pod'ам и от них.

Сегодня остановимся на North-South ситуации. Для Ingress (стандартный ресурс K8s с реализацией на стороне контроллера + на смену идет Gateway API) важно контролировать:
- что вы выставляете наружу
- какой сервис что обрабатывает, чтобы не было перехвата

Для Egress (такого ресурса нет) важно контролировать:
- куда есть доступ наружу, а куда нет.

Egress трафик для North-South можно контролировать 3 способами:
1) Используя NetworkPolicy или возможности ServiceMesh
2) Конфигурацией NAT
3) С помощью Egress gateways

Каждый способ имеет свои "+/-" и зависит от используемого CNI и/или ServiceMesh.