Introducing Methodology and System of Cloud Analysis Patterns (CAPS)

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

Где это может пригодится? Да, при анализе дампов памяти после crashes, hangs, leaks и т.д. Это должно помочь разобраться с проблемой, устранить ее и повысить reliability системы.

В продолжении темы про IMDSv2 хочется добавить что, использование этого сервиса, не защитит от RCE уязвимости веб-приложения. Если потенциальный злоумышленник попал внутрь контейнера/пода кластера AWS EKS, ничто не помешает ему получить значение $TOKEN из переменных окружения контейнера для формирования валидного запроса при обращении к сервису метаданных curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/latest/meta-data/. И далее получив значение temporary credentials для IAM роли сервиса, уже спокойно грабить караваны анализировать возможности повышения привилегий.

В качестве общих рекомендаций для такой ситуации можно выделить:
- Контроль поведения/аномалий внутри контейнеров кластера AWS EKS.
- Настройку мониторинга CloudWatch, в отношении метрик обращений к IMDSv2 для получения учетных данных IAM.
- Настройку мониторинга CloudWatch, в отношении аномалий использования учетных данных IAM temporary credentials из "неожиданных мест". По опыту знаем:) как отлично работает alert использования IAM temporary credentials, c помощью AWS CLI на системе c user agent Kali/Parrot.
- Конфигурацию IAM политик в соответствии с принципами least privilege.
- Патч-менеджмент ПО веб-приложений.
- Регулярное проведения аудитов безопасности и тестирований на проникновений.

Завтра я буду выступать на конференции "Код ИБ" в Санкт-Петербурге с 20мин докладом "Kubernetes: Незнание системы – злейший враг". За основу для названия данного доклада я взял цитату известного специалиста по ИБ Bruce Schneier: “Complexity is the worst enemy of security, and our systems are getting more complex all the time.” Основной посыл доклада заключается в том, что если вы не понимаете и не знаете что и как работает, устроено в вашей Kubernetes инфраструктуре, то атакующие (и другие не порядочные сотрудники) могут пользоваться вашим незнанием.

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

P.S. Если кто будет на данном мероприятии буду рад общению и знакомству!

Как вы помните реализация концепции NetworkPolicy лежит на CNI, а не самом Kubernetes. Но при этом разработчики разных CNI на этот вопрос смотрят по-разному и расширяют эту концепцию также по-разному. В низу представлена небольшая сводная табличка по данному вопросу.


APIGROUP NAMESPACED KIND

cilium
cilium.io false CiliumClusterwideNetworkPolicy
cilium.io true CiliumNetworkPolicy
networking.k8s.io true NetworkPolicy

calico
crd.projectcalico.org false GlobalNetworkPolicy
crd.projectcalico.org true NetworkPolicy
networking.k8s.io true NetworkPolicy

weave
networking.k8s.io true NetworkPolicy

Kube-router
networking.k8s.io true NetworkPolicy

flannel
networking.k8s.io true NetworkPolicy (не умеет)


В OpenShift благодаря расширению концепции namespace до project, так и во все по умолчанию Pod`’ы в одном `namespace изолированы от всех остальных.

За последний месяц появилось несколько новых Container Runtime, что кажется, что любой уважающий себя человек/компания должно его выпустить (стандартизация CRI, OCI творит чудеса) на тот или иной случай из жизни. Сильно не уверен, что в проде стоит использовать малоизвестный, малораспространённый Container Runtime, но иметь ввиду и быть в курсе определенно стоит.
1) runj - экспериментальный OCI runtime для FreeBSD jails ;) Руководство к проведению эксперимента тут.
2) Quark - OCI runtime на Rust на базе VM изоляции и безопасности, использующий shared memory queues и io_uring для улучшения IO performance.
3) sysbox - модифицированный runc с отсутствием совместимости с OCI (90%) и наличием платной версии. Позволяет запускать в контейнере Systemd, Docker и Kubernetes с высокой степенью простоты и изоляции, базирующейся на Linux user-namespace, в общем rootless.
4) cri-dockerd - заявлен как возможность использовать Docker в качестве runtime после удаления его из поддержки (1.23). Подробнее о судьбе Dockershim можно прочитать тут. По сути, это и будет обертка над Dockershim, позволяющая стартовать его как отдельный демон: kubelet -> cri-dockerd -> dockershim -> docker (1 версия).

