В этом году на Open Source Summit North America 2024 в рамках ContainerCon был замечательный доклад "Reinventing Container Linux for the Wasm Era (and More) with System Extensions" (WASM в названии больше для хайпа, в самой презе всего ничего слайдов о нем).

Данный доклад продолжает и расширяет одну из наших любимых тем - container-specific OS! А расширяет он эту тему тем что авторы предлагают следующий шаг за данной категорией - Composable Linux.

По сути вся идея крутится вокруг механизма systemd-sysext (еще тут хорошо описано), а демонстрируется на примере дистрибутива Flatcar, в котором это уже все сделали. Примеры для него можно посмотреть тут и там есть: kubernetes, docker, nvidia-runtime, wasmtime, ollama и т.д.

P.S. Про Flatcar был замечательный доклад на нашей прошлогодней конференции БеКон.

P.S.S. В OS Talos это присутствует под названием Talos Linux System Extensions.

Большая и наглядная статья "Shielding Your Kubernetes Network: Mastering iptables for Enhanced Security" рассматривает использование iptables для повышения сетевой безопасности в Kubernetes кластерах.

Автор статьи объясняет, как с помощью iptables можно управлять сетевым трафиком, защищая его от потенциальных угроз. В статье представлены базовые концепции и команды для настройки iptables, а также практические примеры, которые помогают лучше понять, как интегрировать правила iptables в Kubernetes для защиты кластера.

В том числе автор показывает как читать и понимать цепочки правил iptables – то, что нужно для начинающих.

Capslock - новая OpenSource разработка от компании Google, позволяющая проводить capability analysis (анализ возможностей) для Go пакетов (прямых и транзитивных зависимостей). Результатом его работы является перечень привилегированных операций, которые может делать данное ПО. На сегодняшний день их 15 штук, такие как:
- CAPABILITY_EXEC
- CAPABILITY_ARBITRARY_EXECUTION
- CAPABILITY_SYSTEM_CALLS
- CAPABILITY_FILES
- CAPABILITY_NETWORK
- ...

Как не трудно догадаться это очень полезно в тематике supply chain безопасности. И это сильно смахивает на идею с Android permissions ;) Как по нам за такими штуками будущее - когда четко понимаешь что запускаешь.

Также уже встроили в портал deps.dev (общаться по API), можно делать дифы (capslock-git-diff) между версиями пакетов и кастомизировать собственные категории!!!

Подробнее об инструменте можно узнать из презентации "Capslock: Escaping Bad Dependencies" c Open Source Summit Europe 2024.

Заканчиваем эту неделю новостью, связанную с обновлением документации Kubernetes по части security. А именно новому разделу – Seccomp and Kubernetes.

В этой небольшой статье рассказывается об основах API Seccomp профилей в Kubernetes, и то как они сопоставляются с syscalls.

21 октября на конференции Industrial++ 2024 наша команда Luntry совместно с Моной Архиповой представят доклад «Безопасность от виртуальных машин до контейнеров и обратно».

Департаменты IТ и ИБ уже приняли, адаптировали виртуализацию и виртуальные машины в свой технологический стек и процессы. Но время неумолимо бежит вперед и приводит индустрию к контейнеризации, контейнерам, оркестраторам (Kubernetes).

Мы проведем между ними параллели, чтобы понять, где они сходятся, а где расходятся. Это позволит понять разницу, преимущества и недостатки, на основании которых можно эффективно играть и использовать их как порознь, так и совместно во благо безопасности.

Два классных репозитария для глубокого понимания и изучения принципов работы двух важнейших компонентов любого Kubernetes кластера - CNI (Container Network Interface) и CRI (Container Runtime Interface):
1) Demystifying CNI
2) Demystifying CRI

Автор заверяет, что потом вы сможете написать их с нуля) Данный тезис мы не проверяли, но все объясняется очень низкоуровнево!

Ещё двумя уязвимостями пополнился Kubernetes CVE Feed, а именно CVE-2024-9486 и CVE-2024-9594: VM images built with Kubernetes Image Builder use default credentials.

