Статья "PodSecurityPolicy Deprecation: Past, Present, and Future".

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

Краткая выжимка:
- PodSecurityPolicy (PSP) перейдет в статус deprecated в версии 1.21
- Alpha релиз замены должен состояться в версии 1.22
-Старая версия будет удалена скорее всего в версии 1.25
- Разрабатывается замена для покрытия ключевых потребностей
- Изменения связанные с PSP никаким образом не повлияют на PodSecurityContext
- Основная причина отказа от текущей реализации – не удобство в использовании
- K-Rail, Kyverno и OPA/Gatekeeper это хорошо, но надо иметь простую, гибкую и встроенную реализацию
- За разработкой замены можно следить в Kubernetes Enhancement Proposal (KEP 2579)

Для тех, кто занимается обеспечением надежности (reliability) работы своих сервисов следующие метрики точно знакомы:
- MTTF - mean time to failure (среднего времени до отказа)
- MTBF - mean time between failures (среднего времени между отказами)
- MTTD - mean time to detect (когда проблема уже присутствовала, но о ней еще не было известно)
- MTTR - mean time to repair/recover/resolve/response (среднее время, необходимое на восстановление работоспособности системы после получения сигнала о сбое.)

Возвращаясь к тому, что reliability и security вещи не разделимы, то эти же метрики можно совершенно успешно использовать и в security для работы с инцидентами безопасности. Так, на пример, MTTD + MTTR = это общая продолжительность инцидента информационной безопасности.

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

Сегодня поговорим про Workload Identity в GKE
Очень часто в managed Kubernetes нам приходится работать с managed базами и другими облачными ресурсами. Для аутентификации в них у каждого облака есть IAM и ServiceAccount'ы, которые позволяют гибко настроить доступы. В общем случае чтобы получить токен от ServiceAccount'а нужно обратится в Metadata API c инстанса, ServiceAccount задается для каждого Compute instance.

Минусы такого подхода для Kubernetes:
- из-за того, что на одной ноде могут быть разные поды и нагрузки, приходится выдавать больше привилегий ServiceAccount'у
- из-за миграций нагрузок по нодам, приходится выдавать всем нодам одинаковый ServiceAccount
В итоге данное решение не очень гибко и противоречит least privilege principle.
Альтернативно, можно хранить ключи от ServiceAccount'ов в Kubernetes Secrets, но тогда необходимо самому задумываться о ротации ключей.

Тут нам на помощь приходит Workload Identity
Эта фича позволяет Kubernetes ServiceAccount'ам аутентифицироваться за Cloud ServiceAccount. Таким образом, пропадает зависимость от Compute ServiceAccount, и решаются вышеописанные проблемы.
В GKE Autopilot (о котором мы писали ранее) эта опция включена по дефолту. Технически это реализовано через перехват запросов к Metadata API, в кластер добавляется DaemonSet с соответствующим функционалом.

Вердикт - must have для тех, кто работает с облаком из GKE. Более того, данный инструмент может оказаться удобнее, чем альтернативные методы.

Некоторое время назад наткнулся на упоминание документа (о котором раньше никогда не слышал) "A Master’s Guide To Container Securing" по безопасности контейнеров. Если вы себя считаете настоящим контейнероводом или специалистом по их безопасности, то обязательно к изучению. После вы сможете поддержать обсуждение о любых контейнерах.

CDK - container penetration toolkit, offering stable exploitation in cloud-native docker/k8s/serverless deployments.

Инструмент будет презентован:
- 6 мая на BlackHat Asia 2021 на докладе "CDK: Zero Dependency Container Penetration Toolkit"
- 27 мая на HITB Amsterdam на докладе "Attacking Cloud Native Kubernetes with CDK"

Это набор сетевых тулов, PoC'ов и эксплоитов для побега из контейнеров и захвата Kubernetes кластера. Есть 3 основных модуля:
- Сбор информации - 12 тактик по Information Gathering (9) и Discovery (3)
- Запуск эксплоитов - 21 тактика по Escaping (11), Remote Control (1), Credential Access (3), Privilege Escalation (1), Persistence (5)
- Запуск дополнительных инструментов (8)

+ режим auto-escape для автоматического побега из контейнеров.

При этом также есть несколько версий: all, normal, thin, upx. Так thin оптимизирована для работы в контейнерах с коротким жизненном циклом (на пример в Serverless), upx помогает обходить сигнатурные средства защиты.

Сегодня рассмотрим opensource boilerplate для создания базовой инфраструктуры EKS-кластера и вспомогательных сервисов в облаке AWS от MadDevs. С точки зрения архитектуры, решение представляет собой VPC из 3-eх публичных подсетей для ресурсов k8s, которые должны быть доступны из интернета, 3 приватные подсети с доступом к интернету через Nat Gateway и 3 приватные подсети для RDS развернутые в 3-ех availability zones для обеспечения redandency.