Что, по-вашему, интересно и имеет перспективу, а что нет? А может с чем-то из этого вы успели уже плотно поработать?

Из коробки Kubernetes не предоставляет Multi-Tenancy. И для улучшения, данного вопросы была даже создана специальная рабочая группа. Данная группа недавно в рамках блога опубликовала 3 возможных модели/реализации:
1) Namespaces as a Service - на основе проекта Hierarchical Namespace Controller (HNC) + Multi-Tenancy Benchmarks (MTB) (проводит и ряд security проверок).
2) Clusters as a Service - на основе проекта Cluster API (CAPI).
3) Control planes as a Service - на основе проекта Virtual Cluster + Cluster API Nested (расширение CAPI).

Естественно вопрос безопасности не был оставлен без внимания и были упомянуты: image scanning, RBAC, Network Policy, Kubernetes Pod Security Standards, CIS Benchmarks for Kubernetes, policy engines, runtime scanners, VM-based container sandboxing. Часть более общей информации вынесено в скриншот данного поста.

P.S. Также в рамках Kubecon EU 2021 будет панельная дискуссия "Multi-tenancy vs. Multi-cluster: When Should you Use What?" по данному вопросу.

Kubernetes продолжает развиваться и расширятся. Так концепция Ingress постепенно эволюционирует в Gateway API (Alpha стадия). Данной теме и посвящена последняя запись в официальном блоге.

Если оставить за скобками введение для этого новых типов ресурсов (HTTP/TCP/UDP/TLSRoute, BackendPolicy, Gateway, GatewayClass), возможности по манипуляции HTTP заголовками, возможности по пропорциональному управлению трафиком и вообще расширяемости в независимости от используемо Gateway провайдера (реализаций Gateway controller множество, как и для Ingress). То с точки зрения управления и безопасности в глаза бросается старание авторов реализовать в данной концепции Role-oriented design.

Это предполагает удобное разделение ответственности между разными членами команды или департаментами в вопросах маршрутизации и взаимодействия Kubernetes сервисов. По сути, это должно дать возможность безопасно, совместно управлять маршрутизацией несколькими командами, даже в условиях multi-tenant инфраструктур.

Реализация NetworkPolicy лежит на плечах разработчиков CNI. У разных CNI своя реализация, что приводит к различиям и, конечно, ошибкам. Kubernetes сообществу же хотелось, чтобы это везде работало одинаково - давало один результат в независимости от реализации.

Для этого было разработано 2 инструмента для тестирования сетевых политик в различных CNI:
1) e2e framework
2) Cyclonus

За время тестов ошибки уже были найдены в OVN Kubernetes,Antrea, Calico, Cilium.

Помимо этого, SIG Network сейчас работает над следующими нововведениями в NetworkPolicy:
- Поддержка диапазона портов [в v1.21 alpha]
- Автоматический лейблинг для namespace [в v1.21 beta] (необходимо и удобно для меж namespace политик)
- Поддержка Fully Qualified Domain Names(FQDNs) в политиках - есть прототип от Google и его можно уже попробовать как CRD FQDNNetworkPolicies.
- Поддержка политик для всего кластера

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

В Kubernetes самой маленькой вычислительной единицей, которую он создает и управляет, является Pod (отдельной сущностью еще выделяют StaticPod). Но практически никто и никогда Pod'ы сами по себе не создает, а используют вышестоящие ресурсы/контроллеры - хорошо всем известные стандартные: Deployment, ReplicaSet, ReplicationController,StatefulSet, DaemonSet, CronJob и Job. И правильно настраивать PodSecurityContext внутри них, чтобы в дальнейшем Pod это все унаследовал.

