По заказу Kubernetes Security Working Group в середине 2019 года ряд сторонних компаний делали аудит безопасности Kubernetes. Целью был актуальный на тот момент Kubernetes 1.13.4.
Ориентир работ был на:
- Networking
- Cryptography
- Authentication & Authorization (including Role Based Access Controls)
- Secrets management
- Multi-tenancy isolation: Specifically soft (non-hostile co-tenants)
На все про все было 8 недель и результатом работы стало 4 документа:
- Kubernetes Security Review
- Attacking and Defending Kubernetes Installations
- Whitepaper
- Threat Model
Несмотря на то, что данные документы в некоторых моментах устарели (текущая стабильная версия уже 1.18) — это определенно лучший старт для технического погружения в безопасность Kubernetes, нового исследования в данной теме или участия в BugBounty Kubernetes.
Подробнее о каждом из документов, пройдемся в отдельных постах.
Ориентир работ был на:
- Networking
- Cryptography
- Authentication & Authorization (including Role Based Access Controls)
- Secrets management
- Multi-tenancy isolation: Specifically soft (non-hostile co-tenants)
На все про все было 8 недель и результатом работы стало 4 документа:
- Kubernetes Security Review
- Attacking and Defending Kubernetes Installations
- Whitepaper
- Threat Model
Несмотря на то, что данные документы в некоторых моментах устарели (текущая стабильная версия уже 1.18) — это определенно лучший старт для технического погружения в безопасность Kubernetes, нового исследования в данной теме или участия в BugBounty Kubernetes.
Подробнее о каждом из документов, пройдемся в отдельных постах.
Kubernetes не безопасен по умолчанию или правильнее будет сказать не использует механизмы безопасности по умолчанию. И это понятно, потому что любые ограничения затрудняют внедрение или перенос приложения. Поэтому по умолчанию все отключено и сделано для того, чтобы первый опыт запуска/переноса своего приложения был простым и приятным. Никто не хочет мигрировать в новое окружение и иметь непонятные проблемы, из-за которых уже работающее приложение не работает. Это относится не только к Kubernetes но и к другими системам тоже. Так что после того, как вы запустили свое приложение в Kubernetes имейте это в виду. Kubernetes имеет/умеет практически все что нужно: RBAC, NetworkPolicy, PodSecurityPolicy (включая seccomp, AppArmor, SeLinux) и т.д.
Отличный writeup, демонстрирующий как уязвимость/проблема в ПО в кластере может привести к компрометации внутренней инфраструктуры кластера, на примере уязвимости Slack TURN сервере. Сама уязвимость/проблема напоминает SSRF (server-side request forgery), но не ограничивается HTTP протоколом. В итоге, Slack TURN сервер выглядит как обычная прокся во внутреннюю инфраструктуру. Тоесть можно:
- Подключаться к AWS meta-data сервису на http://169.254.169.254 и получать IAM temporary credentials
- Подключаться к открытым портам на localhost, которые не доступны из сети интернет (на пример, node exporter): 22, 25, 53, 443, 515, 5666, 8500, 8888, 9090 и 9100
- Сканирование портов в Slack AWS инфраструктуре 10.41.0.0/16 и т.д.
При этом данная проблема с TURN известна авторам с 2017 года (по их словам) и данное поведение TURN сервера является не багой, а фичей и решается на конфигурационном уровне.
- Подключаться к AWS meta-data сервису на http://169.254.169.254 и получать IAM temporary credentials
- Подключаться к открытым портам на localhost, которые не доступны из сети интернет (на пример, node exporter): 22, 25, 53, 443, 515, 5666, 8500, 8888, 9090 и 9100
- Сканирование портов в Slack AWS инфраструктуре 10.41.0.0/16 и т.д.
При этом данная проблема с TURN известна авторам с 2017 года (по их словам) и данное поведение TURN сервера является не багой, а фичей и решается на конфигурационном уровне.
Kubernetes Threat Model
Мне известно по крайней мере 2 ее реализации (обе они разные и дополняют друг друга):
1) Как результат Kubernetes Third Party Security Audit от сторонних ИБ компаний. Документ содержит dataflow, Threat Actors, описание компонентов, Trust Zones и взаимодействие компонентов, контроли безопасности, реализуемые в них, рекомендации по их улучшению.
2) От CNCF Financial Services User Group. Документ содержит K8s Attack Tree.
При договоре с заказчиком всегда обсуждается какие модели угроз и модели нарушителя аудитор будет применять/проверять в процессе аудита - так что это очень полезные доки, чтобы разговаривать на одном языке аудиторам и k8s владельцам.
Не забывайте, что система развивается и Attack Surface и Threat Model могут изменяться.
Мне известно по крайней мере 2 ее реализации (обе они разные и дополняют друг друга):
1) Как результат Kubernetes Third Party Security Audit от сторонних ИБ компаний. Документ содержит dataflow, Threat Actors, описание компонентов, Trust Zones и взаимодействие компонентов, контроли безопасности, реализуемые в них, рекомендации по их улучшению.
2) От CNCF Financial Services User Group. Документ содержит K8s Attack Tree.
При договоре с заказчиком всегда обсуждается какие модели угроз и модели нарушителя аудитор будет применять/проверять в процессе аудита - так что это очень полезные доки, чтобы разговаривать на одном языке аудиторам и k8s владельцам.
Не забывайте, что система развивается и Attack Surface и Threat Model могут изменяться.
Кратко рассмотрим результат Kubernetes Third Party Security Audit из документа Kubernetes Threat Model. На скриншоте вы видите насколько оценили аудиторы уровень реализации контролей для того или иного компонента. Все эти компоненты (8 штук) были проанализированы и в них выделено 17 проблем – от информационного до среднего уровня:
- kube-apiserver – 2 проблемы
- etcd – 2 проблемы
- kube-scheduler – 2 проблемы
- kube-controller-manager и cloud-controller-manager – 2 проблемы
- kubelet – 2 проблемы
- kube-proxy – 1 проблема
- Container Runtime – 1 проблема
И еще 6 общесистемных проблем.
При этом есть проблемы, которые актуальны и по сей день для Kubernetes! Напомню, что отчет был на основе Kubernetes 1.13.4.
- kube-apiserver – 2 проблемы
- etcd – 2 проблемы
- kube-scheduler – 2 проблемы
- kube-controller-manager и cloud-controller-manager – 2 проблемы
- kubelet – 2 проблемы
- kube-proxy – 1 проблема
- Container Runtime – 1 проблема
И еще 6 общесистемных проблем.
При этом есть проблемы, которые актуальны и по сей день для Kubernetes! Напомню, что отчет был на основе Kubernetes 1.13.4.
Если вам нечем заняться на самоизоляции или просто на выходных, то есть прекрасная возможность и время интересно провести и с Kubernetes поиграться на Mini Kubernetes Easter CTF (базируется на AWS EKS). Образы контейнеров доступны на DockerHub. Для участия просто вводите команды в поле “Command” на сайте, так что берете и вбиваете
kubectl и понеслась!На днях в свободном доступе появилась книжка "Building Secure & Reliable Systems" от SRE инженеров Google.
Слово Kubernetes встречается 21 раз (Cloud - 95, GCP - 3, AWS - 4, Azure - 0). Книга не о Kubernetes, а о построение систем в целом. Но в ряде моментов есть не двусмысленные намеки (примеры) на то, что если хотите secure и reliable, то все что нужно для достижения этого заложено в концепцию Kubernetes.
Слово Kubernetes встречается 21 раз (Cloud - 95, GCP - 3, AWS - 4, Azure - 0). Книга не о Kubernetes, а о построение систем в целом. Но в ряде моментов есть не двусмысленные намеки (примеры) на то, что если хотите secure и reliable, то все что нужно для достижения этого заложено в концепцию Kubernetes.
Каждая инфраструктура с Kubernetes уникальна -> Attack Surface, Threat model соответственно. Значит подход к вопросам обеспечения ее безопасности и ее стороннего аудита будет в каждом отдельном случае иметь свою специфику.
Начинаем с Kubernetes интерфейсов: Container Runtime Interface (CRI), Container Networking Interface (CNI) и Container Storage Interface (CSI). Продолжаем кучей проектов, без которых очень сложно обойтись в реальной (не тестовой) инфраструктуре - список можно посмотреть на портале CNCF Cloud Native Interactive Landscape (также надо будет позаботится и о безопасности данных сущностей). Заканчивая разными Custom Resource Definitions (CRD), кастомными операторами и контроллерами - точек встраивания и изменения в Kubernetes предостаточно. И, конечно, все это приправляем различными версиями этих сущностей, версиями API и т.д.
Сложность системы повышается и возможностей ошибиться тоже. Но сам Kubernetes дает и много возможностей это контролировать и не нужно это оставлять без внимания.
Начинаем с Kubernetes интерфейсов: Container Runtime Interface (CRI), Container Networking Interface (CNI) и Container Storage Interface (CSI). Продолжаем кучей проектов, без которых очень сложно обойтись в реальной (не тестовой) инфраструктуре - список можно посмотреть на портале CNCF Cloud Native Interactive Landscape (также надо будет позаботится и о безопасности данных сущностей). Заканчивая разными Custom Resource Definitions (CRD), кастомными операторами и контроллерами - точек встраивания и изменения в Kubernetes предостаточно. И, конечно, все это приправляем различными версиями этих сущностей, версиями API и т.д.
Сложность системы повышается и возможностей ошибиться тоже. Но сам Kubernetes дает и много возможностей это контролировать и не нужно это оставлять без внимания.
Если вы абсолютно не знаете, как подступится к безопасности своего приложению на базе микро сервисов, то можно начать с «OWASP Сheat Sheet Series. Microservices-based security architecture documentation» и для этого будет достаточно взять листок бумаги с ручкой или excel табличку + пообщаться с вашей командой разработки. Данный Сheat Sheet естественно подходит и при использовании Kubernetes. Основная суть/соль — это инвентаризация, описание, выстраивание связей и поддержка актуальности ваших знаний о системе. Можно об этом посмотреть и в видео.
YouTube
Александр Барабанов,OWASP Сheat Sheet Series.Microservices-based security architecture documentation
Как в мире микросервисов иметь актуальную информацию о каждом из них с точки зрения безопасности? Попробуем найти решение этой проблемы и презентуем новую памятку в рамках проекта "OWASP Сheat Sheet Series"
Безопасность Helm v2.
Основные моменты по обеспечению безопасности Helm v2:
- включение RBAC, использование специализированного service-account
- использование namespaces'ов для Tiller multi-tenancy
- использование secrets вместо ConfigMaps для стораджа
- использование HTTPS для репозитариев
- использование подписи для Chart'ов и их проверка
- включение TLS на gRPC для Tiller сервиса
Послушать об этом можно в выступлении "Безопасность Helm", что базируется на документации проекта. Helm v3 претерпел значительные изменения - там отказались от Tiller (что значительно уменьшило AttackSurface) и используют более нативную интеграцию с помощью CRD. О безопасности Helm v3 в следующий раз.
Основные моменты по обеспечению безопасности Helm v2:
- включение RBAC, использование специализированного service-account
- использование namespaces'ов для Tiller multi-tenancy
- использование secrets вместо ConfigMaps для стораджа
- использование HTTPS для репозитариев
- использование подписи для Chart'ов и их проверка
- включение TLS на gRPC для Tiller сервиса
Послушать об этом можно в выступлении "Безопасность Helm", что базируется на документации проекта. Helm v3 претерпел значительные изменения - там отказались от Tiller (что значительно уменьшило AttackSurface) и используют более нативную интеграцию с помощью CRD. О безопасности Helm v3 в следующий раз.
Возможные модели нарушителей для Kubernetes (взято из ранее уже упомянутого стороннего аудита безопасности платформы). В принципе, тут со всеми все ясно кроме если только последнего действующего лица в этом списке - "End user". Его туда добавили, так как некоторые атаки могут проходить через обычных пользователей приложений, что хостятся в кластере (например, Cross-Site Request Forgery (CSRF)). И как вы понимаете это в первую очередь проблема безопасности приложения что там хостится, а не самого Kubernetes. Но все равно такой сценарий атаки через одно звено (через пользователя), а далее уже и на сам Kubernetes возможен.
Везде пишут, что для хранения критичной информации используйте
1) Необходимо использовать `EncryptionProviderConfiguration` (появился с Kubernetes 1.7)
2) Необходимо создать конфиг файл и передать его через
3) Можно задавать какие ресурсы вы хотите шифровать (не только
3) Есть поддержка 3 типов шифрования:
4) Ключи шифрования хранятся на диске всех api-servers нод, если вы не используете
На скриншоте вы видите возможности атакующего до использования шифрования данных в
Secrets, вместо ConfigMaps. Но она все равно хранится в открытом виде, так как не настроено шифрование. Важно знать следующее:1) Необходимо использовать `EncryptionProviderConfiguration` (появился с Kubernetes 1.7)
2) Необходимо создать конфиг файл и передать его через
--encryption-provider-config аргумент kube-apiserver - он отвечает за шифрование и дешифрование данных3) Можно задавать какие ресурсы вы хотите шифровать (не только
Secrets)3) Есть поддержка 3 типов шифрования:
aescbc, secretbox и aesgcm (все симметричное)4) Ключи шифрования хранятся на диске всех api-servers нод, если вы не используете
Key Management Service (KMS)
5) Ключи шифрования можно и нужно ратироватьНа скриншоте вы видите возможности атакующего до использования шифрования данных в
etcd и после их шифрования с использованием KMS.Что нужно подготовить заранее при пентесте/аудите Kubernetes инфраструктуры?
Конечно же, специального подготовленный image с кучей хакерских/пентестерских и просто Kubernetes, container - specific инструментов. Если у вас есть возможность запустить свой Pod, со своим image, то стоит его заранее подготовить и выложить, для последующей выкачки и установки. Так что делайте его заранее и в качестве ориентира могу вам посоветовать проект - botty. Внутри есть kubectl, krew c плагинами, botb, peirate, gcloud, istioctl, amicontained, dive, linuxprivchecker.py, conmachi, helm2, и много еще чего полезного (curl, dnsutils, nmap, ...). Постепенно мы пройдемся по каждому инструменту в отдельности. При этом данную сборку еще явно есть чем дополнить
Также понадобится и специально подготовленное YAML описание для Pod'а, в котором будет работать image. Оно может помочь сделать побег из контейнера (зависит от наличия и настроек PodSecurityPolicy). Об этом также поговорим отдельно.
Конечно же, специального подготовленный image с кучей хакерских/пентестерских и просто Kubernetes, container - specific инструментов. Если у вас есть возможность запустить свой Pod, со своим image, то стоит его заранее подготовить и выложить, для последующей выкачки и установки. Так что делайте его заранее и в качестве ориентира могу вам посоветовать проект - botty. Внутри есть kubectl, krew c плагинами, botb, peirate, gcloud, istioctl, amicontained, dive, linuxprivchecker.py, conmachi, helm2, и много еще чего полезного (curl, dnsutils, nmap, ...). Постепенно мы пройдемся по каждому инструменту в отдельности. При этом данную сборку еще явно есть чем дополнить
Также понадобится и специально подготовленное YAML описание для Pod'а, в котором будет работать image. Оно может помочь сделать побег из контейнера (зависит от наличия и настроек PodSecurityPolicy). Об этом также поговорим отдельно.
Продолжаем тему самообучения. И сегодня у нас проект kubernetes-simulator от CNCF Financial Services User Group. Данная платформа призвана повысить уровень знаний в области информационной безопасности Kubernetes. Позволяет посмотреть на проблемы как с атакующей, так защищающей стороны, что будет полезно blue team, red team и forensics team. На сегодняшний день включает в себя около 25 сценариев (проблем с подзадачами) различной сложности (Easy, Intermediate, Hard). При этом в системе сразу предусмотрен механизм подсказок если вы зашли в тупик. Сценарии связаны с контейнерами, etcd, control-plane, сетью, нодами, PodSecurityPolicy, RBAC, секретами. Для работы с этой тренировочной платформой вам понадобится доступ к AWS, где все развернется по скриптам.
Автор Kubernetes Easter CTF, о котором я писал ранее, выложил весь исходный код и ресурсы, используемые в контесте. Можно посмотреть, где были спрятаны все 9 флагов, как вообще был устроен контест и взять его за основу для организации собственного. А кто не успел может его развернуть для себя и попробовать пройти самостоятельно.