В заметке "Learn about Kubernetes security best practices for your cloud native application development" из блога CNCF мое внимание привлекло не само содержимое текста, а то какие там материалы были использованы (да бывает и такое).

1) Правильная мысль и цитата: "By integrating security as early as possible throughout the development lifecycle, or even earlier with interactive developer training, security organizations can enable preventative security rather than reactive security." из Cloud Native Security Whitepaper.

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

2) Ссылка на очень старый материал "9 Box of Controls" от ребят из BlackBerry. Заглавная картинка как раз от туда.

Этот материал можно просто весь разобрать на цитаты - на столько он хорош и актуален сегодня и особенно для Kubernetes (думаю что это заслужит даже отдельного поста).

version-checker это простенький инструмент для Kubernetes, который смотрит какие версии образов контейнеров запущены в кластере и на сколько они соответствуют последним версиям данного проекта. Тоесть позволяет очень просто контролировать актуальность используемых образов. Результаты проверки вывешиваются как Prometheus metrics, отображаются на dashboard и могут информировать об этом оператора.

При этом поддерживается порядочный набор registries:
- ACR
- Docker Hub
- ECR
- GCR (включая k8s.gcr.io)
- Quay
- Self Hosted (Docker V2 API совместимые реджистри типа artifactory и т.д.)

На конференции OFFZONE 2022 в этом году у меня было аж два доклада и второй из них (видео и слайды) это "Безопасность Kubernetes: Фаза Deception" (первый - это мой `keynote`-доклад).

Мы в нашей команде Luntry любим смотреть на безопасность Kubernetes со всех сторон и под абсолютно разными углами. И в рамках данного доклада я рассмотрел как, защищая свой Kubernetes, можно повысить шансы на обнаружение злоумышленника за счет его обмана (deception)! При этом всем будем использовать всю специфику окружения и его встроенные механизмы - тут k8s открывает прям безграничные возможности как по мне.

Данный доклад будет полезен Red и Blue team, работающих с Kubernetes.

P.S. В комментариях можно предлагать свои идеи - я уверен, что в данном направлении можно придумать еще много всего интересного ;)

Буквально недавно открыл для себя https://www.kubernetes.dev/ - где очень удобно можно следить за Kubernetes Enhancement Proposals (KEPs) (также искать/копаться в них) и на страничке Release смотреть какие фичи появятся в новой версии (Enhancements Tracking Sheet) и в какие даты выйдет (kubernetes/sig-release v1.26 milestone).

Так, на пример, я/мы/все теперь могу намного проще следить за "KEP-2091: Add support for AdminNetworkPolicy resources". О нем я уже как-то писал тут, но с тех времен ресурс ClusterNetworkPolicy переименовали в AdminNetworkPolicy.

Недавно наткнулся на политику "Verify Image Check CVE-2022-42889" в постоянно расширяемой библиотеке политик Kyverno (уже 232 политики).

Она позволяет проверить есть ли в образе последняя нашумевшая уязвимость в Apache Commons Text library или нет и решить разрешить ли выкатку микросервиса с таким образом или нет.

Все это делается на основании информации из SBOM, которая предварительно генерируется в CI, а далее в самой политике прописываем где она лежит, в каком форма, название какого компонента нас интересует и какой версии.

За деталями реализации помимо самого примера для данной уязвимости будет полезно почитать разделы:
- Verify Images - проверка образов
- JMESPath - JSON язык запросов

Также можно обратить внимание на следующие политики связанные с работой с уязвимостями:
- "Require Image Vulnerability Scans" - есть скан на уязвимости не старше 1 недели
- "Check Tekton TaskRun Vulnerability Scan" - скан на уязвимости не содержит уязвимости с рейтингом больше 8.0

Сегодня в 11:00 (по Мск) я (от лица Luntry) в приятной компании буду участвовать в онлайн-конференции AM Live «Российский DevSecOps в условиях импортозамещения». По мне это прекрасная возможность послушать как различные вендоры, интеграторы и дистрибьюторы смотрят на вопрос DevSecOps.

Вместе с командой сейчас работаем над добавлением в Luntry функциональности связанной с Compliance, а именно CIS Kubernetes Benchmark. Предварительно мы проанализировали множество OpenSource и коммерческих решений - первые на уровне кода и UI, вторые чисто на уровне UI. Остановимся на первых и обсудим к каким не утешительным выводам мы пришли. И так, обнаруженные проблемы:
- Отсутствие реализации проверок - идет как TODO или manual check
- Не полная реализация проверок - этот факт даже отмечается в комментариях (partial check)
- Отсутствие поддержки новых версий Kubernetes - для кого-то может быть новостью, но CIS Kubernetes Benchmark обновляется с новыми релизами Kubernetes.

В итоге, запуская/используя тот или иной инструмент с этими проблемами вы получаете не корректную картину по своей инфраструктуре.

P.S. Не ленитесь читать код OpenSource проектов!

"Restructuring the Kubernetes Threat Matrix and Evaluating Attack Detection by Falco" это записки интерна на практике, который разбирался с безопасностью Kubernetes и игрался с Falco.

Основные темы статьи:
- Расширение/дополнение Threat matrix for Kubernetes от Microsoft методами атак что там отсутствуют - очень полезный раздел и картинка этого дополнения вынесена в начало поста.
- Рассказ про правила обнаружения в Falco - что автор туда дописал. Учтите, что чем больше правил/сигнатур использует движок, тем медленнее он работает и больше оверхеда дает.
- Способы обхода Falco - опять привет symbolic links. Еще про его обходы я писал тут, тут и тут.
- Понимание эффективности и ограничений возможностей Falco

Инструмент KubeStalk позволяет обнаружить Kubernetes системы и связанные с ним компоненты путем сканирования списка IP адресов.