Но время идет, подходы к разработке, выкатке приложений начинают выдвигать новые требования к работе и возможностей данных контроллеров становится недостаточно. На пример, для удобных canary или blue-green развертываний. Тем самым сторонние проекты разрабатывают новые контроллеры, которые такое начинают поддерживать. На пример, Rollout из Argo Rollout или Workflow из Argo Workflow. И вот в таких новых ресурсах также стоит не забывать о PodSecurityContext (если, конечно, сами авторы не забыли это учесть в своей реализации) - вот пример из одной документации.

В комментариях хотелось бы собрать какие вы знаете проекты и их ресурсы, которые способны создать и управлять Pod'ами. А так я уверен, что со временем такого будет появляться все больше и больше.

Как-то это прошло мимо меня, но 2 месяца назад в Istio закрыли забавную, но при этом классическую уязвимость для подобных механизмов (Подобное можно было видеть и в случаях с saml/oauth.), в проверке JWT токена. Суть: "If a JWT token is presented with an issuer that does not match the issuer field specified in JwtProvider, then the request is mistakenly accepted". Подвержена была версия 1.17, а более младшие версии нет (1.16 и младше). Уязвимость получила идентификатор CVE-2021-21378 и высокий CVSS рейтинг 8.2 CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N.

P.S. Не очень понятно почему авторы во всех переписках это публикуют как "fix for zero day"... Может они видели использование данной уязвимости в реальном мире ?!

Сегодня с 10:00 CEST стартует KubeCon + CloudNativeCon Europe 2021 и продлится до 7 мая включительно. Полное расписание можно посмотреть тут.

А завтра будет специальная секция Cloud Native Security Day от CNCF - программу этой секции можно посмотреть тут. Там, как всегда, много всего интересного (будет даже CTF), но этого не значит, что в остальные дни на конференции нет докладов затрагивающий тему безопасности.

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

Совсем недавно компания Google на одной из страниц своей официальной документации опубликовала/обновила раздел "Compare AWS and Azure services to Google Cloud". То есть она сопоставила свои облачные сервисы с сервисами своих основных конкурентов. Это может быть полезно как при выборе облачного провайдера, так и при миграции из одного в другой или при создании Multi-cloud.
Отдельно стоит обратить внимание (применить фильтр) на следующие моменты:
- "No equivalent alternative" - так как таблица строится от сервисов Google, то это свойственно только конкурентам. Так что у конкурентов тоже могут быть сервисы, которым нет альтернативы в Google.
- "Security" - быстро посмотреть, что позиционируется как механизм безопасности
- "Kubernetes" - быстро посмотреть, что на прямую связывают с k8s

До этого я встречал только вот такое сравнение "Mapping of On-Premises Security Controls vs. Major Cloud Providers Services" (не со всеми пунктами я там согласен) для решений ON-PREMISES, AWS, AZURE, GOOGLE, ORACLE, IBM и ALIBABA.

Определенно было бы здорово иметь подобное сопоставление/сравнение и с участием российских облачных провайдеров.

https://doc.crds.dev/ - очень удобный online сервис по работе с CRD (Custom Resource Definition). Он очень прост и полезен в использовании - достаточно вбить только github адрес проекта, CRD которого вас интересуют. А далее проект самостоятельно выделит версии проекта и для каждой из них имеющийся там набор CRD с описанием. По сути, это такая автоматическая генерилка документации на CRD сторонних проектов.

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

ELF внутри YAML ресурса Pod или x86 assembler внутри ConfigMap ?) Вот такие кейсы [1,2] можно найти на просторах сети... И при этом это также может использовать атакующий, но уже не в ваших интересах.

