PCI Security Standards Council выпустил документ "Guidance for Containers and Container Orchestration Tools", делался он в рамках специальной SIG группы и по сути состоит из 3-х частей:
1) Общая информация о контейнерах и оркестраторах - совсем базовая информация. Kubernetes упоминается 4 раза на документ ;)
2) Списка угроз и best practices для противодействия им в контейнерных окружениях - основное мясо документа
3) Примеры для работы с угрозами и практиками - 4 use-cases

Рассматриваемые темы:
- Authentication
- Authorization
- Workload Security
- Network Security
- PKI
- Secrets Management
- Container Orchestration Tool Auditing
- Container Monitoring
- Container Runtime Security
- Patching
- Resource Management
- Container Image Building
- Registry
- Version Management
- Configuration Management
- Segmentation

Документ хороший - рекомендую к ознакомлению! Какой-то карточной специфики там особо нет, так что может быть полезен всем.

Завтра подсвечу наиболее любопытные моменты на мой взгляд.

Как и обещал сегодня поделюсь своим мнением о наиболее интересных моментах из документа "Guidance for Containers and Container Orchestration Tools" и, конечно, это будет из раздела 3.1 Threats and Best Practices, как самого интересного с технической точки зрения.

1) Я не понял смысл и пользы от разделения на “Applicable to Use Case”. В некоторых моментах я вообще не согласен. Например, пункт 11.1 Resource Management говорит, что работа с Limits есть только в Containerization in a Mixed Scope Environment, а в других случаях не важно. Поэтому я бы советовал смотреть на эти колонки с достаточной толикой скептицизма.
2) Важный пункт 4.1,4.2 Network Security прямо говорит о подходе запрещено все, что не разрешено и не двузначно намекает о использовании NetworkPolicy ;)
3) Удивило требование 4.3 Network Security про шифрование общения с API оркестатора, которое я нигде ранее не встречал. В угрозе написано про "packet sniffing or spoofing attacks", но подобного я лично никогда не наблюдал, хотя теоретически это возможно и скорее всего атакующий будет это делать в тех условиях, когда это можно сделать другим более легким способом.
4) В пункте 6.1 Secrets Management прямым текстом написано, что для работы с секретами нужно использовать стороннее решение за пределами кластера: "should be held in encrypted dedicated secrets management systems". Seald Secret и подобные проекты по push-модели совсем не в почете?!
5) Пункт 8 Container Monitoring - бальзам на мою душу, так как это было в точности то, что мы в первую очередь реализовали в Luntry.
6) Пункт 9 Container Runtime Security (почему-то он не часть пункта 8) несет в себе как по мне спорные моменты - мы увеличиваем изоляцию, но теряем в наблюдаемости. И, по сути, выигрыш только в усложнении побега из контейнера через уязвимости ядра и не более.
7) Понравился пункт 13.2 Registry в котором говорится про Registry Staging, о котором я писал недавно.
8) Пункт 15. Configuration Management полезная напоминала про важность pre-prod окружения для security.
9) Пункт 16. Segmentation это про multitenancy ;)

Еще один обзор на "PCI Guidance for Containers and Container Orchestration Tools" от известного западного коллеги. При этом он создал документ (xls, pdf) описав каждый из пунктов раздела 3.1 Threats and Best Practices со спецификой Kubernetes! Так что настоятельно рекомендую с ним ознакомиться.

В ближайшие дни мы с моим коллегой из Luntry представим аж две новые презентации про pentest и digital forensic в Kubernetes:
- 15 сентября. 14:40. KazHackStan 2022 (Казахстан, Алматы) - "Специфика расследования инцидентов в контейнерах", Дмитрий Евдокимов
- 15 сентября. 15:45. CyberCamp 2022 (online) - "Расследование инцидентов в средах контейнеризации", Сергей Канибор
- 18 сентября. 12:00. HackConf 2022 (Санкт-Петербург) - "Pentesting Kubernetes: From Zero to Hero", Сергей Канибор
- 20 сентября. 19:15. VolgaCTF 2022 (Самара) - "Pentesting Kubernetes: From Zero to Hero", Сергей Канибор

