Если после прочтения постов о подходе 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.

Неожиданно NSA совместно с CISA выложили свой документ "Kubernetes Hardening Guidance"!

Там в 59 страницах есть 7 основных разделов:
- Threat model
- Kubernetes Pod security
- Network separation and hardening
- Authentication and authorization
- Log auditing
- Logging
- Upgrading and application security practices

В данном документе вы не найдете никаких откровений, новшеств по сравнению с той же презентацией от DoD. По мне так рядовой документ (за исключением кто его автор) - подобные документы выпускают с разной периодичностью вендоры разных security решений.

Так документ подойдет новичкам, которые только начинают обращать свое внимание на безопасность Kubernetes. Отдельно наверно отмечу раздел Appendix, где собраны различные примеры тех или иных best practices и харденингов.

P.S. Документ похоже долго ждал публикации и там до сих пор рассматривается деприкейтнутая PSP.

Несколько недель назад разработчики ServiceMesh Istio обнародовали отчет стороннего security аудита.

По большому счету результатом этой работы стало появление очень хорошего раздела "Security Best Practices" в документации Istio. Да, какие-то проблемы разработчики поправили, но большинство находок исследователей носят архитектурный характер и поправить их либо очень сложно, либо невозможно в силу тех или иных обстоятельств (обратная совместимость и т.д.). В анонсе прям есть раздел «The tradeoff between useful and secure», посвященный этой теме.

Анализ проводился для версии 1.6.5 (версия актуальная на июль 2020), а ряд из находок рабочие и для текущей версии 1.10 (да и для будущей 1.11). Естественно, себе на заметку это должны взять RedTeam команды и выдумывать ничего не надо.

Мое самое любимое:
- Default Production Profile Not Sufficiently Hardened
- Default Sidecar Image Not Hardened
- Istio Client-Side Bypasses
- Sidecar Envoy Administrative Interface Exposed To Workload Containers
- Default Injected Init Container Requires Sensitive Capabilities
- Weak Trust Boundary Between Workload Container and Proxy Sidecar

По сути, это все позволяет, попав в workload "накрытый" Istio sidecar не унывать и делать обходы, побеги, lateral movement и т.д. Так что атакующего внутри скомпрометированного Pod'а мало что остановит из арсенала Istio, который еще надо соответствующе правильно настроить с приложениями (ресурсы AuthorizationPolicy, PeerAuthentication, RequestAuthentication).

P.S. NetworkPolicy никто не отменял ;)

P.S.S. Думаю так долго не публиковали отчет (прошел год), чтобы всех заинтересованных лиц предупредить, продумать какие-то смягчающие меры и т.д. и т.п.

25,000$ выплатила компания Snapchat в рамках своей BugBounty программы исследователю, нашедшему кластер с доступным без аутентификации Kubernetes API из сети интернет.

На этом все - всем хороших выходных =)

P.S. Обратите внимание на даты репорта и публичного раскрытия. Сколько подобных историй еще не рассказано?!

На прошлой неделе состоялся релиз Kubernetes 1.22. Там было аж 56 улучшения, что на текущий момент самый масштабный релиз. Вопросы безопасности не остались без внимания, я бы даже сказал - были одними из самых фундаментальных:

- PodSecurity admission controller (alpha feature) - замена старой PSP
- Unprivileged users to bind low ports using the sysctl in the security context - теперь биндить порты в контейнере ниже 1024 можно и не привилегированным пользователем (не root)
- NetworkPolicyEndPort (beta feature) - возможность работы с диапазоном портов в NetworkPolicy (но вы все также зависите от своего CNI - он должен это уметь поддерживать)
- Immutable label selectors for all namespaces - будет проще работать с NetworkPolicy
- Default seccomp (alpha feature) - использование встроенного seccomp профиля для всех контейнеров по умолчанию (будет заблокировано около 60 syscalls)
- Kubelet-in-UserNS (aka Rootless mode) (alpha feature) - это позволит всем Kubernetes компонентам и контейнерам работать от non-root пользователей, тем самым значительно снизив риск при побеге из контейнера. Для запуска нужно активировать KubeletInUserNamespace в feature gate.

Это далеко не все моменты связанные так или иначе с ИБ - лучше просмотреть полный список. Из того что я еще лично очень ожидаю, так это полную поддержку Cgroupsv2, которая сейчас только частичная.

P.S. Теперь придётся значительно обновить свои доклады и тренинг …