В результате эксплуатации уязвимостей неавторизованный пользователь может получить доступ по ssh к Node, использующий образ VM, созданный с помощью Kubernetes Image Builder.

Найденным уязвимостям были присвоены оценки 9.8 и 6.3 по CVSS.

В качестве мер митигации предлагается пересобрать образы, используя новую версию Image Builder. До обновления эту уязвимость можно митигировать, отключив учетную запись builder на затронутых VM:

usermod -L builder

Недавно наша команда, в лице Сергея Канибора, приняла участие в подкасте [SafeCode Live] – "Как взломать Kubernetes?".

На подкасте с нашими хорошими товарищами – Алексеем Федулаевым (MTS Web Services) и Вадимом Шелестом (Wildberries) мы обсудили:

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

Ну и конечно же поделились интересными историями с пентест-проектов =)

Выпуск доступен на YouTube.

Слушайте подкаст на других платформах:
- Apple Podcasts 
- Яндекс Музыка
- ВКонтакте

Посмотрели недавно доклад с хайповым названием "Coping with Zero-Days with Cilium Tetragon". По факту один маркетинг, но давайте разбираться со всем по порядку.

1) Из описания доклада "When a new CVE and its patches are announced, it's called a "zero day"" <- НЕТ! Это называется 1day, так патч уже есть. 0day как раз когда патча нет.
2) Чтобы ответить на вопрос "Is the affected version built into any of our images?", которым задается автор, не нужен сбор информации в runtime через eBPF. Достаточно SBOM и информация его распределениям по образам, далее узнать, где запушен с ним Pod находится в поле Status.
3) Допустим, что хотим узнавать в runtime. Для этого авторы подписываются на функцию security_mmap_file и при ее вызове сравнивают ее аргумент с версиями уязвимых библиотек "liblzma.so.5.6.0" и "liblzma.so.5.6.1". И получаем сразу 3 странных момента: это дополнительный оверхед при старте всех приложений, если приложение уже загрузило эту библиотеку, то ничего обнаружено не будет, и чтобы поймать 0day нужно заранее знать имена библиотек, что, конечно, невозможно для реальных сценариев ловли 0day.
4) "block policy" <- на скриншоте видно, что библиотека уже загрузилась и уже после отправляется процессу SIGKILL. В итоге, это не блокировка, а реакция и непонятно, что успел сделать тот код.
5) "Low Overhead" <- все красиво, когда политика одна. Ситуация разительно ухудшается при сложных политиках и при их большом количестве. Банально нужно больше проверок проделать и все это делается прямо на клиенте. То есть потребление сенсора будет расти пропорционально количеству политик/проверок. Ничего не бывает бесплатно.

Если вы по какой-то причине до сих пор используете обычные базовые образы (вроде debian или ubuntu) и не переходите на distroless, то статья "The vulnerability puzzle: understanding base images and their relationship to CVEs" как раз для вас.

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

Авторы предлагают меры для минимизации риска, включая использование сканеров уязвимостей и оценку их актуальности.

Уже давно я задавался вопросом, но все никак не доходили руки разобраться, зачем и для чего вообще нужен встроенный Admission Controller под названием ImagePolicyWebhook. В принципе, из названия можно понять для чего он нужен, но вот какой в нем есть смысл и преимущество по сравнению с ValidatingAdmissionWebhook было непонятно. Поиски привели к прекрасной статье "Kubernetes Image Policy Webhook Explained" (репозиторий со всем кодом тут) в которой они оба и сравниваются.

По итогу в эру PolicyEngine движков этот механизм явно должен кануть в Лету, так как на сегодняшний день никаких преимуществ он не дает.

P.S. Всем хороших выходных!

Understanding DNS resolution on Linux and Kubernetes – неплохая статья от Jérôme Petazzoni, повествующая о возможных сложностях резолва DNS имён в Kubernetes и Linux в целом.

Продолжаем тему обучающих материалов о сети в Kubernetes и сегодня у нас замечательный лонгрид "Kubernetes networking: service, kube-proxy, load balancing".