И бонусом еще участие в круглых столах и meetup:
- 22 сентября. 20:20. Innopolis meetup: DevOps (Иннополис) - "Кто и что такое CTO в ИТ startup’е?", Дмитрий Евдокимов
- 23 сентября. 11:00. Kazan Digital Week 2022 (Казань) - круглый стол "Облачные технологии в финтех", Дмитрий Евдокимов


Обратите внимание на обширную географию и на возможность посмотреть одно из выступлений в online! И мы как всегда будем рада новым знакомствам и общению - так что не стеснитесь подходить на конференциях ;)

Крохотная иллюстрированная заметка о том как по шагам работает Kaniko, о котором я уже пару раз писал [1,2].

Безопасная сборка образов в кластере Kubernetes это очень важно - это помогает следовать принципу наименьших привелегий!

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

И тут на помощь приходит Vulnerability Exploitability eXchange (VEX) и о нем идет речь в статье "How a Vulnerability Exploitability eXchange can help healthcare prioritize cybersecurity risk".

VEX это концепция и machine-readable формат, которая может использоваться со SBOM, так и без него. Его основная цель дать понятие к чему уязвим данный продукт и дать рекомендации по исправлению. При этом он учитывает, что наличие уязвимости не говорит о ее эксплотируемости в конкретном случае (non-exploitable vulnerabilities). И имеет статус:
- Not affected
- Affected
- Fixed
- Under Investigation

Данная информация призвана упростить определение приоритетов исправления уязвимостей. Пример VEX можно посмотреть тут.

В общем авторы статьи рисуют будущее в духе: SBOM+VEX+SLSA

P.S. Из статьи мне понравилась фраза: "Without the ability to see into what we must protect, it can be difficult to determine how to quickly reduce risk."

Мои слайды "Специфика расследования инцидентов в контейнерах" c KazHackStan 2022.

Буду рад ответить на любые вопросы в комментариях!

P.S. Обратите внимание, что некоторые спрашивают и ведут диалог в чате канала.

Хочу обратить отдельное внимание на Kubelet Checkpoint API из презентации "Специфика расследования инцидентов в контейнерах" (слайд 34) c KazHackStan 2022.

Это реально крутое будущее как для security, так и для IT, на пример, для реализации live migration. Пока что данное API в Kubernetes находится в ContainerCheckpoint feature gate, который по умолчанию отключен, и очень ограничен и упрощен:

POST /checkpoint/{namespace}/{pod}/{container}

Тоесть пока что можно просто сделать checkpoint/snapshot и потом в ручную с ним поработать. Но мы то знаем что под капотом у него CRIU (Checkpoint and Restore in Userspace), который может это и восстанавливать и запускать! Полностью с этим можно поиграться сейчас можно в Docker при активации Docker Checkpoint (экспериментальная фича).

А так представьте, что можно будет брать и контейнер с атакующим переносить (делать live migration) в sandbox cluster и там наблюдать и изучать его действия ;)

Слайды моего коллеги "Pentesting Kubernetes: From Zero to Hero" c VolgaCTF 2022.

Задавайте свои вопросы в комментариях!

Выложили видео и слайды с ArgoCon 2022. Это мероприятие от создателей таких проектов как: Argo CD, Argo Workflows, Argo Rollouts, Argo Events и соответственно о них.

Не обошлось и без докладов про связь данных проектов с security. Я для себя выделил:
- "Attacking Argo CD with Argo CD (and then Defending)" - говорящее название - любой продукт нужно готовить правильно!
- "Securing GitOps Supply Chain with Sigstore and Kyverno" - подпись образов и их проверка с помощью Policy Engine Kyverno и Sigstore (слайды, код).
- "Secure by Default with GitOps - A Guide to OPA with Argo CD" - подпись образов и их проверка с помощью Policy Engine OPA Gatekeeper и Sigstore (слайды, код).
- "Using Argo Project to Help Elastic infoSec Team in Securing Elastic" - очень рекомендую посмотреть тем командам что строят свой SOC на ELK стеке в Kubernetes - вы скорее всего и Argo проекты захотите себе взять после этого (слайды).