Несколько недель назад я писал о компрометации Kubernetes окружения через UI от Argo Workflow для запуска майнеров.

А сегодняшняя история о инциденте похожем на этот как две капли воды. И речь идет о зафиксированной Microsoft атаках на Kubeflow (год назад такое оказывается тоже было). Там также его UI выставленный на общее обозрение в интернет. Видимо, чтобы максимальное количество людей приобщить к Machine Learning (ML) ;)

Из примечательного:
- Используется легитимный образ TensorFlow с официального аккаунта Docker Hub
- Атакующие создают свой Kubeflow Pipelines, который базируется на Argo Workflow (БИНГО!)
- Злоумышленники для наращивания вычислений используют также образы с поддержкой работы с GPU - очень удобно майнить =)

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

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

Перечитывал "Service Discovery in Kubernetes - Combining the Best of Two Worlds" и знать это полезно не только для понимания как все устроено и повышения надежности работы системы, но и для повышения уровня безопасности (и там, где Kubernetes не используется вовсе).

Знаю, что в некоторых компаниях над service discovery много что надстраивают в плане безопасности. На пример, момент инвентаризации сервисов, может ли вообще service использоваться в данном окружении, с кем он и как может общаться и т.д. Сам Service Registry обогащается дополнительной информацией, контекстом и становиться немного умнее (но при этом не стоит забывать и об угрозах и атаках связанным с этим).

В разрезе Kubernetes, я бы это сформулировал как управление созданием ресурсов Service через policy engines, контроль применения NetworkPolicy.

P.S. Внутри этой статьи есть классные отсылки на замечательный сайт "Microservice Architecture", где отдельно отмечу раздел Patterns. Правильная безопасность, начинается с правильной архитектуры - иначе все может превратиться в латание дыр и набор костылей ...

Наверное, уже все слышали про проект CoPilot от GitHub и Microsoft, который по сути является AI помощником для программиста.

Народные умельцы его испытали уже и для написания Kubernetes manifest - по данной ссылке представлено видео как пишется/генерируется YAML для Deployment для запуска WordPress и при этом разработчик (человек) нажимает только клавишу tab! Тут все YAML-инженеры должны заволноваться =)

Лично меня еще позабавил комментарий под этим твитом: "lol, I hope it doesn't autofill securtityContext".

Хотя как по мне его бы наоборот можно было просить все заполнять, предварительно обучив на политиках от policy engine, так что бы kubernetes ресурс точно соответствовал всем требованиям, а разработчик об этом не задумывался.

P.S. Решил, что для пятничных постов буду стараться выбирать легкие, забавные, смешные темы для преддверия выходных ;)

Обычно на каналах публикуют классные и полезные материалы. А я сегодня хочу показать пример неудачной статьи "Kubernetes Pentest: Checklist, tools and resources".

Автор начинает со слов "When you arrive at kube-world as a beginner (like me) nothing has sense. ". А дальше непонятно при каких условиях/обстоятельствах, от куда из Pod или с Node, с правами или без, инструментами что уже есть в контейнере или надо отдельно скачать и т.д.

По итогу если вы прям начинающий, то вас это только запутает/демотивирует, а не поможет. А для людей кто более-менее в теме это просто небольшой перечь базовых команд. Для pentest куда более полезнее будет упоминаемый мною ранее репозитарий PayloadsAllTheThings.

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

Дописывая пост, я вообще подумал, что автор специально дает такие вредные советы, чтобы ему было проще защищать свою Kubernetes инфраструктуру =)

Для Kyverno появился очень занимательный проект Policy Reporter, который позволяет отправлять и смотреть результаты работы данного policy engine в режиме аудита (не блокировки) в наши любимые и не очень:
- Grafana Loki
- Elasticsearch
- Slack
- Discord
- MS Teams
- Prometheus Metrics API
- Policy Reporter UI

Последний пункт это отдельный UI для работы с результатами. Вообще удивительно появление данного проекта, да и еще в официальном репозитории, так как почти у всех policy engine платная версия это как раз UI над движком с интеграциями и прочими бизнес плюшками.

Под капотом все на самом деле очень просто и крутится вокруг таких его Custom Resources как PolicyReport и ClusterPolicyReport из группы wgpolicyk8s.io. Это также идет в копилку работы Policy Working Group и приближению к концепции Everything-as-Code, а далее и к SOAR. По аналогии можно будет делать подобное с любым Custom Resources из группы wgpolicyk8s.io!

