В продолжение моего недавнего поста про безопасность при node-based multi-tenancy - в официальном блоге Kubernetes вышла статья "Advanced Kubernetes pod to node scheduling"

В ней очень просто, понятно с примерами рассматриваются такие Use Cases для Pod-to-Node Scheduling, как :
- Running pods on nodes with dedicated hardware
- Pods colocation and codependency
- Data Locality
- High Availability and Fault Tolerance

Странно, но сценарий, связанный с ИБ отсутствует. Хотя можно придумать множество таких сценариев: распределение сервисов, что обрабатывают критичную информацию, или отделение сервисов, что часто грешат уязвимостями, или сервисы внутренней разработки отделять от сторонних разработк и т.д.

В статье рассматриваются следующие механизмы и стратегии:
- nodeSelector
- Node Affinity
- Inter-Pod Affinity
- Taints and Tolerations
- Pod Anti-Affinity

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

И еще раз продолжая тему распределения рабочих нагрузок (Pod) по Nodes, рассмотрим ситуацию когда нужно чтобы нагрузка выполнялась на Nodes с определенными устройствами. На пример, таких как FPGA, GPU, high-performance NICs, InfiniBand adapters, что очень актуально при текущем развитии и распространённости машинного обучения (ML). Но не все хорошо сейчас в этом направлении (там каждый кто во что горазд) ...

И вот, рабочая группа Container Orchestrated Device (COD) сейчас работает над Container Device Interface (CDI), которая является спецификацией для container runtimes, для поддержки разных сторонних устройств через общепринятую, понятную всем систему плагинов. По сути, это продолжение линейки: CRI, CNI, CSI, SMI, CPI.

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

Легкий пятничный пост.

Те, кто занимаются пентестами и имеют дело с Linux и Windows окружениями определённо должны знать о таких проектах как:
- GTFOBin для Linux
- LOLBAS для Windows (есть даже drivers)

Это набор/список/перечень легитимных исполняемых файлов, библиотек, скриптов, которые можно использовать для атакующих целей: что-то скачать и выгрузить, выключить, обойти, спрятать, поднять привилегии и т.д. При этом как вы понимаете сигнатуру/правило на это написать, конечно, можно, но нужно будет часто фильтровать от нормального использования ;)

Так вот пользователь twitter подметил, что всеми нами любимый kubectl с флагом --raw отлично подходит для замены тех же curl и/или wget, если их нет под рукой, и отлично подходит для пополнения данных проектов!

Месяц назад гремела новость про "Kubernetes Hardening Guidance" от NSA (и я об этом писал), затем все писали про инструмент Kubescape для проверки по данному гайду (я об то не писал).

И пока совсем без внимания остается статья "NSA & CISA Kubernetes Security Guidance – A Critical Review" от известной security компании. Статья состоит из 3-х частей: что хорошего, что плохого и что забыто в данном гайде.

На том что там хорошего - останавливаться не будем, лишь процитирую авторов по этому поводу: "Each of these points relate back to the generic guidance for almost any platform, regardless of the technology in use"

Про плохое (страдает точность, актуальность и полнота):
- PSP Deprecation - про данный факт ни слова.
- Admission Controllers - практически не упоминаются, хотя это мощнейший инструмент k8s.
- Inconsistencies/Incorrect Information - опечатки/неточности про порты.
- Authentication Issues - ошибка что в k8s нет аутентификации по умолчанию.

Последнюю часть характеризует цитата: "With a project as complicated as Kubernetes, it is not possible to cover every option and every edge case in a single document, so trying to write a piece of one size fits all guidance won’t be possible. "). То есть там авторы говорят о том, что вообще не было рассмотрено в документе:
- Levels of Audit Data
- Sidecar Resource Requirements
- External Dependencies are essential
- RBAC is hard
- Patching Everything is hard

Много шума наделал статья "Finding Azurescape – Cross-Account Container Takeover in Azure Container Instances"

