Сегодня еще отдохнем немного от темы сканирования образов (думаю еще 1-2 поста и я закрою данную тему).

Сейчас мы поговорим о Static Pods.

Это Pods, которые управляются не через Kubernetes API server, а kubelet на самой Node. В основном это нужно для служебных задач кластера, на пример, бустрапа чего-либо. Подробнее о них можно почитать в документации. Для запуска таких подов достаточно расположение YAML файл с описанием Pod по определенному пути и указанием на него в `kubelet.

Но это также очень полезная штука и для атакующих (недобросовестных сотрудников и т.д.), которые проникли на Node тем или иным способом (вариантов и способов хватает). Просто authentication token от kubelet атакующему может не хватить - на пример, чтобы создать Pod в kube-system namespace. Что делать? Выход: пойти в обход Kubernetes API server, с помощью Static pod ;)

Пятая часть из цикла [1,2,3,4] сканирования образов.

Сегодня речь пойдет про создание минимального docker образа. Есть замечательная серия постов (+ код) на эту тему под названием "The Quest for Minimal Docker Images". Сам автор об этом пишет так: "We’re going to review a number of techniques to reduce image size, without sacrificing developers’ and ops’ convenience." С уменьшением размера выкидывается все (или почти все) ненужное и сканеры образов начинают меньше шуметь + маленький размер образов для хранения.

1) Первая часть про multi-stage сборку.
2) Вторая часть об особенностях работы с различными языками Go, Java, Node, Python, Ruby, Rust и о Alpine образе.
3) Третья часть покрывает различные паттерны и анти-паттерны при работе с ЯП, фреймворками. А также использование Bazel, Distroless, DockerSlim, UPX.

Маленький комментарий о статической линковке - перед ней сканеры образов просто слепы - не забывайте об этом.

В итоге если вы по тем или иным причинам не можете использовать Distroless подход, вы можете прийти к концепции golden-image (минимального, хорошо проверенного, эталонного и т.д.) для своих команд.

Red Kube или Red Team KubeCTL Cheat Sheet - набор kubectl команд (27 штук), полезных при пентесте/аудите, и две лабы, где их можно все попробовать. Отдельно стоит отметить, что все команды автор разбил на категории в соответствии с матрицей MITRE ATT&CK. Так что это все очень хорошо классифицировано (особенно для начинающих). Но важно не забывать, что чтобы данные команды успешно выполнились у атакующего должны быть соответствующие права в системе. На пример, через скомпрометированный token полученный тем или иным образом.
Так же по мне использовать в атаке приносной бинарь kubectl - очень заметно, даже если переименовав, тем самым сбив детект у части решений по безопасности. Лучше curl (он, кстати, требуется для части этих команд), но он еще должен находится в образе – иначе тоже его нужно будет нести с собой.

Среди возможных сертификатов по Kubernetes от The Linux Foundation пополнение - CKS (точнее должен появится вот-вот до KubeCon + CloudNativeCon North America Virtual). Таким образом будет доступно 3 сертификата

- Certified Kubernetes Application Developer (CKAD) - для разработчиков.
- Certified Kubernetes Administrator (CKA) - для администраторов.
- Certified Kubernetes Security Specialist (CKS) - для специалистов по безопасности.

Для получения последнего необходимо также иметь сертификат CKA.

Учебный план сертификации по темам:
1) Cluster Setup (10%)
2) Cluster Hardening (15%)
3) System Hardening (15%)
4) Minimize Microservice Vulnerabilities (20%)
5) Supply Chain Security (20%)
6) Monitoring, Logging, and Runtime Security (20%)

Кто-то уже даже под это сделал симулятор экзамена и продает.

Недавно наткнулся на репозитарий с правилами детектов для Elastic Security Solution (развитие или дополнение ElasticSearch). Среди правил, там есть правила для AWS, Azure, GCP в соответствии с матрицей ATT&CK. Честно говоря, про Kubernetes там нет ничего. И мое внимание это привлекло лишь потому, что можно провести параллели с Falco, который также работает на основе правил (правда которые вы же и должны предварительно адаптировать под себя).

В правилах от Elastic Security Solution мне очень понравилось и позабавило поле false_positives. Понравилось тем, что авторы вообще проработали этот момент и сделали для этого хорошее описание, а позабавило что это поле есть наверно у 99% всех правил. При этом эти правила в основном для детектирования каких-то инфраструктурных вещей, что на мой взгляд определенно имеет право на существование.

А вот второй момент по детектированию аномального поведения тут реализован отлично, от того, как это сделано в Falco (в нем надо собственноручно описать нормальную модель поведения и поддерживать ее). Здесь используется отдельная категория для таких вещей как ML - machine learning. Насколько это качественно работает сказать абсолютно невозможно и единственный механизм влияния тут это численное поле anomaly_threshold. Что говорит нам о использовании нейронных сетей. При разработке своего детектора аномального поведения приложений в Kubernetes, мы также проводили эксперименты с нейронными сетями и пришли к выводу что основная их проблема это не возможность объяснить на основании чего было принято то или иное решение оператору и в случае false positive необходимость полного переобучения сети. Так что, меняя значение anomaly_threshold остается просто ждать какой-то магии и конечный результат вы вряд ли поймете.

В процессе, подготовки доклада по теме побега из контейнеров в Kubernetes, открыл для себя такую тему как Node isolation как инструмент реализации security mitigations для определенных угроз. С помощью Node isolation можно разграничивать запуск Pod'ов по Node, группируя их на основании того или иного свойства. Так на пример, можно наиболее критичные сервисы (платежные сервисы, сервисы работающий с пользовательскими данными и т.д.) располагать отдельно от менее критичных (frontend, мониторинг и т.д.) или не доверенных (написанных на аутсорсинге, legacy кода). Или еще сценарий, сервисы с большим количеством известных CVE, отдельно от тех, где данная проблема уже как-то решена.

Все это можно реализовать благодаря:
1) labels и taints - для распределения Pod'ов
2) node authorizer и node restriction - для ограничения выставления атакующим нужных ему labels

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

Вчера узнал о таком проекте как Open Cloud Security Posture Management Engine (OpenCSPM), который буквально недели 2 назад появился на GitHub. Из описания следует, что это платформа для более глубокого понимания конфигурации и метаданных вашего облака, призванная помочь понять и снизить риски. И заявляется поддержка cloud-native платформ (AWS, GCP) и нативного Kubernetes. Проект также привлек мое внимание ввиду использования графовой БД RedisGraph для анализа.

Посмотрим на поддержку Kubernetes:

1) Для того, чтобы анализировать данные от какой-либо системы для этого нужен loader. В основной ветке k8s_loader.rb пока пустой ...
2) В отдельном репозитарии лежит логика запросов к графовой БД для валидации правил. Запросов к данным k8s нет - достаточно сделать поиск по control_id в виде darkbit-kubernetes-*.
3) В отдельном репозитарии лежит описание проверок с remediation и validation. Вот тут уже информация по k8s есть. И это пока единственное, что имеет смысл посмотреть в данном инструменте.

Шок новость: Идут обсуждения об удалении/отказе (скорее о замене) от Pod Security Policies.

Проблемы PSP:
1) Путаница с привязкой субъектов
2) Проблема дублирования Admission Controllers
3) Отсутствие поддержки альтернативных CRI
4) PSP только для `Pod`s и ничего больше
5) Проблемы с тестированием покрытия PSP

Есть вероятность что от данной реализации откажутся в Kubernetes 1.22.

Обсуждение будущего PSPv2 можно наблюдать в документе "Future of PodSecurityPolicy". Работает над этим группы Sig-AUTH и Sig-SECURITY.

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

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

The Kubernetes Security Profiles Operator - данный проект призван помочь с управлением, распространением и применением таких профилей безопасности как seccomp, AppArmor, SeLinux, PodsecurityPolicy и RBAC.

Проект разрабатывается в рамках Kubernetes Special Interest Group и находиться еще в ранней стадии. Пока есть поддержка только seccomp, который недавно попал в GA. Далее по планам поддержка AppArmor.

Это должно позволить просто и эффективно использовать встроенные механизмы безопасности Linux для обеспечения prevention внутри Pod'ов Kubernetes.

Размышляя о проблемах PodSecurityPolicy и, в частности, о том, что она ограничена только Pod'ами, что в свою очередь позволяет атакующим обходить PSP и совершать побег из контейнера благодаря другим ресурсам (например, PersistentVolumes и его hostPath).

Я пришел к выводу, что подобных сценариев обхода PSP можно поискать и среди других ресурсов и особенно среди CustomResourceDefinition. Сейчас многие делают свои CRD и operator'ы, вообще не задумываясь что с помощью них можно использовать их возможности для зловредных целей. Чтобы кто-то широко занимался аудитом CRD (да и `operator`ов) я пока не слышал.

Это касается не только путей монтирования, но, например, и сетевых взаимодействий. Можно потенциально сделать что-то похожее на CVE-2020-15157, о котором я уже рассказывал. Или устроить DoS, подсунув operator`у специально подготовленный `CRD.

При этом атакующий может очень просто узнать о тех ресурсах, что у вас используются благодаря curl и default service account. Как я уже говорил знание о используемых ресурсах дает много информации при разведке. Отключить данный token можно так.

В ближайшее время думаю будет небольшое затишье по новостям/мыслям/идеям от меня, а потом наоборот много всего интересного. Сейчас активно работаю над двумя выступлениями:
- "Container escapes: Kubernetes edition"
- "Kubernetes: Трансформация к SecDevSecOpsSec"

eBPF Summit 2020 выложил все доклады отсортированные по playlist'ам. Мой личный топ докладов:
- "Safe Programs The Foundation of BPF"
- "bpfbox: Simple Precise Process Confinement with KRSI and eBPF"
- "Building a Secure and Maintainable PaaS"
- "Kubernetes Network Policy Logging with eBPF"
- "Security Auditing and Enforcement using eBPF"

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

DAST operator — это Kubernetes operator, позволяющий реализовывать динамическое тестирование безопасности приложений и его API, на базе бесплатного и открытого решения Zed Attack Proxy (ZAP).

Данный оператор отлично ложиться в концепцию DevSecOps и хорошо смотрится в тестовом кластере при прогонке тестов для сервисов. Архитектурно от состоит из 2 reconcilers (для самого DAST и Services) и validating admission webhook для Ingress. Также для его успешной работы придётся добавить соответствующие annotations в тестируемые ресурсы + описать его собственные CRD.

Делать он сам по себе пока еще не много что умеет, но roadmap выглядит красивым. Честно я рассчитывал найти еще такой же operator на базе BurpSuite, который более любим специалистами по ИБ, но по крайней мере такого в открытом доступе не нашлось.

Сегодня хочется опять поговорить про технологии, которые будут двигать развитие контейнерных приложений и Kubernetes в том числе. Есть замечательный проект, за которым я уже давно слежу - CRIU (Checkpoint/Restore In Userspace). Суть проста, в runtime в необходимых контрольных точках (checkpoint) запоминается состояние программы, далее это состояние может быть перенесено на другую систему и программа возобновит (restore) свою работу с контрольной точки. Я лично слежу за данным проектом из-за таких сценариев его использования как "Applications behavior analysis on another machine" и "Snapshots of apps", что может быть очень полезно для security в том числе.

Проекту недавно исполнилось 7 лет и он постепенно начинает прокладывать себе дорогу в большой мир:
- В ядре 5.9 появилась новая capabilities "CAP_CHECKPOINT_RESTORE"
- В сообществе Kubernetes также работают над внедрением этой возможности во фреймворк

Есть даже PoC реализация PodMigration оператора. С ним можно поработать, но требуются измененные версии Kubernetes API, kubelet и container runtime.

В очередной раз хочется поднять проблему CAP_NET_RAW capability, да и вообще тему дефолтных (тут можно посмотреть их список) и необходимых capabilities. Так как CAP_NET_RAW просто является наиболее ярким примером из тех что есть по умолчанию. С ней появляется целый ряд известных проблем:
- Благодаря CVE-2020-14386 можно сделать container escape
- Возможность проведения MitM атак


Если ваше приложение это не использует, то можно убрать те capabilities что ему не нужны, тем самым уменьшить поверхность атаки.
Для этого в разделе securityContext в секции capabilities можно использовать описания add и drop. На пример:

securityContext:
  capabilities:
  drop:
    - all
  add:
    - NED_BIND_SERVICE

Исследуя тему побега из контейнеров, я не мог не обратить свое внимание и на виртуальные машины (VM), которые можно использовать для запуска OCI образов в Kubernetes. В процессе всего этого, я встретил несколько точек зрения о будущем использования VM в Kubernetes. Кто-то считает, что:
- VM вытеснят контейнеры и те уйдут с передовой.
- такие мысли — это происки разработчиков VM, которые проигрывают на данном рынке.
- они нужны только при условии, что есть multi-tenancy
- они нужны только при определенных требованиях информационной безопасности для решение определенных задач

Естественно, речь идет о легковесных VM, типа:
- Kata containers
- Nabla containers
- Firecracker
- Toro Kernel

Что вы думаете на этот счет ?

CVE-2020-15257: containerd – containerd-shim API Exposed to Host Network Containers

Атакующий способен совершить побег из контейнера, поднять привилегии и скомпрометировать хост/ноду.

Все это возможно в условиях и благодаря, если:
- hostNetwork: true для Pod
- контейнер работает от root
- контейнер работает в host user namespace (сейчас это не исправить, но работа над этим кипит в keps/127: Support User Namespaces)

А проблема крутиться вокруг того, что containerd-shim использует abstract Unix domain sockets, который в отличие от normal Unix domain sockets привязан к network namespace процесса, а не к файлу.

В итоге злоумышленник из контейнера может делать такие операции как:
- Чтение/добавление/запись произвольного файла хоста
- Выполнение произвольных команд в контексте containerd-shim (root) на хосте
- Создание и запуск контейнера из runc config.json файла
Это, конечно, более чем достаточно для совершения побега из контейнера на хост.

Сегодня поговорим о таком стандартом ресурсе Kubernetes как RuntimeClass.

Благодаря данному ресурсу можно назначать на каком container runtime будет исполняться тот или иной Pod. Да все так - на вашем кластере моет одновременно существовать несколько container runtime.

Данный тип ресурса пришел на смену sandboxed runtime (описанию в annotations) и как пишут его авторы в KEP: "These implementations could stick with scheme ("trusted" and "untrusted"), but the preferred approach is a non-binary one wherein arbitrary handlers can be configured with a name that can be matched against the specified RuntimeHandler."

Это можно использовать для запуска специфичных подов. На пример, можно использовать gVisor, firecracker, kata или любой другой CRI runtime с более сильной изоляцией, чем у шустрого runc для запуска Pod'ов:
- не доверенных
- подозрительных
- сторонних разработок
- не прошедших pentest или аудит безопасности
- с большим количеством уязвимостей в image

Недавно опубликовали CHANGELOG для Kubernetes v1.20.0-rc.0.

По мне по версии 1.20 можно хорошо понять всю суматошность некоторых решений, применяемых по изменениям в Kubernetes. (Хотя я уверен вы знаете и более яркие примеры, но сточки зрения безопасности я подметил сейчас).

1) В v1.20.0-alpha.0: __"Dockershim security: pod sandbox now always run with no-new-privileges and runtime/default seccomp profile dockershim seccomp: custom profiles can now have smaller seccomp profiles when set at pod level"__ и __"Kuberuntime security: pod sandbox now always runs with runtime/default seccomp profile kuberuntime seccomp: custom profiles can now have smaller seccomp profiles when set at pod level"__
2) А уже в `v1.20.0-beta.1`: __"Docker support in the kubelet is now deprecated and will be removed in a future release. The kubelet uses a module called "dockershim" which implements CRI support for Docker and it has seen maintenance issues in the Kubernetes community. We encourage you to evaluate moving to a container runtime that is a full-fledged implementation of CRI (v1alpha1 or v1 compliant) as they become available."__


Касаемо Kuberuntime security все отлично теперь Pod будет по умолчанию подтягивать "runtime/default" для seccomp. Но улучшать dockershim security и затем деприкейтить его по мне странно). Сам деприкейт dockershim логичен и обоснован.

Также касаемо безопасности fsGroupChangePolicy (часть securityContext) поднялось в стадию beta. Имеет значения OnRootMismatch и Always (по умолчанию).