Запуск контейнера в ручную от Ивана Величко;)

Последнее время я много пишу про безопасность образов. И возникает вопрос, а как дела обстоят у нашего Luntry и как мы смотрим на данный аспект. Ведь в нашем составе также есть сторонние компоненты и в них появляются известные уязвимости. И так по порядку, что мы делаем и что предоставляем:
1) Стараемся своевременно все патчить. Но это не всегда просто и все равно есть окно между моментом, когда это находит наш же сканер (да у нас есть сканер на известные CVE) и моментом когда обновленная версия раскатывается клиентом.
2) Переходим на distroless образы. Снижаем false positive срабатывания сканера на известные CVE, уменьшаем attack surface и возможности для атакующего.
3) Предоставляем модели поведения (behaviour models) для Luntry на наши микросервисы. В случае попыток эксплуатации известных CVE или не известных уязвимостей (0-days) наш движок обнаружит аномалию и проинформирует клиента.
4) Предоставляем AppArmor для наших микросервисов. В случае попыток эксплуатации известных CVE или не известных (0-days) подсистема ядра Linux просто не даст запуститься тому, что не прописано в AppArmor профиле.
5) Предоставляем NetworkPolicy для наших микросервисов. Если атакующий каким-то образом все-таки смог запустить вредоносную логику, то по сети он не сможет общаться с сервисами клиента, да и вообще не со всеми компонентами нашей системы.

На мой взгляд это супер набор, который сторонний вендор может сделать и предоставить клиенту, для обоснование безопасности своего продукта на ряду со SBOM. И в моем идеальном мире будущего - сторонний вендор, аутсорсер должен предоставлять это на свою разработку, а клиент только использовать и контролировать, реализую концепцию ZeroTrust.

Сегодня поговорим об одном тонком моменте связанным с автоматической генерацией NetworkPolicy. Реализуя данную фичу в нашем Luntry, мы предварительно проанализировали подобную функциональность в других решениях и с удивлением обнаружили, что никто не учитывал специфику labels, которые есть у Pods ...

Если сказать проще, то при генерации NetworkPolicy в этих решениях в podSelector попадали абсолютно ВСЕ labels - типа pod-template-hash, minor-version и подобные легко/часто меняющиеся labels. Это автоматом означало, что при их изменении, применение NetworkPolicy просто отваливалась. В итоге, с такими политиками приходится еще и возится вручную или часто их пере генерировать и пере применять.

Так что важно при работе с NetworkPolicy выделить/определить labels по которым будет применяться сетевая политика ;)

Сегодня и завтра пройдет ежегодный eBPF Summit . Старт в 18:30 по Мск. Трансляцию всех докладов всех двух дней можно посмотреть здесь:
- День 1
- День 2

Там море интересных докладов! Я же для себя отметил:
- Signed eBPF Programs: A Cross-Platform Analysis
- When you need to overcome your fear and build your own data-driven eBPF firewall
- Securing systems with eBPF Linux Security Module
- Using eBPF in system security
- Applied eBPF for cross platform security research
- Analysis of offensive capabilities of eBPF and implementation of a rootkit

P.S. Для ряда презентаций первого дня в описании доклада уже доступны слайды!

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

Но сначала поясню что у нас в Luntry есть функциональность Runtime Security, которая позволяет строить поведенческие модели для микросервисов (выглядят они в виде графа взаимоотношений между процессами). Отхождения от модели поведения создаёт аномалию и на неё уже реагирует SOC. Это как бы их классический сценарий работы.

Но порой они лезут глубже и изучают что вообще микросервисы делают и из чего состоят. И находят просто ужас/кошмар разработки. На пример, цепочку вызовов: java -> python -> bash -> perl …ну и это уже эскалируют на Лидов разработки, которых такое тоже повергает в шок =)

PS Для SOC такие цепочки вызовов также выглядят очень подозрительно и напоминают закрепление ;)

На просторах сети попалась очень добротная статья "Kubernetes Security Best Practices Part 2: Network Policies" - про нативные NetworkPolicy (не забываем что есть и кастомные от Calico и Cilium).

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