Кратко:
- Используя данную проблему вредоносный пользователь может выйти из своего окружений и попасть в соседние окружения других клиентов облака
- Дело касается Azure Container Instances (ACI) это CaaS/serverless от Microsoft
- У Microsoft реализация ACI есть на Kubernetes и Service Fabric Clusters, проблему удалось проверить только в первом случае
- В реализации на Kubernetes для размещения клиентов использовался node-based multi-tenancy подход
- Azure Kubernetes Service (AKS) мог пострадать только в том случае, если он интегрирован с ACI
- Атака: 1) Побег из контейнера через 1-day уязвимость CVE-2019-5736 в runC 2) получение доступа к privileged Kubernetes service account token 3) выполнение команд на Kubernetes api-server
- На первом шаге использовали контейнер WhoC, который позволяет прочитать и отправить исполняющий его container runtime
- На втором шаге исследователи поняли, что им доступен service account token, который имеет права на pods/exec в любом namespace, включая kube-system
- На третьем шаге исследовали просто получили shell в контейнере Kubernetes api-server - Game Over!
- Также исследователи нашли возможность получить shell в контейнере Kubernetes api-server через SSRF ;)

После прочтения я большое всего в шоке от того что в этой части облака (непонятно как в других) использовался runC 2016 года и Kubernetes от ноября 2017 - октября 2018 ...

На YouTube стали доступны видеозаписи с Cloud Village 2021 с конференции DEFCON 29. Про Kubernetes там есть:
- Kubernetes Goat - Kubernetes Security Learning
- Kubernetes Security 101: Best Practices to Secure your Cluster

Ну и, конечно, много всего про AWS, GCP и Azure =)

Также обратите свое внимание на доклады с Blue Team Village 2021 с той же конференции. Там также есть про облака и про их защиту. Мой взгляд там зацепился за доклады:
- A SERVERLESS SIEM: DETECTING ALL BADDIES ON A BUDGET
- I know who has access to my cloud, do you?

CVE-2021-25741: Symlink Exchange Can Allow Host Filesystem Access

Уровень: High (CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)

Пользователь может создать контейнер с subpath volume смонтированным с доступом к файлам и директориям за пределами volume, в том числе к хостовой (Node) файловой системе. По сути, это приводит к container escape.

Эксплуатация позволяет hostPath-like доступ, без доступа/использования к hostPath фичи, тем самым обойти данное ограничение если оно используется в вашем окружении.

Уязвимость находиться в kubelet и не зависит от container runtime.

Нужно обновится до соответствующих версий, а если это у вас невозможно, то можно отключить VolumeSubpath feature gate на kubelet и kube-apiserver, и удалить все существующие Pods созданные с использованием данной фичи. А также admission control (policy engine) для предотвращения создания таких Pods, а также их backgroud scan для обнаружения.

Уязвимые версии:
- v1.22.0 - v1.22.1
- v1.21.0 - v1.21.4
- v1.20.0 - v1.20.10
- <= v1.19.14

Более подробных деталей по эксплуатации данной CVE пока отсутствуют. Но судя по описанию, атакующий должен контролировать содержимое образа и соответствующим образом через symlink добиваться доступа за пределы volume.

Backups in Kubernetes.

Наверняка вы знаете или по крайне мере слышали о таких бесплатных решениях как Velero и K8up (Kubernetes Backup Operator) нацеленных на Kubernetes cluster resources и persistent volumes.

Если такие темы как:
- Disaster recovery
- Backup and restore
- Local high availability

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

Интересно узнать, а как вы смотрите на тему backups в Kubernetes?

Threat Hunting with Kubernetes Audit Logs

Серия из двух частей "Analyzing Kubernetes audit logs to look for potential threats" и "Using the MITRE ATT&CK® Framework to hunt for attackers".

В первой статье идет база:
- What is threat hunting?
- What are Kubernetes audit logs?
- Why are audit logs important?
- What does an audit log look like?
- Let’s Hunt! (на что и как стоит обращать внимание - по сути как правильно интерпретировать лог)

Во второй статье рассматривают как на каждой стадии MITRE ATT&CK® Framework можно строить гипотезы и проверять их - в принципе полезная вещь.

