Using OCI artifacts to distribute security profiles for seccomp, SELinux and AppArmor – очередная статья в блоге Kubernetes, посвященная Security Proifles Operator.

На этот раз автор затрагивает очень интересный момент, а именно хранение профилей в OCI registries. В последней версии оператора была добавлена функция, позволяющая складывать профили в registries. Сейчас оператор поддерживает довольно большой список:

– CNCF Distribution
– Azure Container Registry
– Amazon Elastic Container Registry
– Google Artifact Registry
– GitHub Packages container registry
– Bundle Bar
– Docker Hub
– Zot Registry

На примере seccomp профиля автор показывает как легко, с помощью baseProfileName, можно сослаться на такой артефакт, а также как доставить его до registries.

Очень простое/базовое сравнение "Kubernetes Ingress Vs Gateway API". Для новичков, но как показывает практика далеко не все еще знают об этом.

P.S. Напоминаем про конкурс, который продлится до 31 числа!

Довольно простая для понимания и красочная заметка о том как Kubernetes распределяет Pods по Nodes.

Рассматривается как и в целом работа scheduler’а, так и принципы работы механизмов для распределения Pods:

- nodeSelector
- Node affinity
- Pod affinity/anti-affinity
- Taints and tolerations
- Topology constraints
- Scheduler profiles

Думаю что, понимание работы планировщика в Kubernetes помогает специалистам по безопасности оптимизировать и обеспечивать безопасность кластера, рабочих нагрузок и приложений, работающих в среде Kubernetes. Например, Pods могут часто переезжать с Nodes на Nodes, или если стоит задача делать разграничения сервисов по Nodes (например, DMZ) – эти моменты нужно держать под контролем.

Отдельно позабавил тот факт, что в коде Kubernetes есть 13 (!) функций, которые расчитывают score и оценивают Nodes для заселения их Pods.

Всем, привет!

1) Сегодня последняя возможность поучаствовать в конкурсе ;)
2) До нашей конференции "БЕКОН" осталось чуть больше недели - успейте взять билет. Количество мест ограничено! Продажа идет до 5 июня, не оплаченные брони исчезают. Приобретение билетов на площадке не предусмотрено.

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

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

При этом не редки случаи, когда настройки/политики/контроли безопасности внедряются на одном кластере, а потом "как есть" (или с небольшими изменениями) тиражируются на другие кластера без учета их специфики ...

По итогу, у нас на проекте получается, что один кластер очень сложно идет, а другие с теми же самыми настройки/политики/контроли безопасности становятся легкой добычей.

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

У Kyverno вышел новый релиз – 1.10. Основные изменения:

1) Повышенная High Availability, благодаря декомпозиции существующих сервисов (почитать подробнее про это можно здесь). Теперь их стало 4: Admission Controller, Reports Controller, Background Controller, Cleanup Controller.

2) Расширенные возможности External Data Sources. Раньше в качестве внешнего источника данных для политик можно было использовать OCI registires, ConfigMaps и API Kubernetes. В этом релизе, ко всему прочему, в качестве источника данных можно указать endpoint сервиса из кластера.

3) Поддержка Notary. В Kyverno уже была поддержка технологии для валидации подписи образов – Cosign Sigstore, но решили завезти еще одну.

Наконец руки дошли ознакомиться со статьей "Building a Kubernetes purple teaming lab". Тема кажется очень интересной и горячей, тем более что обещается и практическая часть с лабой.

Но изучив материал я был сильно разочарован ... В большей части это такая реклама инструмента от авторов статьи (хорошо что можно тут бесплатно с ним поиграться). Но ладно, подумал я. Может сами примеры/кейсы/ситуации будут сами по себе очень полезными и поучительными?! Но .... и тут разочарование. Авторы нам предлагают детектировать действия атакующего по тому что он вводил в команду kubectl там же где мы и поставили minikube и средство защиты - занавес. И по мне это жизнеспособно только в 1 случае, если вы используете minikube и рядом с ним и вводите эти команды как в статье.

В статье ни слова про:
- Kubernetes Audit Log (1,2)
- PAM (1,2)

И других средствах защиты, что было правильнее и эффективнее использовать. Очень плохо, что авторы сознательно или без сознательно эти аспекты не освещают в своей статье.

Схема от Rory McCune, отражающая то, как можно подойти к безопасности Kubernetes со всех сторон и на разных уровнях.

Нельзя не отметить, что тут не учитывается важный момент – Container Runtime Security. То, что происходит внутри контейнера несомненно должно контролироваться. Да и сама по себе схема достаточно верхнеуровневая, без какой-либо конкретики. Нет ничего про управление ресурсами (ResourceQuota, LimitRange), patch management самого Kubernetes, image security и hardening.

Также сам автор отмечает, что эта схема не учитывает Cloud Security и безопасность самих приложений, работающих в кластере – а это SAST/DAST/IAST/сбор SBOM/управление уязвимостями.

Подготовка к нашей конференции "БЕКОН" идет полным ходом, остались небольшие моменты и все. Я уже посмотрел и послушал все доклады - мне все понравилось) Уверен и вам это должно зайти.

На сайте уже можно посмотреть полное расписание со временем.

P.S. Вся наша команда в большом предвкушении =)

Cегодня в фокусе нашего внимания проект Kyverno Playground, который представляет из себя web-страничку на которой можно учиться, тестировать, разбираться с политиками для Policy Engine - Kyverno. подробнее о проекте можно узнать из статьи "Let's Play Kyverno".

Основной гигантский плюс всего этого - теперь не нужно разворачивать k8s, чтобы поработать с Kyverno! Достаточно в одном окне ввести политику, а в другом пример k8s ресурса, который по этой политике будет проверяться.

Могу сказать, что на одном из мероприятий в Екатеренбурге (анонсируем позже) наши специалисты (Luntry) при рассказе про Kyverno будут использовать данный проект для знакомства и обучения азам Kyverno.

Парочку важных моментов перед нашей завтрашней конференцией:
1) Гайд посетителя - тут собрана вся необходимая информация, для тех кто будет на площадке.
2) Данный телеграмм канал будет полностью освещать мероприятие и тут будет непривычно много сообщений. На пример, почти одновременно с началом доклада тут будут выкладываться слайды! В комментариях, можно будет задать автору вопросы и мы попросим всех авторов потом заглянуть в комментарии.

Увидимся завтра =)

Всем, доброе утро!
Мы начинаем БЕКОН!
И по счастливой случайности (это правда) так получилось, что сегодня празднует День Рождение Kubernetes!

В этот день 7 июня 9 лет назад был initial release Kubernetes ;)

Всем хорошего дня!!!

"Kubernetes, ответь мне, кто я для тебя", Константин Аксенов, Флант

"Не такой очевидный RBAC Kubernetes", Дмитрий Евдокимов, Luntry

"Как приручить Linux capabilities в Kubernetes", Николай Панченко, Тинькофф

"Контейнерная ОС Flatcar: как обмазаться докерами и забыть про пакеты", Александр Кондратьев, BI.ZONE

"NetworkPolicy для системных и инфраструктурных компонент", Александр Кожемякин, VK

"OPA с shared Docker executor", Павел Сорокин, OZON

"Distroless своими руками", Антон Мокин, Тинькофф