Большой ресерч от DataDog State of Cloud Security получил апдейт. Там есть два интересных момента, которые особо не подсвечивают облачные провайдеры:

1) Managed Kubernetes, запущенные по умолчанию увеличивают риск атаки
2) Опасные (привилегированные) IAM роли в Managed k8s увеличивают риск для pivot

Исследование проводилось на AWS, Azure и Google Cloud так что настоятельно рекомендуем с ним ознакомиться всем, кто имеет дело с этими облаками или просто интересуется облачной безопасностью.

Давненько у нас не было хардкорных постов про ядро и его эксплуатацию - исправляемся.

Встречайте статью "SELinux bypasses". Из данного материала вы узнаете:
- Что такое SELinux и как он реализован
- 6 способов его обхода

Да, в статье рассматривается все на пример ОС Android, но как вы знаете в Kubernetes мы тоже можем использовать SELinux и по сути он не чем не отличается.

В Cilium раскрыли очередную уязвимость – CVE-2024-47825: CIDR deny policies may not take effect when a more narrow CIDR allow is present.

Например, при использовании приведенных ниже политик трафик разрешен для 1.1.1.2, в то время как он должен быть запрещен:

apiVersion: cilium.io/v2
kind: CiliumClusterwideNetworkPolicy
metadata:
  name: block-scary-range
spec:
  endpointSelector: {}
  egressDeny:
  - toCIDRSet:
    - cidr: 1.0.0.0/8
---
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: evade-deny
spec:
  endpointSelector: {}
  egress:
  - toCIDR:
    - 1.1.1.2/32
  - toEntities:
    - all

Так что если у вас есть сетевые политики в кластере, это еще не значит, что они работают =) Ну и про лейблы забывать также не стоит.

Всем хороших выходных!

Начнем эту неделю с крутой статьи "Securing Continuous Delivery: Argo CD Threat Detection", которую написали наши постоянные читатели и любезно поделились ей с нами ;) От ребят ранее была и другая не менее интересная статья про Threat Detection в k8s, но вернемся к сегодняшней теме. В рамках данной стать рассматривается стратегия обнаружения угроз в ArgoCD. Если вы используете данный GitOps оператор, то он определённо играет ключевую роль у вас в кластере, так что стоит серьезно задуматься о его безопасности. И вот в статье приведено 12 полезных детектов для данной системы. Специалистам SOC обязательно к изучению! Так же из статьи можно узнать как вообще об устройстве ArgoCD, так и о его модели угроз, которая отдельна описана в замечательном документе "Argo CD End User Threat Model".

Scaling in the Clouds: Istio Ambient vs. Cilium – интересная статья-сравнение, опубликованная в блоге Istio инженером из Microsoft.

Istio был запущен в ambient mode с waypoint proxy в каждом namespace. Чтобы сделать сценарии похожими, в кластере с Cilium был включен WireGuard encryption, L7 proxies и Node Init, а также была применена L7 Cilium Network Policy в каждом namespace.

По итогам тестирования автор выяснил, что значительные проблемы в производительности у Cilium начинаются при работающих L7 политиках и включенном шифровании. Хотя Istio в то же время потреблял больше ресурсов.

С заметками автора можно ознакомиться тут.

30 октября на конференции SafeCode 2024 Autumn наша команда в лице Сергея Канибора представит доклад "Security observability в Kubernetes". Из доклада вы узнаете, как Luntry может помочь разработчикам, QA-специалистам, системным аналитикам, Ops/DevOps/DevSecOps, командам ИБ и SOC строить и поддерживать надежную и безопасную инфраструктуру.

Также на конференции наш коллега Анатолий Карпенко (Luntry) совместно с Алексеем Федулаевым (MTC Web Services) проведут воркшоп "Готовим контейнеры вкусно и полезно".

AWRBACS - это инструмент на Go предназначенный упростить аудит CRUD прав в Kubernetes RBAC. Подробнее об его истории и назначении можно узнать из статьи автора "AWRBACS: AWACS for RBAC".