Вот и прошел KubeCon + CloudNativeCon Europe 2021 - на нем было много интересного и полезного. Мы обязательно отдельно рассмотрим доклады, что затрагивали тему security, а их было прям предостаточно. Но уже сейчас большинство слайдов докладов доступно на сайте, внутри расписания: основная программа и Cloud Native Security Day.

Сегодня речь пойдет об атаке Terminal escape injection в сервисе AWS CloudShell, обнаруженной командой Google Project Zero в феврале 2021 года.
Суть уязвимости в возможности RCE, из-за ошибки компонента библиотеки aceterm, приводящей к некорректной обработке последовательности символов xterm rewrite терминала javanoscript, при использовании AWS CloudShell. Это может привести к возможности удаленного выполнения кода на EC2 серверах, доступ к которым осуществлялся с помощью консоли CloudShell.

Сервис AWS CloudShell предоставляет возможность доступа к терминалу сервера любых сервисов на AWS c помощью браузера, прямо из веб интерфейса консоли управления AWS.

Поскольку AWS CloudShell имеет полный доступ к учетным данным, используемым для входа в веб интерфейс консоли управления AWS,
успешная эксплуатация данной уязвимости могла бы дать злоумышленнику очень мощную точку входа в инфраструктуру AWS, включая сервисы managed k8s: EKS, ESC. Уязвимость была опубликована в рамках сроков responsible disclosure и в настоящее время устранена.

PS: Примечательно, что 2 года назад такой же баг, приводящий к RCE (CVE-2019-0542) был найден в аналогичном сервисе Azure Cloud Shell/VSCode.

Сегодня открою "страшную" тайну хорошо известную в "узких" кругах о Falco - он легко обходится и трудно настраивается. Но обо всем по порядку:
1) Если вы используете Falco, то срочно обновитесь до последней версии 0.28.1
2) В данной версии закрыли несколько Security Advisories уровня critical и high
3) Сritical позволяла незаметно уронить модуль и отключить Falco
4) High говорит о множественных обходах default правил из falco_rules.yaml (закрыто не все)
5) Об этом всем известно в открытом доступе уже 17 месяцев
6) Все это доступно вместе с PoC из стороннего публичного аудита безопасности опубликованного в репозитории Falco

Также аудиторы отмечают сложность написания хороших правил, а разработчики отмечают необходимость кастомизации default правил во избежание обходов.

Запомните: Правила, созданные человеком, хороши ровно на столько на сколько хорошо их автор знает систему в конкретный момент создания правила. А ОС Linux совсем не простая ОС + ваши микросервисы развиваются ...

Во время последнего KubeCon + CloudNativeCon Europe 2021 была опубликована первая версия Cloud Native Glossary. Если вы или ваши коллеги только начинаете свой путь в Cloud Native мир, то это будет хорошей отправной точкой, чтобы получить общее представление о базовых терминах и определениях.

В первой версии 25 терминов (список будет расширяться) в 3-х категориях:
1) technology
2) property
3) concept

При описании каждой technology объясняют, что это такое, зачем это надо и как помогает. От сюда вы узнаете и что такое Kubernetes и что такое DevOps c DevSecOps и многое другое ;)

Компания Amazon опубликовала серию постов "Policy-based countermeasures for Kubernetes" [1,2].
По сути, это свежий (от 31 марта 2021) обзор и сравнение policy engines, который поможет вам выбрать наиболее подходящий для вашей компании. Среди рассматриваемых кандидатов:
- OPA
- Gatekeeper
- MagTape
- Kyverno
- k-rail

К сожалению, на момент публикации Kubewarden еще не был выпущен, и он тут не рассматривается.

Все решения описываются по следующим пунктам:
1) Создание политик
2) Реакция на недоступность webhook (fail open vs. fail closed)
3) Возможность фонового сканирования
4) Расширяемость кода и данных
5) Архитектура и развитие используемых политик
6) Возможность работы вне Kubernetes кластера (встраивание в CI\CD)

Материал просто MUST READ, а policy engine уже должен быть неотъемлемой частью вашего Kubernetes кластера!