Странно что в статье совсем не упомянут трюк с детектом обращения к ресурсам/API SelfSubjectAccessReview и SelfSubjectRulesReview, что является результатом работы команды kubectl auth can-i. Атакующий же не знает, что может захваченный им token ;)

Очень часто в статьях про K8s каждый механизм ИБ рассматривается в отрыве от остальных (а их в K8s очень много) и может сложиться не верная картина по работе с безопасностью в k8s (а она отличается от классических систем сильно). Я люблю рассматривать это все комплексно, а с учетом того, что Kubernetes Audit Logs вообще мало кто активирует, из-за увеличения нагрузки на API server, это еще более актуально.

Чтобы с минимизировать нагрузку я рекомендую использовать:
- GitOps operator
- PolicyEngine
- Минималистичную AuditPolicy

P.S. Кто-нибудь проводил замеры на сколько увеличивается нагрузка на API Server при работе Audit Logs или видел соответствующие работы на эту тему?

На недавно прошедшей конференции fwd:cloudsec 2021 было 2 доклада, напрямую затрагивающих безопасность Kubernetes:
1) Kubernetes Security: PSP deprecation is an opportunity for a new security model
2) Least-Privilege Kubernetes Authorization with OPA

Первый доклад совсем базовый и как по мне ничем не примечательный, а вот второй очень интересный и представляют собой рассказ о том как ребята в своей компании с помощью policy engine и собственных кастомных ресурсов (YAML) закручивали гайки и реализовывали принцип наименьших привилегий при авторизации. При этом они выходят за рамки стандартной RBAC и могут базироваться на произвольных метаданных (на пример, labels). Таким образом они могут давать доступ, основываясь, например, на отделах/командах сотрудников, типах/классах сервисов и т.д.

Что вам приходит в голову когда речь заходит о image integrity ?

- Supply chain attacks
- Docker Content Trust (DCT)
- Notary
- Sigstore c Cosign
- Anchore Engine с ImagePolicyWebhook
- Portieris admission controller
- Connaisseur admission controller

Есть пути как посложнее, так и попроще. Но если вы хотите все прочувствовать на кончиках пальцев, то для вас определенно проект "Sigstore the Hard Way" (аналог "Kubernetes The Hard Way"). Тут вручную придётся ставить и настраивать Fulcio, Rekor, Certificate Transparency Log, Dex, Cosign ;)

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

Продолжая вчерашнюю тему про image integrity или image signing, хотелось бы остановиться на одном очень интересном и тонком моменте.

В kubernetes manifest ссылаться на образ можно через digest или tag. В случае, если используется tag, многие решения из данной области транслируют tag в digest, проводят проверку, и затем (в случае успеха) патчат исходный manifest, меняя tag на digest. Можно задаться вопросом к чему такие сложности?!

Все очень, просто tag можно просто менять и навешивать его на разные образы, а с digest так не получится. И если всего этого не делать, то присутствует проблема TOCTOU (Time-of-check to time-of-use). Атакующий может подать сначала образ с правильной подписью, а затем перевесить tag на вредоносный образ, а в случае использования digest такое провернуть не получится...

Но тут появляется другая проблема. Если вы используете GitOps подход/оператор, то система может входить в бесконечный цикл, когда GitOps оператор будет видеть расхождения того, что лежит в Git (тут по tag), и то, что запущено в кластере (тут по digest). В некоторых, решения есть опция не мутировать manifest, то тогда сами понимаете остается проблема TOCTOU.

Вот и наступила пятница и можно задуматься о том, как можно провести выходные!

Одним из вариантов может быть изучение материалов, которые уже доступны, с проходящей сейчас Linux Plumbers Conference 2021.

Мое внимание привлекли доклады с:
- Сессии "Containers and Checkpoint/Restore MC"
- Трека "BPF & Networking Summit"

Докладов про (мой любимый) eBPF и на этой конференции очень много и если вы пересмотрели все с eBPF Summit 2021, то вот очередная порция ;)