В качестве точки входа в k8s используется сервис Elastic load balancing (ELB) за VPC Internet gateway. В шаблоне также используется: сервис Route53 для управления DNS, Cloudwatch - для мониторинга работы ресурсов, AWS Certificate manager - для управления сертификатами, ECR - для хранения docker образов и SSM Parameter Store - для хранения секретов и конфигураций. Для развертывания инфраструктуры и сервисов используется terraform. Стоимость ресурсов, которые разворачиваются в облаке AWS при дефолтной конфигурации этого шаблона составляет $217/мес. без учета стоимости трафика. Решение актуально, для тех кто хочет развернуть k8s на Amazon по-быстрому, например для тестов, без необходимости вникать в детали и тонкости настройки сопутствующих сервисов этого облачного провайдера. Если же хочется потестить бесплатно, то рекомендуем обратить внимание на EKS distro на собственной инфраструктуре.

С точки зрения безопасности все относительно неплохо, при условии что IAM-политики и правила Security groups сервисов грамотно настроены самостоятельно. И в качестве пожелания для разработчиков решения, добавить в дефолтную конфигурацию использование AWS Secret Manager вместо SSM Parameter Store для хранения секретов в зашифрованном виде.

Аудит Helm 3. В начале 2021 года под эгидой CNCF опубликовали результаты второго 3rd party security audit, но уже для Helm 3.3.0-rc.1. В рамках данной работы был проверен анализ исходного кода клиентской части и составлена модель угроз (Threat Model) при использовании Helm. Про прошлый можно почитать здесь.

Команда: 2 консультанта, 3 человеко-недели.

Найдено проблем: 3 Medium, 7 Low, 3 Info. Проблемы исправлены в версии 3.3.2.

Модель угроз вы можете наблюдать на скриншоте.

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

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

CVE-2021-25735: Validating Admission Webhook does not observe some previous fields

Уровень критичности Medium (CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:H)

Уязвимость находится в kube-apiserver и позволяет при обновлении Node атакующему обойти Validating Admission Webhook

Под влиянием только сторонние validating admission plugins, встроенный NodeRestriction работает как полагается.

Сегодня поговорим о reliability (надежности) в Kubernetes. Ведь когда случается какой-то сбой нельзя мгновенно, однозначно сказать из-за чего он произошёл. Это может быть как внешний нарушитель (DoS решил устроить), так проблемы ПО внутри самого кластера.

Все, кто стараются максимально использовать возможности Kubernetes пытаются как можно больше задач возложить на ПО - они и есть не просят, и работают 24/7. Вот тут и приходят операторы и CRD.

В рамках доклада "Тестирование Kubernetes оператора" докладчик выделяет 3 основных последствия неправильной работы оператора:
- The Infinite Pod Loop Creation
- The Split Brain Situation
- The Double Rolling Upgrade Reaction

Об этих ситуациях соответствующий момент по timecode.

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

В этой заметке речь пойдет о рисках полной или частичной компрометации EKS кластера, а в особо запущенных случаях и всего аккаунта AWS, с помощью эксплуатации SSRF (Server Side Request Forgery) уязвимого веб приложения, с использованием сервиса Instance Metadata (IMDSv1). Для начала несколько слов о самом сервисе метаданных, основной задачей которого является предоставление информации о конфигурации сервисов, включая IAM credentials, настройки Security-groups и пр. Сервис IMDS доступен только по не маршрутизируемому (link local) адресу 169.254.169.254 по умолчанию из любого контейнера/пода кластера AWS EKS.

Предположим, что в одном из подов развернуто веб приложение уязвимое к SSRF атаке, успешная эксплуатация этой уязвимости предоставляет атакующему возможность обратиться к сервису IMDS, чтобы получить temporary credentials для IAM роли worker ноды, чтобы далее проанализировать конфигурацию IAM политик с целью повышения привилегии. При этом даже если используется настроенная AWS в традициях лучших практик - managed IAM политика EKSWorkerNodePolicy, потенциальный злодей все равно может нанести ущерб, просто удалив все сетевые интерфейсы ec2:DeleteNetworkInterface, нарушив доступность и reliability ресурсов кластера.

Поэтому, единственным возможным решением данной проблемы является переход на использованием новой версии сервиса IMDSv2, реализация которой предполагает наличие session token при обращении к сервису метаданных, что обеспечивает надежную защиту от SSRF атак. Но несмотря на то, что прошел уже почти год с момента, когда AWS анонсировал полную поддержку IMDSv2 в EKS, подавляющие большинство клиентов пока не спешат переходить на использование новой версии сервиса...😢

Чтобы пятница не была будничной - всем владельцам Envoy посвящается 3 remote code execution/DoS уязвимости высокого уровня критичности.

netshoot - a Docker + Kubernetes network trouble-shooting swiss-army container.

Специализированный контейнер для разбирательств с сетевыми проблемами как в контейнерных, так и в хостовых сетевых namespaces. Вряд ли все нужные инструменты будут на месте, а тут они все собраны (49 штук) в одном месте. Также в репозитории есть немного теории о видах и различиях namespaces и use-cases (12 штук) по решение той или иной проблемы с помощью данного набора инструментов.

С другой стороны, смотрю я на этот набор инструментов и понимаю, что почти все что надо для pentest/audit. При этом все легитимное, хорошо известное - не вызывающее подозрение ;) В отличие от того же botty. Тут благодаря scapy так вообще можно создать любой пакет и провести любую сетевую атаку.

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.
- Поддержка политик для всего кластера

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