Отдельно обращу ваше внимание на раздел про "Deny-all NetworkPolicy", так как далеко не все понимают истинный смысл данной политики (и скорее используют на автомате, бездумно).

А так же в статье отдельно четко прописан момент про "NetworkPolicies have to be defined on both sides" - не забывайте ;)

После релиза PCI Security Standards Council документа "Guidance for Containers and Container Orchestration Tools" исследователи продолжают его анализировать и оценивать его применимость к Kubernetes. Так в новой статье "The Challenges of Assessing Kubernetes clusters for PCI Compliance" автор рассматривает проблемы/вызовы с которыми может столкнуться аудитор при рассмотрении сред Kubernetes в виду их разнообразия (не забываем, что Kubernetes это фреймворк и каждый его готовит и использует по своему). Фундаментально автор рассматривает 2 важных аспекта:
1) Managed against Unmanaged - тут и возможность проверить настройки Control Plane и точное расположение файлов и имен или вообще как отдельный кейс OpenShift.
2) Kubernetes Versions - достаточно сказать об очень динамичном развитии Kubernetes с появлением новых возможностей (в стадиях “alpha” , “beta”, “GA”), так и с исчезновением старых (“deprecated”).

Так что некорректное соотношение гайдов к окружению может дать абсолютно непрогнозируемые результаты (false positive или false negative).

В официальном блоге появилась емкая и короткая заметка c очень говорящим названием "Kubernetes 1.25: alpha support for running Pods with user namespaces".

Если кратко, то она о фичи которая позволяет контейнерным процессам работать в отдельном пространстве (user namespace), отличном от хостового. И root в одном не является root в другом. Что также позволяет уменьшить возможный ущерб в случае эксплотации ряда уязвимостей в контейнере.

Для работы с этой фичей необходимо:
1) Включенный UserNamespacesStatelessPodsSupport feature gate
2) Настройка "hostUsers: false" в спецификации Pod
3) Container Runtime с соответствующей поддержкой: CRI-O >= v1.25 или containerd >= 1.7 (еще не вышла)

Также в документации есть более детальный пример использования данной фичи в разделе "Use a User Namespace With a Pod".

P.S. Кстати, не путайте эту фичу с KubeletInUserNamespace, появившейся в 1.22.

P.S.S. Для полного погружения в тему изучите 1 и 2.

На днях прошла конференция KubeHuddle 2022 в расписании которой есть много всего интересного, а видео уже доступно [1,2,3,4]. На пример:

- eBPF or sidecars?
- Securing Kubernetes with Open Policy Agent
- Hacking Kubernetes Like a Beginner with kdigger 🔥
- Secret Management: The Soft Way

- Hacking Kubernetes: Live Demo Marathon 🔥
- Who Can You Really Trust?
- Step by step Kubernetes observability with eBPF
- How to protect your Kubernetes cluster using Crowdsec
- Policy + Cloud Controllers = Secure Scalable Dev-Centric Infrastructure.

- EBPF and Kubernetes - Next level observability
- BumbleBee: Or How I Learned To Stop Worrying And Love eBPF

P.S. Видео с eBPF Summit 2022 также уже доступно ;)

Статья "Exploiting Distroless Images" с прикольной техникой эксплотации в контейнерах на базе gcr.io/distroless/base, которая позволяет читать, писать произвольные файлы и выполнять команды в этом distroless image!

А все это базируется на присутствующей внутри этого образа OpenSSL! Да, shell внутри такого образа нет, но зато можно использовать interactive command prompt от OpenSSL ;)

Таким образом, атакующий, получивший доступ к Kubernetes кластеру, может, через установленный OpenSSL в distroless base образе, прочитать service account tokens (SA), прокинутые secrets и даже получить интерактивное выполнение команд через загрузку custom shell.

Помните в одном из прошлых постов писал, что не все Distroless Images одинаковые (static/base/cc/interpreted)?!

Так что distroless images это не панацея, а лишь одна из техник усиления (hardening) - и никто behavior monitoring, AppArmor не отменял.

P.S. О данной проблеме/особенности было сообщено Google в августе 2021 и они решили не фиксить это.