В чате Kubernetes один из читателей задался вопросом – “Если выставить privileged: true в securityContext, то capabilities: drop: [ALL] теряет всякий смысл?”. Нам стал интересен результат и мы решили это проверить:

Сначала проверим capabilities у privileged контейнера:

root@ubuntu:/run# capsh --print
Current: =ep
Bounding set =cap_chown,cap_dac_override,cap_dac_read_search, …(всего около 40, для удобства восприятия список сокращен)

Потом при выставленном capabilities: drop: [ALL]:

root@ubuntu:/run# capsh --print
Current:
Bounding set =

И в последний раз privileged + capabilities: drop: [ALL]:

root@ubuntu:/run# capsh --print
Current: =ep
Bounding set =cap_chown,cap_dac_override,cap_dac_read_search, …

Никакой разницы между первым и третьим пунктом нет. Становится ясно, что privileged имеет более высокий приоритет над capabilities.

В полку Infrastructure Bill of Materials (IBOM) и Software Bill of Materials (SBOM) пополнение в виде Kubernetes Bill of Materials (KBOM)! И об этом можно узнать из статьи "KSOC Releases the First Kubernetes Bill of Materials (KBOM) Standard", а так же начать пробовать с этим работать с помощью утилитки kbom.

Из статьи можно узнать зачем это вообще придумали, когда полезно и чем отличается от SBOM, IBOM. Основной довод звучит так: "For example, many SBOMs will only cover custom-built images. In terms of what is actually deployed in Kubernetes, looking only at bills of materials for custom images would completely miss third party images for the control plane or in the CRD,"

Напомню что SBOM для основных (control plane) образов k8s можно получать так.

Я пока не понял смысла этого KBOM (за исключением пиара) ....

Awesome Cloud Security Labs - набор различных лаб для самостоятельного изучения безопасности облачных сред и технологий:
- AWS
- Azure
- GCP
- Kubernetes
- Container
- Terraform

Для k8s есть 3 лабы!

Уже на этой неделе - 19 мая в 15:00 на конференции PHDays я (Дмитрий Евдокимов, Luntry) вместе со своим хорошим товарищем Виктором Бобыльковым из Райффайзенбанк представим доклад "SCAзка о SCAнерах".

Доклад будет посвящен процессу Software Composition Analysis. В выступлении будет предложен новый способ оценки уровня зрелости процесса SCA по методологии CMMI. Сейчас зачастую в сфере кибербезопасности у специалистов не хватает компетенции и времени сесть и оценить, в каком состоянии находится тот или иной процесс, куда стоит двигаться дальше и почему нужно приоритизировать именно эти, а не другие задачи.

В докладе будет много про процессы, море CVE и, конечно, образы контейнеров и контейнеры (куда же без них)!

Буду рад со всеми увидеться лично и ответить на любые вопросы про нашу конференцию БЕКОН.

Сегодня хочу поделиться с вами новым крутым ресурсом от Rory McCune – Cloud Native Security Talks.

По сути, сайт представляет из себя хаб, в котором собраны доклады с различных конференций, посвященные Cloud Native Security (само собой будет обновляться и дополняться). Всё самое свежее и полезное в одном месте.

Однозначно рекомендую!

В официальном блоге Kubernetes вышла заметка об очень важном и нужном нововведении "Kubernetes 1.27: In-place Resource Resize for Kubernetes Pods (alpha)".

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

Если кратко, то появилось следующее:
- InPlacePodVerticalScaling feature gate
- Поле resources у контейнеров стало изменяемым и можно его менять!
- Новое поле restartPolicy для cpu и memory с возможными значениями NotRequired и RestartContainer
- Новое поле resources в статусе контейнера для отображения фактической картины

И рекомендую почитать "Resize CPU and Memory Resources assigned to Containers"

Мы обещали 10 докладов в программе нашей конференции БЕКОН, но ... их будет 12!

Есть одна тема, которую мы очень хотели осветить - это Container specific OS и мы до последнего не сдавались искали контент про это.