При этом для определения корректности детекта системы или доступа решение имеет набор сигнатур (plugins - JSON файлы) и там есть detector, который проверяет наличие определенной информации в ответе для проверки. На текущий момент в наличии:
- Kubernetes Version Disclosure
- Kubernetes Pod List Exposure
- Kubernetes Paths Exposure
- Kubernetes Web View Dashboard Exposure
- Kubernetes Resource Report Dashboard Exposure
- Kubernetes Operational View Dashboard Exposure
- Kubernetes Dashboard Exposure
- etcd Viewer Dashboard Exposure
- Unauthenticated etcd Exposure
- cAdvisor Metrics Web UI Dashboard Exposure

Все на python и легко расширяется ;)

На прошлой неделе прошел KubeCon + CloudNativeCon North America 2022 и уже доступны видео и слайды со специализированных сессий:
- Cloud Native SecurityCon NA 2022
- SigstoreCon NA 2022
- ServiceMeshCon NA 2022
- PrometheusDay NA 2022
- Kubernetes on Edge Day NA 2022
- Kubernetes AI Day NA 2022
- GitOpsCon NA 2022
- EnvoyCon NA 2022
- Cloud Native eBPF Day NA 2022
- Open Observability Day NA 2022
- Cloud Native Telco Day NA 2022
- Kubernetes Batch + HPC Day NA 2022
- KnativeCon NA 2022
- Cloud Native Wasm Day NA 2022
- BackstageCon NA 2022

Отдельно выделю появление новых сессий про Sigstore и Backstage, что говорит про тренды про подпись/аттестацию используемых артефактов и движение к специализированным порталам для разработчиков.

P.S. Видео с основной программы KubeCon + CloudNativeCon North America 2022 еще не доступно …

Если вы собираетесь сделать так чтобы ваш Kubernetes кластер соответствовал требования PCI DSS, то вы ,конечно, в курсе, что PCI Security Standards Council выпустил документ "Guidance for Containers and Container Orchestration Tools". Также вы возможно видели ряд обзоров и анализов данного документа с маппингом на Kubernetes на моем канале тут и тут. Но исследователь Rory McCune пошел дальше и начал детально рассматривать каждую из тем.

На сегодняшний день из 16 тем уже автор рассмотрел 5:
- Authentication
- Authorization
- Workload Security
- Network Security
- PKI

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

Организаторы конференции KazHackStan 2022 выложили в открытый доступ записи докладов с конференции и теперь можно посмотреть мой доклад "Специфика расследования инцидентов в контейнерах" (сами слайды тут).

Также отмечу очень крутой и для многих на этом канале полезный доклад своего хорошего товарища Эльдара "kyprizel" Заитова "Вызовы безопасной гибридной облачной инфраструктуры".

P.S. В комментариях можно задавать вопросы по докладам как мне, так и Эльдару ;)

Недавно наткнулся на вот такую забавную картинку. С первого или неопытного взгляда она может показаться просто юмористической. НО она под собой имеет и технический аспект связанный с Kubernetes.

Те кто смотрел мой доклад "Заметки путешественника между мирами: ИБ, ИТ" или был на моем тренинге знают о таком подходе к обеспечению безопасности как Moving target defense (MTD), который мне очень импонирует. А те кто внимательно читает мой канал могут вспомнить пост про Kubernetes operator под названием descheduler, который может помочь в реализации данного подхода.

Так что в каждой шутке есть доля шутки ;)

Команда Kubernetes информирует, что в релизе 1.26 он не только поднаберет в весе, но и значительно скинет за счет отказа от поддержки Container Runtime Interface (CRI) версии v1alpha2. (В первый раз я дочитал сообщение до сюда и ужаснулся). В итоге, останется поддержка только версии v1. Я уверен, что такой отказ от legacy пойдет только на пользу системе.

На скриншотах есть проблема!

Сегодня мы рассмотрим одну из популярнейших проблем при использовании политик от Policy Engine, что наша команда встречаем на своем опыте во время аудитов и пентестов Kubernetes кластеров.

Речь пойдет о политике, отвечающей за проверку разрешенных image registry. В OPA Gatekeeper обычно она базируется на ConstraintTemplate под названием K8sAllowedRepos, а в Kyverno на базе restrict-image-registries или advanced-restrict-image-registries (о них я писал тут).

Если вы не догадались, то проблема на скриншотах заключается в том, что в путях имен image registry отсутствует символ "/", без него данные политики достаточно просто обходить, подняв у себя домен желаемый_путь.evil.domen.com. Данные проверки обычно работают на базе инструкций startWith(), contains() и наш вредоносный домен будет удовлетворять данным требованиям ;)

Печально что эти примеры политик широко распространены в интернете и многие их бездумно копируют к себе. Будьте аккуратнее копируя из интернета =)

Все кто занимается или задумывается о supply-chain безопасности в Kubernetes (и на самом деле не только в нем) знают проект Sigstore.

Но мало кто знает, что у данного проекта есть собственный admission controller под названием policy-controller, который может применять политики к ресурсам на основании supply-chain metadata от утилиты cosign. Единственное учтите, что эта часть проекта Sigstore новая и пока находится в активной стадии разработки.

Данный контроллер позволяет проверять:
- Подписи образов
- Аттестацию связанных с образом ресурсов (SBOM и т.д.)

Для всего это требуется создать свою политику, которая из себя представляет Custom Resource типа ClusterImagePolicy.

В этой политики можно описать:
- К каким образам и в каких namespaces, pods и из каких image registry это применяется
- Что проверить, например, подпись образа, наличие SBOM или его содержимое (логика пишется на CUE)!
- Реакцию warn|allow|deny (по умолчанию deny)

На скрине политика, что не пропустит образы с уязвимостью Text4Shell