Вчера несколько друзей мне скинули статью "Hiding in Plaintext Sight: Abusing The Lack of Kubernetes Auditing Policies".

Cуть: Исследователь придумал использовать секцию annotations в K8s манифестах для скрытой передачи данных и организации С2 (C&C, Command and Control).

И все это для того, чтобы объяснить, что важно использовать Audit Log. Оригинально, но мудрено.

При этом нужно понимать, что для реализации представленного сценария у атакующего должны быть не малые права/возможности:
- Доступ из вне с возможности аннотации ресурсов
- Его вредоносный агент установленный на Node или в Pod с правами на получение аннотированного ранее ресурса.

Для большей скрытности можно еще за использовать Static Pods ;)

При выполнении annotate происходит 2 запроса: GET и PATCH, тоесть у атакующего должны быть get и patch verbs в RBAC Role на тот тип ресурсов, что он использует в качестве скрытого канала.

Из полезного могу выделить ссылки о том, как включить Kubernetes logging в AWS, GCP и Azure.

Альберт Эйнштейн говорил: «Только дурак нуждается в порядке — гений господствует над хаосом», но это не верно для работы нескольких департаментов (DEV,QA,SEC,OPS,SRE,...) и вообще в командой работе.

На мой взгляд систематизация и порядок являются важными составляющими надежной и безопасной системы. Особенно когда с системой работает много людей и происходит множество быстрых изменений, как в микросервисных приложениях.

В плане Kubernetes я для себя выделил 2 направления:
1) Подход к организации хранения Kubernetes манифестов - посмотрите "A Better Way of Organizing Your Kubernetes Manifest Files".
2) Подход к организации аннотаций в Kubernetes манифестах - посмотрите "Annotating Kubernetes Services for Humans".

Это позволяет и подход Policy-as-Code применить, и процесс troubleshooting'а упростить и ускорить.

Применяете ли вы такое? Или может у вас есть какие-то свои подходы? Можете поделиться своими наработками, советами в комментариях.

На днях прошел второй eBPF Summit. И уже доступны все записи докладов на YouTube! Я еще не успел все посмотреть, но обязательно после выходных расскажу о своем топе (с прошлого года можно посмотреть тут).

Про eBPF будет полезно послушать всем и тем кто работает с HighLoad системами, и тем кому просто интересны темы observability, network и security. В этом году все доклады имеют маркировку уровня сложности и разбиты на несколько блоков/тем:
- Keynote
- Observability
- Security
- Deploying BPF in Kubernetes
- Networking
- Writing BPF code
- Advanced

Если кратко пробежаться по самим докладам, то там затронуты такие области: SRE, GPU, Continuous Profiling, Attacks, Kernel Security Monitoring, IoT, Windows, Load Balancing, DNS, Firewall, BPF Library Ecosystem, Rust и многое другое.

Всем хороших, продуктивных выходных ;)

P.S. У себя в разработке мы активно используем eBPF и с недавних пор в сочетании с Rust.

Классная статья "Kubernetes — Running Multiple Container Runtimes" в стиле HOW-TO.

Статья о том (мало кто знает) как в Kubernetes можно запускать несколько Container Runtime и использовать их по ситуации (в зависимости от того, что запускаем). В техническом плане здесь описывается как на Nodes настроить containerd (высокоуровневый runtime) для работы с (низкоуровневыми) runC и Kata Containers (базируется на концепции microVM). И потом управлять какой workload где запускать с помощью Kubernetes ресурса RuntimeClass (стандартный ресурс с версии 1.14). При этом стоит отметить, что такое можно проворачивать с любым CRI совместимым Container Runtime, на пример, CRI-O, gVisor и т.д.

Алгоритм:
1) Настраиваем на нужной Node конфиг containerd для работы с Kata Containers
2) Устанавливаем Kata Containers на Node, где правили конфиг containerd
3) Инициализируем Kubernetes Control Plane
4) Помечаем Node с Kata Containers, используя taint и label, для запуска определённых workloads
5) Создаем ресурс RuntimeClass с описанием Kata Containers
6) Создаем workload с соответствующими параметрами для runtimeClassName, nodeSelector, tolerations для запуска в Kata Containers

Таким образом можно разграничивать доверенные и недоваренные workloads. Но не все так замечательно и поговорим об этом завтра.

P.S. Для тех, кому проект Kata Containers очень интересен рекомендую следить за их twitter аккаунтом