А в конце сентября уже состоится Linux Security Summit! Я лично неразрывно смотрю на развитие Linux и Kubernetes, так как при развитии одного активно развивается (с некоторым опозданием) и второй. И при этом на мой взгляд с той же точки зрения безопасности необходимо сначала по максимуму использовать встроенные средства безопасности, что уже предлагает как Linux, так и Kubernetes, а только потом навесные, где не удалось использовать встроенные.

Тут увидел CNCF End User Technology Radar для DevSecOps.

Он у меня вызывает больше вопросов, чем дает ответов. Вообще не понятно по какому принципу они сюда подбирали решения ...

Использование ServiceMesh (Istio, Linkerd) или CNI плагинa (без которого вообще k8s работать не будет), автоматом не означает что у вас есть DevSecOps. Я часто вижу картину, когда они есть в компании и активно используются, но безопасностью на основе них никто не занимается. И причем тут DevSecOps?! Очередной маркетинг или посредственное вовлечение опрошенных?!

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

В прицепе, с такими же мыслями подошел и автор проекта k8s-lab-plz. Это модульная Kubernetes лаба, которая создает тестовый кластер на minikube или baremetal. Из текущих компонентов там есть:
- Vault
- ELK (Elasticsearch, Kibana, Filebeats)
- Observability (Prometheus, Grafana, Alertmanager)
- Kafka (Kafka, Zookeeper, KafkaExporter, Entity Operator)
- Baremetal Setup (Load Balancing, Volumes, etc.)
- Cartography
- Yopass

И еще планируется поддержка:
- Istio
- Gatekeeper
- Falco
- Starboard
- Audit logging
- Private Registry

Будет полезно и для Red и Blue team.

P.S. О подобной системе у нас я писал ранее тут.

C большим интересом смотрю сейчас за проектом/фреймворком SLSA и то как к его реализует у себя Google (не забываем еще о Google Binary Authorization). У них в блоге на эту тему стоит почитать:

- "Introducing SLSA, an End-to-End Framework for Supply Chain Integrity" - введение в тему и PoC для первого уровня.
- "Distroless Builds Are Now SLSA 2" - как добились второго уровня, используя проекты Tekton Pipelines и Tekton Chains, для автоматической генерации и подписи так называемого provenance

SLSA (”salsa”) расшифровывается как Supply-chain Levels for Software Artifacts. Общий смысл это: "Improving artifact integrity across the supply chain."

Для 99% компаний это пока не достижимый уровень и тут не надо гнаться за Google. Но получать и так проверять те же компоненты самого Kubernetes было бы полезно всем =)

А вы знали о такой возможности kubectl ?)

“Complexity is the worst enemy of security, and our systems are getting more complex all the time.”, Bruce Schneier

Развитие неизбежно и нужно уметь к нему адаптироваться. А так, к этой всемирно известной фразе я бы еще добавил, что это верно не только для security, но и для reliability.

Всем хорошей пятницы =)

На последнем тренинге мы с классом достаточно долго обсуждали firewalling на L7 на базе Istio: возможности, ограничения, недостатки, ресурсы и т.д. И, как всегда, при обсуждении service mesh все упирается в излишнюю прожорливость ресурсов, особенно когда дело касается использования AuthorizationPolicy.

Так вот в конце прошлой неделе вышла новая версия конкурента - Linkerd 2.11 в котором добавили возможность реализации Authorization policy! Как известно Linkerd почти во всем легче и быстрее Istio и вот теперь бы хотелось бы увидеть сравнение работы двух этих service mesh решений при использовании Authorization policy.

Но стоит отметить, что по возможностям Istio выигрывает - там в политиках можно не только указать с какими сервисами и как можно общаться, но и к каким именно API по HTTP можно обращаться, такого в Linkerd еще не завезли.

Наткнулся недавно на достаточно неплохую подборку Container CVE List в:
- Kubernetes
- runc
- ContainerD
- Docker

Начинание хорошее, главное, чтобы поддерживалось актуальное состояние. Так о самих у уязвимостях я пишу и на данном канала [1,2,3,...], а еще как я писал ранее - можно следить за этим всем с помощью специальных поисковых запросах в репозитории проекта Kubernetes.