На последней конференции AWS re:Invent 2020 состоялся релиз open source Amazon EKS Distro (EKS-D).

EKS-D содержит абсолютно аналогичные версии Kubernetes и зависимостей, которые использует сервис Amazon EKS, что позволяет создавать EKS-кластеры на собственном оборудовании, в локальной среде с помощью привычных инструментов.

Основные преимущества использования, согласно тезисам презентации, обеспечиваются возможностью удобной миграции кластеров (например из тестовой локальной среды on premise на Amazon EKS), наличием необходимых патчей безопасности и совместимости компонентов, а так же расширенной поддержкой версий Kubernetes со стороны AWS, в течении 14 месяцев. EKS-D строится на основе kops, включает etcd & etcdctl, CoreDNS, Upstream CNI, CSI sidecars, aws-iam-authenticator.

С точки зрения пентестера, security специалиста, EKS-D - это отличная возможность потренироваться и локально развернуть свой EKS-кластер для исследований.

На данном канале уже не раз упоминался такой документ от CNCF как Cloud Native Security Whitepaper, в котором есть много категорий инструментов по соответствующей теме. В текущий момент CNCF разрабатывает Cloud Native Security Map (Vanilla), где теперь для каждой из этих категорий приводит перечисления коммерческих и open source проектов. Будем следить за его прогрессом и посмотрим, что из этого выйдет в конечном итоге. Но вы уже сейчас можете посмотреть черновик ;)

Dostainer - Kubernetes Resource Exhaustion PoC Container

Данный проект позволяет исчерпать ресурсы в Kubernetes кластере 3 способами:
- Выделив весь оставшийся RAM на Node
- Выделив все оставшееся место на диске
- Fork bomb

При этом в YAML файле проекта содержаться и меры по предотвращению исчерпания ресурсов и для их применения необходимо их просто раскомментировать.

Как и для чего может быть полезен данный проект?)

1) Наглядно продемонстрировать коллегам необходимость использования лимитов в YAML ресурсах приложений.
2) Проверить все ли у вас корректно настроено в мониторинге и сможет ли SRE заметить такую проблему и быстро ее обработать.
3) Проверить как поведут ваши приложения (и кластер) если окажутся на Node с таким вот контейнером - некоторый такой элемент chaos engineering.
4) Департаменту безопасности обновить сигнатуры вредоносных образов контейнеров ;)

В комментариях предлагайте свои варианты использования!

AWS анонсировал релиз ECS Exec для EC2 и AWS Fargate
ECS Exec - возможность запустить интерактивный шелл на EC2 и Fargate, под капотом автоматически монтируемый том c бинарями SSM agent, который обеспечивает необходимую коммуникацию с контейнером.

С точки зрения безопасности, доступ определяется IAM политикой ecs:ExecuteCommand, в контексте users/groups/IAM roles для всего кластера или конкретного контейнера. ECS Exec поддерживает Amazon CloudWatch и CloudTrail для мониторинга и логирования выполняемых команд и S3 для хранения архивов. Коммуникация между ECS Exec и контейнером зашифрована с помощью TLS1.2 по умолчанию, так же можно использовать собственный KMS ключ.

К тому же, стоит отметить что ранее совсем не было возможности делать exec-ing для контейнеров запущенных на AWS Fargate - легковесной fully managed microVM на основе firecracker. (об этом мы уже писали) Поэтому, кажется, что ECS Exec будет довольно востребованной фичей, при условии и соблюдении принципов least privilege при конфигурации IAM.

4 мая в рамках Virtual KubeCon + CloudNativeCon Europe пройдет очередной Cloud Native Security Day.

