Что вам приходит в голову когда речь заходит о 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.

Выбор правильной технологии, инструмента, решения является важной частью создания надежной системы. И если вы смотрите в сторону Service Mesh решений, то стоит начать с материала "Service Mesh Ultimate Guide - Second Edition: Next Generation Microservices Development". Первая часть выходила в феврале 2020.

Конечно, же вопрос security там также рассматривается ;)

Классный репозиторий для тех, кто хочет понять:
- Как определить, что попал в Pod обернутый Istio
- Как обойти/отключить sidecar от Istio
- Какие есть способы усложнить сделать это атакующему
- Какие best practices по Istio security есть

P.S. Самый забавный способ отключить sidecar как по мне это curl --request POST localhost:15000/quitquitquit

Inventory или asset management это база, фундамент, основа основ! Без понимания того, что и как у вас функционирует в инфраструктуре, окружении, Kubernetes кластере - любое закручивание гаек (security hardening) будет просто каплей в море. Атакующий всегда идет по пути наименьшего сопротивления и часто находит то, что вы забыли или банально не знали. Все думаю слышали: “Атакующему достаточно обнаружить один вектор, чтобы проникнуть в периметр. А защищающейся стороне надо найти все векторы, чтобы минимизировать риски.” Заниматься минимизацией рисков без полной картины невозможно.

С учетом микросервисной специфики и вообще текущих реалий нужно continuously inventory для continuously security.

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

kdigger - новый инструмент, позволяющий понять, что код выполняется в контейнере в Kubernetes и с какими возможностями. Сами авторы его описывают как: Context Discovery Tool for Kubernetes. По сути, является идейным наследником amicontained.

Для того чтобы понять окружение инструмент умеет проверять:
- admission
- authorization
- capabilities
- devices
- environment
- mount
- pidnamespace
- processes
- runtime
- services
- syscalls
- token
- userid
- usernamespace
- version

kdigger, конечно, будет полезен на ранних стадиях как на pentest, так и на CTF, но автоматизировано взломать k8s он не поможет (для этого смотрите инструмент CDK). При этом учтите, что ряд команд имеют side effects, поэтому используйте с умом!

Для того чтобы поиграться с инструментом и попробовать все его возможности авторы создали даже отдельный Minik8s CTF с 3 задачками (+ есть прохождения)!

Небольшой анонс.

После завтра, а именно 13 октября в 19:00 (Мск) будет вебинар «Дыры и заборы: безопасность в Kubernetes», который является по сути предваряющим курс "Безопасность в Kubernetes" на площадке СЛЁРМ.

Я решил также внести свою небольшую, посильную лепту в этот образовательный проект для широкой аудитории. Не только же корпоративные тренинги читать =)

Kubernetes Cluster API достиг версии 1.0 и перешел в v1beta1, это означает, что теперь он официально production-ready! Для этого данному API понадобилось 3 года. Все это время над ним работали и внутри себя использовали ведущие IT компании - их use cases можно почитать в статье в блоге CNCF. При этом работа в Cluster API продолжает кипеть и идет работа над ClusterClass и Managed Topologies.

Данного API мы касались, обсуждая тему Multi-Tenancy. Оно, по сути, позволяет декларативно управлять Kubernetes, используя API для создания, конфигурирования и обновления кластеров.

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

P.S. Пример установки CNI Calico и Cilium с помощью ресурса ClusterResourceSet

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

Мне, на пример, понравился очень хорошо описанный с PoC тикет "Man in the middle leading to root privilege escalation using hostNetwork=true (CAP_NET_RAW considered harmful)", который ничего не получил ... Бага была классифицировано как provider-specific, сам автор показал успешность атаки в GKE и EKS. Автор данной багой хотел показать и убедить разработчиков Kubernetes убрать CAP_NET_RAW капабилити из дефолтных - очень благая цель! Он даже предложил workaround для использования ping через sysctl net.ipv4.ping_group_range, но это осталось без внимания …

P.S. В CRI-O с версии 1.18 так и сделали, возможно когда-нибудь так сделают и в docker с containerd ...

Давненько не было облачных новостей - исправляем это упущение.

От команды Yandex.Cloud вышел официальный чеклист по безопасности (есть и не официальный)!

Мое внимание в первую очередь, конечно же, захватил раздел "Безопасность Managed Service for Kubernetes", где присутствуют такие пункты как:

- Шифрование данных и управление ключами/секретами
- Сетевая безопасность
- Аутентификация и управление доступом
- Безопасная конфигурация
- Сбор, мониторинг и анализ логов аудита
- Резервное копирование

Большинство инструкций можно на прямую посмотреть в соответствующем репозитории. Мне, например, очень понравилась инструкция "Анализ логов безопасности k8s в ELK" - там можно подсмотреть вещи и для разворачивания такого и у себя локально ;)

Также пообщавшись с ребятами из команды безопасности узнал, что не за горами появление аналога IMDSv2 для борьбы с SSRF атаками и механизма подобного Workload Identity из GKE или IRSA из EKS. Это все очень здорово!

В официальном блоге Kubernetes вышла статья "A Closer Look at NSA/CISA Kubernetes Hardening Guidance", которая является еще одним анализом, критикой, дополнением к нашумевшему документу Kubernetes Hardening Guidance от NSA/CISA.

В данном блоге прошлись по таким темам, как:
- Kubernetes Pod security
-- "Non-root" containers and "rootless" container engines
-- Immutable container filesystems
-- Building secure container images
-- Pod Security Policies
-- Hardening container engines
- Network Separation and Hardening
-- Network Policies
-- Resource Policies
-- Control Plane Hardening
-- Etcd
-- Kubeconfig Files
-- Secrets
- Log Auditing
-- Kubernetes API auditing
-- Streaming logs and auditing
-- Alert identification
- Upgrading and Application Security practices

Все очень грамотно и четко изложено и заключение очень правильное:"Finally, it is worth reiterating that not all controls in this guidance will make sense for all practitioners. The best way to know which controls matter is to rely on the threat model of your own Kubernetes environment."

Материал из разряда MUST READ!

Статья "A Practical Guide to the Different Compliance Kubernetes Security Frameworks and How They Fit Together"

Это сравнение популярных Kubernetes security и compliance фреймворков: чем они отличаются друг от друга, когда и что использовать, их основные цели и задачи, а также существующие вспомогательные инструменты для них.

В сравнении участвуют:
- CIS Kubernetes Benchmark - самый известный и у всех на слуху
- MITRE ATT&CK® Framework for Kubernetes - на самом деле тот что от Microsoft и уже обозреваемый мной
- PCI DSS Compliance for Kubernetes - притянут тут за уши, для привлечения внимания, так как в нем нет ничего Kubernetes специфик
- NIST Application Container Security Framework - это тот что NIST SP 800-190.
- NSA/CISA Kubernetes Hardening Guide - многострадательный документ, по которому уже прошлись раза два точно [1,2]