- ОС Talos Linux - путь к "тому самому" харденингу инфраструктуры для k8s (Николай Панченко, Тинькофф)
- Контейнерная ОС Flatcar: как обмазаться докерами и забыть про пакеты (Александр Кондратьев, BI.ZONE)

Билеты можно купить тут.

Privilege escalation in AWS Elastic Kubernetes Service – очень интересная статья про повышение привилегий и закрепление в EKS кластере.

Для начала автор затрагивает интересный момент: с скомпроментированного пода, можно достучаться до AWS metadata для получения информации об IAM. По сути, это означает, что независимо от того какие привилегии имеет под, он имеет те же возможности в AWS, что и EC2.

Сам вектор построен на использовании system:node token, но просто так использовать его не получится – он ограничен механизмом NodeRestriction. Автор в деталях показывает как можно повысить свои права в кластере, получив cluster-admin. После этого также затрагивается техника для закрепления, через указание IAM роли и без создания дополнительных Kubernetes Resources.

В качестве remedations предлагается использовать функцию AWS IMDSv2, перенос ненадежных микросервисов на изолированную Node (концепция DMZ) и отключение доступа из вне к Kubernetes API.

Серия из 26 роликов для подготовки к Certified Kubernetes Security Specialist (CKS)! Сам гайд для подготовки от того же автора тут.

P.S. Ближайшие 2 дня я в Москве на PHDays! Буду рад встретиться в IRL или AFK, кому что ближе и пообщаться)

Having fun with seccomp profiles on the edge – новая заметка в официальном блоге Kubernetes.

Заметка в первую очередь посвящена Security Profles Operator (о котором мы не раз рассказывали на канале – 1, 2, 3) а точнее новому функционалу, добавленному в версии v.0.8.0. Благодаря новому интерфейсу spoc, можно записывать и воспроизводить seccomp profiles.

Автор подробно на простом примере показывает работу новой фичи. Важно отметить, что использовать seccomp можно на любой Linux системе, а также встраиваться в CI/CD. Вообщем, если задумывались затащить к себе seccomp – обязательно к прочтению.

Заметка "Debugging Kubernetes Nodes With Kubectl" раскрывает, как оказалось, для многих мало известный момент с отладкой Nodes через kubectl, без необходимости иметь там SSH доступ.

Есть ряд моментов, что нужно помнить при использовании этого:
- kubectl debug автоматически создает Pod с именем Node
- Корень хостовой ФС монтируется в /host
- Этот Pod запущен с host IPC, Network, PID namespaces, но не как privileged. Так что есть ограничения.

Классная вещь, которая может уменьшить attack surface за счет уменьшения запуска сторонних сервисах на Nodes k8s.

Container security fundamentals part 4: Cgroups – четвертая статья из цикла статей [1,2,3] про безопасность контейнеров от Rory McCune.

Автор затрагивает такие важные темы как:

– почему cgroups необходимы в контейнерах
– принципы работы cgroups
– использование cgroups для ограничения ресурсов
– использование cgroups для предотвращения fork bomb (DoS атак)
– использование cgroups для доступа к Linux devices

Конкурс!

Приз: Билеты на нашу конференцию "БЕКОН"

Задача: С использованием новомодных генеративных AI класса text-to-image, сгенерировать картинки на тему безопасности контейнеров, Kubernetes и рядом стоящих тем. Можно использовать любую сетку что у вас есть: Midjourney, Dall-E, Stable Diffusion, Kandinsky, Шедеврум и т.д. Результаты прикреплять к комментариям к данному посту вместе с указанием самого promt, что использовался для генерации =)

Работы будем принимать и оценивать до 31 мая.

Самые оригинальные, интересные, впечатляющие работы будут отмечены!

P.S. О самой конфе написали статью на Хабре.

Видео выступления "Kubernetes Security Detection Engineering" c конференции HITB 2023 Amsterdam от автора учебного/тренировочного проекта Kubernetes Goat. По большому счету, на основании заготовленных там сценариев автор и показывает как это можно обнаруживать. Все достаточно простенько, но для общего понимания пойдет.

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, но решили завезти еще одну.