Уже сейчас доступно расписание данной секции. В докладах будут рассмотрены и затронуты такие темы:
- Безопасность Open Source кода (разработка, проверка, распространение - в общем весь supply chain)
- Как WebAssembly может быть использован для написания Kubernetes admission политик
- Как eBPF инструменты могут помочь при решении threat detection задач в Kubernetes окружении
- Как Hierarchical Namespace Controller (HNC) и `Kyverno могут вместе помочь реализовать “namespaces-as-a-service”
- Проблемы расследования инцидентов в Cloud Native окружениях
- Представят новый фреймворк для оценки рисков в Kubernetes на базе CIS benchmarks и матрицы MITRE ATT&CK для containers/Kubernetes


Также будет Capture The Flag в Kubernetes окружении!

Из рубрики наблюдений. Заметил, что очень много людей пытаются начинать строить безопасность Kubernetes сразу исходя из пунктов различных документов best-practices.

Мое мнение, что нужно идти от себя, от собственных рисков, моделей нарушителей, моделей угроз и т.д., в общем со знанием дела что и для чего вы меняете/добавляете, а не от общепринятых практик, которые могут быть лишь ориентиром для вас. Некоторые и них могут вам не подходить, даже может что-то ломать (нужно помнить о Dev, Ops команд) и уж точно не учитывать ваши особенности. Не говоря, что уже есть собственные финансовые, временные, человеческие, процессные ограничения и особенности.

Со временем, опытом и знанием вы точно придёте к тому что из этого списка best-practices вам актуально и вы будете их отслеживать и контролировать.

Тема создания Network Policy в Kubernetes не такая простая как кажется на первый взгляд. Недавно авторы CNI Cilium создали проект NetworkPolicy Editor, который позволяет создавать, визуализировать и делится сетевыми политиками в online формате на странице https://editor.cilium.io/.

Отдельно отмечу правый нижний угол, где есть 6 полезных туториалов с теорией. Если вам этого недостаточно, то посмотрите вебинар "Demystifying Kubernetes Network Policy".

А если и этого недостаточно, то сегодня в 20:00 (Мск) можно посмотреть по данной теме и технический тренинг "Securing Kubernetes w/ Network Policies", где также будут покрыты темы CNI Cilium и eBPF.

Статья "Using Kubelet Client to Attack the Kubernetes Cluster".

Данный материал хорошо раскрывает аспект безопасности Kubernetes кластера со стороны его компонента под названием kubelet. Этот компонент присутствует на каждой Node и является связующим звеном между Kubernetes API и Container Runtime.

В статье рассматриваются такие моменты как:
- Описание целей и задач kubelet
- kubelet API с его недокументированными возможностями
- Утилита kubeletctl, очень полезная при pentest
- Слабые настройки kubelet, которые могут приводить к удаленным атакам на кластер
- Пути повышения безопасности для kubelet

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

Спустя год Microsoft обновила матрицу Adversarial Tactics, Techniques & Common Knowledge (ATT&CK) для Kubernetes, актуализировав и дополнив ее с учетом новых угроз и изменений в Kubernetes.

Убрали:
- Техники связанные с Kubernetes Dashboard (если k8s у вас старый, то это еще актуально)
- Технику с Tiller endpoint от Helm 2 (если у вас не Helm 3, то еще актуально)

Добавили:
- Exposed sensitive interfaces — это когда привилегированные сервисы без аутентификации для всех желающих выставляют
- Sidecar injection - техника выполнения своего кода без порождения новых подозрительных Pods
- Malicious admission controller - закрепление в системе по мотивам вот этого доклада
- Access managed identity credential - про доступ к Instance Metadata Service (IMDS)
- CoreDNS poisoning - название говорит само за себя, а атака идет на его ConfigMap
- ARP poisoning and IP spoofing - живее всех живых в 2021
- Images from private registry - техника из добавленной тактики Collection

Не думал, что когда-нибудь пересекусь с Vmware Tanzu, но в итоге пришлось. Для тех, кто не знает это Cloud штука от Vmware с поддержкой Kubernetes со множеством имен:
- Project Pacific
- vSphere with Kubernetes
- VMware Tanzu Kubernetes Grid (TKG) и VMware Tanzu Kubernetes Grid Integrated Edition (TKGI)
- + различные редакции Basic/Standart/Advanced

Может еще как-то и что-то - может где-то и ошибся, но разобраться с тем, что понаписал их маркетинг не просто.

Из интресного:
1) Как и в OpenShift (речь о project), тут namespace это security boundary
2) Основной Container Runtime это MicroVM (а не контейнер) под названием CRX (Сontainer Runtime eXecutive). Это такая мини-виртуальная машина с ядром Linux внутри (на базе ответвления Photon OS). При этом Pod под таким управлением называется Native Pod или vSphere Pod. Поддержка Open Container Initiative (OCI) в наличии
3) Работа сети лежит на NSX-T

Было бы интересно послушать людей кто работал с этим решением.

Сегодня рассмотрим сервис AWS IAM, как основной инструмент для аутентификации и авторизации AWS EKS.
Для аутентификации EKS использует Webhook Authentication Token, API-серверу передаётся специально сформированный токен, в котором передаётся идентификатор ARN (Amazon Resource Name) IAM-пользователя/роли.

Далее API-сервер, с помощью AWS IAM Authenticator обращается к сервису AWS IAM, который проверяет имеет ли данный пользователь права обращаться к кластеру AWS EKS, сравнивая ARN запроса с ARN mapRoles в aws-auth ConfigMap.

После того, как пользователь прошёл аутентификацию, Kubernetes должен c помощью Role Based Access Control проверить сам запрос — есть ли у данного клиента право на выполнение запрошенных действий, например — выполнение вызова kubectl get pods. Так же для аутентификации AWS EKS в качестве альтернативы может использоваться OpenID Connect (OIDC).
Таким образом, при условии грамотной конфигурации, AWS IAM представляет собой мощный инструмент для обеспечения безопасности AWS EKS.

На этой неделе будет небольшой цикл постов про sensor-based решения по безопасности для Kubernetes. Мне с командой довелось посмотреть, покопаться во внутренностях во всех широко известных решения на сегодняшний день (знаю, как там работает любая функциональность). Ну и плюс мы сами занимаемся разработкой решения для observability и visibility происходящего в Kubernetes кластере, также в sensor-based архитектуре и знаем разные тонкие и не очевидные моменты, которыми можем поделиться. Рассказывать я буду без упоминаний брендов, при этом считаю, что у каждого из них есть как свои слабые, так и сильные стороны, так что у каждого найдется своя аудитория. При этом имея обширный опыт работы с сенсорами от Antivirus, EDR (Endpoint Detection and Response) решений позволит мне провести параллели и с ними.

Sensor-based решения раскатываются на все Node (обычно как DaemonSet) и затрагивают все приложения на них, поэтому очень важно знать и понимать, что и как они делают, чтобы не пострадала ни надежность, ни производительность, ни безопасность.

В комментариях к этому посту вы можете написать вопросы, и я постараюсь на все ответить либо сразу, либо в постах цикла.

Пару недель назад, AWS анонсировал релиз дополнения policy validation для IAM Access Analyzer - инструмент, позволяющий провести проверку конфигурации IAM политик на соответствие требованиям безопасности (более 100 проверок на основе AWS AIM best practices) и детальные рекомендации по настройке IAM в соответствии с принципами least privilege.

Пользоваться можно прямо из веб-интерфейса IAM Console при создании IAM политик, а та же CLI/API aws accessanalyzer validate-policy для интеграции с пользовательскими CI/CD workflows, без необходимости использования сторонних инструментов.

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

Первая часть из цикла про sensor-based решения по безопасности для Kubernetes.

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

Сбор этой информации может происходить как ИЗ контейнера, так и ВНЕ его. Для первого случая решения используют sidecar- контейнеры, подмену системного компонента runc и встраивание (injection) собственных библиотек в процессы, пользовательских приложений. Для второго случая используются модули ядра и eBPF пробы.

1) Самым надежным и правильным решением на сегодняшний день считаются eBPF пробы - просто, быстро, стабильно.
2) Модули ядра предлагают, как вариант, когда ядро младше 4.19. При этом нужно понимать, что при ошибке в модуле и его падении - упадет и вся Node.
3) Sidecar- контейнеры могут помочь видеть только сеть и при этом дают значительные ресурсные издержки на каждый Pod.
4) Подмена runc обычно идет в связке со встраиванием собственных библиотек через LD_PRELOAD, dlopen, патчинг GOT таблиц и т.д. Все для того, чтобы подготовить окружение для запускаемого контейнера для его мониторинга - то есть происходит модификация окружения (контейнеры под таким решением и без него могут вести себя по-разному). Данная библиотека производит перехват нужных функций на user-space уровне. Получаем такой классический антивирус из нулевых. При этом накладные расходы по ресурсам размываются с расходами самого приложения и сложно сказать на сколько они в итоге повышаются, но точно падает скорость работы.

Для окружений с MicroVM (типа AWS Fargate) или serverless-функциями (типа AWS Lambda) работает только 4 вариант со встраиванием собственной библиотеки для перехвата ряда функций.

Вторая часть из цикла [1] про sensor-based решения по безопасности для Kubernetes.

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

Sensor'ы могут это обеспечить по-разному (со своими плюсами и минусами): через системные механизмы, CRI и собственными силами.

1) Системные механизмы значит, что сам sensor этим не занимается, а занимается ОС с помощью seccomp, AppArmor, SeLinux в режиме prevention, а в случаи сети это вообще NetworkPolicy самого Kubernetes. В таком случаи sensor может помочь подготовить политики для данных механизмов, но применять их будет ОС. Обеспечивает высокий уровень надежности и контроля с высокой наглядностью для всех команд (так как можно прописать прям в YAML).
2) Сценарий с CRI (Container Runtime Interface) означает контроль на уровне работы всего контейнера - запуск, пауза, остановка. Реализации бывают разные и некоторые способны только на response, никакого реального prevention.
3) Категория собственными силами самая обширная и полностью зависит от способа работы (рассматривали в прошлом посте) самого sensor. В случае встраивания библиотек, тут классический антивирус - подгружающий в себя все что нельзя и на каждый системный вызов проверяющий можно это или нет. В случае eBPF все может быть очень красиво на базе KRSI (Kernel Runtime Security Instrumentation), но требует ядро > 5.8. Явным плюсом тут является возможность на лету менять сами политики/правила.

Важно понимать, что sensor как и ContainerRuntime достаточно опосредованно понимает, что такое сущности Kubernetes и мыслит в терминах контейнеров и происходящего в нем. Также sensor заранее не знает где и какой workload будет запущен и ряд проверок будет делать там, где это и не надо, замедляя работу даже тех сущностей, к которым prevention и не относится.

Третья часть из цикла [1,2] про sensor-based решения по безопасности для Kubernetes.

Согласитесь исполняемый файл bash запущенный в контейнере от entrypoint (runc) и bash запущенный вашим, например, java и python приложениями это 3 разных действия с точки зрения поведения bash. Или еще пример: Обращение к файлам в директории /var/run/secrets/kubernetes.io/serviceaccount/ двумя разными процессами в контейнере это 2 разных действия. К чему это все? А к тому, что разные sensor-based решения на происходящее внутри контейнеров смотрят с разным уровнем гранулярности (точности), которая потом ложиться в основу модели поведения или политики.

Я для себя выделил 3 типа гранулярности политик: слабое/низкое (1), среднее/гибридное (2) и сильное/высокое (3):
1) Все происходящее в контейнере относительно процессов, файлов и сетевого взаимодействия отражается в виде списков. То есть список процессов, что там был запущен, список файлов к которым было обращение и список сетевых endpoint'ов к которым было обращение. При этом эти списки не связана. Таким образом, если процесс bash есть, то непонятно от кого и он всегда разрешен, если есть обращение к /var/run/secrets/kubernetes.io/serviceaccount то это можно всем, соединение на определенный IP возможет от любого процесса в контейнере.
2) Это что-то среднее между низким и высоким уровнем гранулярности политик, относительно тех или иных связей между процессами, файлами и сетевыми операциями. Может быть много вариаций, в плоть до полного отказа от контроля от файловых операций. В основном, оставляют связи на уровни родитель-потомок.
3) Все происходящее в контейнере относительно процессов, файлов и сетевого взаимодействия отражается в виде графа. Это означает наличие иерархии взаимодействия между процессами и для каждого из них собственная иерархия взаимодействия с файловой системой и сетью. При этом каждый процесс в такой иерархии может иметь свои права доступа к файлам (r,w,rw).

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

Четвертая часть из цикла [1,2,3] про sensor-based решения по безопасности для Kubernetes.

Что это за контейнеры, за которыми идет наблюдение разные решения могут видеть на разном уровне детализации. Тут нужно вспомнить как работает Kubernetes с Container Runtime через CRI. Вся цепочка создания Pod сокращенно выглядит так: создаётся ресурс Pod, далее Container Runtime создает контейнер и происходит обновление статуса ресурса через добавление информации о контейнере, который работает в данном Pod'е. Kubernetes только уже после фактического запуска контейнера связывает информацию с ресурсом Pod.

В связи с этой не очень простой схемой разные решения к контейнеру присоединяют (enrichment стадия) разное количество информации. Самый полный комплект выглядит таким образом:
- Image : k8s.gcr.io/etcd
- Digest : sha256:303ce5db0e90dab1c5728ec70d21091201a23cdf8aeca70ab54943bbaaf0833f
- Tags : k8s.gcr.io/etcd:3.4.3-0
- Container ID : eaadea8d867e2833b1fee449a993ec96c2708bbec37e9349369a6541f796d9ae
- Container Name : etcd
- Cluster : PROD
- Node : flex-f94c4afe-1
- Namespace : kube-system
- Pod : etcd-flex-f94c4afe-1
- Kubernetes Resource : StaticPod:etcd
- UID : 816f47b8-02bd-456d-8b1e-3b1a3f1fa318

Чем больше решение присоединяет информации к контейнеру или событию в нем, тем проще расследовать сбои и инциденты.