Мощный лонгрид "User and workload identities in Kubernetes" посвящённый AuthN (на самом деле это 4 статья из цикла). Помимо более-менее очевидных моментов что кочуют из статьи в статью про аутентификацию в Kubernetes - типа: внутренние и внешние субъекты, различные стратегии аутентификации (static token, bearer token, X509 certificate, OIDC и т.д.), назначение и роль Service Accounts и подобное.

В данной статье есть очень классный момент про работу Service Accounts и Secret до версии 1.24 и начиная с нее. Если вы об этом не знали, то тут появляется значительное отличие по работе. Если раньше при создании Service Accounts для него Secret с token создавался автоматически, то теперь этого не происходит (но можно вернуть прежнее поведении через специальную annotations - читайте в этой же статье). С версии 1.24 желаемый token монтируется в Pod автоматически как projected volume и имеет срок действия (чего не было раньше)!

Из статьи "Governing Multi-Tenant Kubernetes Clusters with Kyverno" можно узнать и на примерах посмотреть, как Kyverno ловко управляется в сценариях, где требуется:
- Validate
- Mutate
- Generate

Приведены не тривиальные примеры на каждый из кейсов:
1) Validate Resources: Убедится, что Ingress HTTP Rule Paths уникальны для каждого хоста.
2) Mutate Resources: установить timeoutSeconds для readinessProbe в Deployment, где они не проставлены.
3) Generate Resources: создать VerticalPodAutoscaler ресурс для определенных Deployment.

Многие ошибочно думают, что Policy Engines это инструменты только отдела ИБ, но это совсем не так! С помощью данного класса инструментов можно решать задачи и Dev и Sec и Ops департаментов и все в декларативной манере ;)

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

Я тут более менее определился с мероприятиями, где представлю новые доклады про Kubernetes и рад сегодня с вами этим поделиться. И так:

- OFFZONE 2022 (Москва), 25-26 августа, "Безопасность Kubernetes: Фаза Deception" - рассмотрим ловушки для злоумышленников в Kubernetes на базе его механизмов и не только.
- KazHackStan 2022 (Казахстан, г.Алматы), 14-16 сентября, "Специфика расследования инцидентов в контейнерах" - в данном докладе рассмотрим какая есть специфика, которая ряд моментов делает более сложными, а некоторые более простыми.
- Kazan Digital Week 2022 (Казань), 21-24 сентября, поучаствую в круглом столе об облаках.
- HighLoad++ 2022 (Москва), 24-25 ноября, (CFP комитет еще рассматривает заявку) "Сочетание несочетаемого в Kubernetes: удобство, производительность, безопасность" — как ИТ и ИБ в кластере Kubernetes могут сразу делать и оптимально, и удобно и при этом безопасно. И все живут мирно и дружно!

Буду рад со всеми встретится и пообщаться!

При этом есть 2 интересных/полезных момента:
1) В рамках OFFZONE есть AppSec.Zone и тут мои хорошие знакомые еще ищут докладчиков - есть шанс залететь туда и поделится своим опытом, исследованием ;)
2) Также я хочу разыграть 1 билет на OFFZONE и для того чтобы его выиграть необходимо в комментариях к этому посту предложить тему исследования в области безопасности Kubernetes, которая вам интересна/полезна и вы бы с удовольствием ее послушали ;)

Небольшая заметка "Fun with Capabilities", которая в первую очередь будет полезна атакующей стороне. Из нее можно узнать занимательную информацию про Capabilities при использовании контейнеров, а именно:
1) Using File Capabilities when you’re not root - тут мы получаем ответ на вопрос "Можно ли использовать Capabilities, если мы работаем не из под root?". И ответ, да при условии что можно влиять на формирование образа контейнера! Для этого достаточно в Dockerfile установить для нужного бинаря нужные Capabilities и далее просто его использовать.

RUN setcap 'cap_net_raw,cap_net_bind_service,cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap=+ep' /bin/busybox

2) Moving files with Capabilities - нужно учитывать что по умолчанию при копировании таких бинарей с Capabilities, они сами не копируются и это надо делать специальным способом. Можно использовать tar с флагом --xattrs и при распаковке флаг --xattrs-include='security.*'!

Правда для этого потребуется определенная реализация tar и root права ...

P.S. Результаты конкурса объявлю завтра, так что есть время поучаствовать ;)

На сегодняшний день существует 4 способа работы с внешними хранилками секретов в Kubernetes:
1) Direct API - тоесть приложение самостоятельно при помощи SDK лезет куда нужно. Используется pull модель.
2) Controller - специализированный Kubernetes operator, который берет и зеркалит секреты из внешних систем в классический Secret в Kubernetes. Проект типа External Secrets Operator. Используется push модель.
3) Sidecar + MutatingWebhook - проект типа Vault Agent Sidecar Injector. Используется pull модель.
4) Secrets Store CSI Driver - проект от сообщества Kubernetes, выполненного в виде DaemonSet и нескольких CustomResources. Используется push и pull модель на выбор.

Последний герой появился недавно/последним и позволяет интегрировать хранилища секретов внутрь Kubernetes как CSI volume. На сегодняшний день есть поддержка:
- Azure Key Vault
- AWS Secrets Manager
- Google Secret Manager
- HashCorp Vault

Для подробного знакомства с ним рекомендую ознакомится с официальной документацией и видео "Secrets Store CSI Driver: Bringing external secrets in house".

Наша исследовательская команда Luntry (в лице Сергея Канибора) недавно решила проверить две атакующих техники в Kubernetes, которые можно встретить в разных статьях, презентациях и даже книгах. Проверить с той целью насколько они рабочие на сегодняшний день в последних версиях Kubernetes (взяли для тестов 1.24).

1) Обход Kubernetes Audit Log за счет добавления к Kubernetes Resources очень большой/длинной annotations. Ввиду данной манипуляции по идее в Log попадет далеко не вся информация о действии с данным ресурсом.

Как итог, воспроизвести это не удалось - система выдает: The Pod "nginx" is invalid: metadata.annotations: Too long: must have at most 262144 bytes

2) Обход Admission Controllers (тех же Policy Engines) за счет создания StaticPod в несуществующем namespace. Ввиду этого Pod создается на Node, через kubelet, а Kubernetes API о нем не узнает.

Как итог, воспроизвести это не удалось - система выдает: Aug 01 16:49:02 gimme-4b0b886b-1 kubelet[13744]: E0801 16:49:02.151102 13744 kuberuntime_sandbox.go:70] "Failed to create sandbox for pod" err="rpc error: code = Unknown desc = failed to setup network for sandbox \"4efe71bddeb0a918968168c1f2579b2638a115df0667c4430b1711b5fd2d6b27\": namespaces \"test\" not found" pod="test/priv-exec-pod-gimme-4b0b886b-1"

Как мы видим`Kubernetes` активно развивается и многие моменты там быстро устаревают.

P.S. Вы можете задаться вопросом а в каких версиях это работает?! Но я бы рекомендовал не тянуть с обновлениями кластеров ;)

Похоже что нас ждут большие изменения по работе seccomp в Kubernetes 1.25. Как минимум уже известно:

1) SeccompDefault feature переходит в статус beta (с версии 1.22 он был в alpha )! Еще один шажок к тому чтобы запускать все workloads с дефолтным seccomp профилем, если он не определен.
2) В связи с этим частично уберут seccomp annotations из-за ненадобности.

P.S. Оценили как можно смотреть документацию на версию 1.25, которая еще не выпущена? ;)

Почти 4 месяца назад был гостем подкаста "Битовая каска" и как-то забыл этим с вами поделиться - исправляюсь ;)

Выпуск 36: Дмитрий Евдокимов про безопасность приложений, девсекопс и инженеров-пентестеров

Отличный доклад "Харденинг K8S. (Не)очевидные настройки" от моего хорошего товарища поможет правильно посмотреть на CIS Kubernetes Benchmarks.

Очень важно помнить, что не стоит слепо следовать всем требованиям любого Benchmark. Ко всему стоит подходить с чувством, с толком, с расстановкой. Обычно относительно CIS Kubernetes Benchmarks, специалисты изучают его, накладывают на свою инфраструктуру и оставляют 10-20 значимых пунктов и их контролируют, а не слепо добиваются 100% покрытия его. Хорошо это еще все сразу заложить и проверять на стадии IaC, чтобы не пересканитивать это постоянно (особенно с учетом Container-Optimized OS).

Если вы только делаете первые шаги в аудите, пентесте Kubernetes или во все готовитесь к CTF, где его можно встретить, то в рамках проекта HackTricks (выполненного как большая база знаний) есть раздел Kubernetes Security и там все достаточно хорошо задокументировано по этому направлению.

Про подобное я уже писал тут в рамках проекта PayloadAllTheThings - так рекомендую к изучению ;)

Только пожалуйста не будьте noscript kiddie - всегда разбирайтесь и понимайте что, как и почему работает!

Давненько ничего не было про хардкорные ядерные уязвимости, которые могут позволить осуществить побег из контейнера (container escape), и при этом не в каком-то плохо настроенном окружении, а в серьезно защищенном, типа kCTF [1,2] ;)

Ранее на канале я писал про:
- CVE-2021-22555
- CVE-2022-0185

А сегодня речь про CVE-2022-29582 - Use-After-Free уязвимость в io_uring (v5.10 - v5.12).

В статье рассматривается окружение в виде захардеренного nsjail на Google’s container optimized OS (COS) дистрибутиве. Эксплоит не требует unprivileged user namespaces, а в результате предоставляет root privileges в root namespace.

vulnscan - сканер уязвимостей, базирующийся на syft (создает SBOM) и grype (сканирует SBOM на известные уязвимости), работающий в Kubernetes (runtime сканирование). Результаты хранит в БД Postgres, в наличие простенький UI и есть возможность "ignore list" для результатов сканирования (малюсенький зачаток vaulnerability managment).

Алгоритм работы:
- Запрашивает все Pods в кластере
- Для тех Pods, что еще не создан SBOM- создает SBOM
- Сканирует SBOM на известные уязвимости

Из последних сканеров он похож KubeClarity и Kubei, но уступает как по мне обоим.

Тема сегодняшнего поста это Threat Modeling для Kubernetes методом STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege).

Занимался кто?)

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

Но, одни добрые ребята, взяли и позволили это дело значительно упростить!

В итоге процесс выглядит следующим образом:
1) Скачиваем Microsoft Threat Modeling Tool (MS-TMT)
2) Скачиваем шаблон для этой MS-TMT для поддержки k8s (его как раз ребята и написали и выложили в открытый доступ)
3) Начинаем из разных предоставленных субъектов и объектов рисовать в MS-TMT свою диаграмму взаимодействий между разными ними и обозначать границы доверия (а может у вас ZeroTrust).
4) Далее система сама эта проанализирует и сгенерирует отчет с обнаруженными угрозами по STRIDE.
5) Занимаемся анализом угроз в MS-TMT - отмечаем как: требует исследования, не применима или уже имеет тако-то митигейшен.

На прошлой неделе в Las Vegas прошла самая известная конференция в области технической безопасности - BlackHat USA 2022. И в этом году она нас порадовала одним докладом по безопасности Kubernetes - "Kubernetes Privilege Escalation: Container Escape == Cluster Admin?" (слайды).

И по сути это доклад на основе исследования "Kubernetes Privilege Escalation: Excessive Permissions in Popular Platforms" о котором я писал ранее тут. Но слайды все равно посмотреть стоит - многие моменты там раскрыты лучше и понятнее из-за их графического представления.

На пример, там классно продемонстрирован сценарий поднятия привилегий до Cluster Admin в кластерах с CNI Cilium (стоит обновиться!), который состоит из 3 шагов после попадания на Node:
1) Скедулим cilium-operator на подконтрольную Node
2) Получаем мощный Service Account token от cilium-operator
3) Проводим эскалацию прав, добавив себе полные права

Мини бог пост "Auditing RBAC - Redux" про сложности аудита Kubernetes RBAC с хорошим перечнем OpenSource инструментов для данной задачи:
- rbac-tool
- Kubiscan
- krane
- RBAC Police

Тема действительно не простая при кажущейся простоте, особенно когда дело касается больших, сложных, быстро развивающихся систем при процессном подходе, а не простом запуске тулов. Говорю это не понаслышке - сейчас мы делаем модуль аудита RBAC в нашем Luntry и сталкиваемся со многими нюансами. Но задача интересная в чем то даже творческая - сейчас сделали базу об опасных правах и на текущий момент она содержит 33 правила, помимо возможности создавать свои правила (включая для CustomResources).

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

- Про аудиторию канала
- Про PolicyEngine
- Про используемые типы Kubernetes
- Про реализации Multi-Tenancy
- Про securityContext.capabilities.drop.all
- Про distroless образы
- Про immutable OS
- Про autoMountServiceAccountToken: false
- Про безопасность использования образов (еще идет)

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

Цель данного поста: В комментариях к данному посту можно предложить свои опросы (с вариантами ответов на ваш взгляд) , которые можно было бы провести на канале. И наиболее интересные на мой взгляд будут опубликованы =)

Я уже рассказывал, что в недрах CNCF было разработано 3 модели/решения для организации Multi-Tenant в Kubernetes. Но это не значит, что нет других инструментов помогающих достичь этого.

Встречайте Capsule - multi-tenancy и policy-based фреймворк для Kubernetes.

По факту это Kubernetes Operator c Custom Resource (Tenant, CapsuleConfiguration) и MutatingWebhook и ValidatingWebhook. В ресурсе Tenant прописываются все возможности и ограничения, которые затем накладываются на ту группу namespaces, которые там будут созданы и ресурсы внутри них. Внутри данного Tenant пользователи вольны делать, что угодно в рамках заданных ограничений. При это каждый Tenant изолирован от других: Network и Security Policies, Resource Quota, Limit Ranges, RBAC и другие политики служат ограничениями на уровне Tenant и автоматически наследуются всеми namespaces в рамках Tenant.

Отдельного внимание заслуживает соответствие данного решения требованиям Multi-Tenancy Benchmark!

P.S. В комментариях можете спрашивать любые вопросы по данному проекту и на них ответит один из основных мейнтейнеров проекта ;)

Совсем скоро уже выйдет Kubernetes 1.25 и уже сейчас можно присмотреться к новым фичам, изменениям и светлому будущему [1,2,3].

Мы же в первую очередь заострим наше внимание на вещях связанных с security:
1) PodSecurityPolicy (PSP) полностью исчезает из K8s
2) PodSecurity admission (замена PSP) переходит в stable и включен по умолчанию
3) Добавление поддержки user namespaces - фича UserNamespacesSupport и новый параметр spec.hostUsers для Pod (вроде как 6 лет к этому шли) 🔥
4) Forensic Container Checkpointing - можно делать snapshot запущенного контейнера и потом проанализировать его на другой машине незаметно для атакующего 🔥
5) Оптимизации по работе с SELinux
6) Добавление поля SecretRef к запросу NodeExpandVolume
7) Улучшение CVE feed - добавили official-cve-feed label, по которому просто искать и фильтровать
8) Поддержка диапазона портов в классической NetworkPolicy перешла в stable
9) Ephemeral Containers перешли в статус stable
10) Поддержка cgroup v2 перешла в stable 🔥

P.S. Это и хорошее обновление для моего тренинга =)

Если вы не понимаете и путаетесь чем отличаются и для чего нужны External Secrets Operator и Secret Storage CSI а вопрос как работать с внешними хранилками секретов вам не дает покоя, то статья "Comparing External Secrets Operator with Secret Storage CSI as Kubernetes External Secrets is Deprecated" как раз для вас! Из нее вы узнаете:
- Отличия в архитектуре
- Отличия в функциональных возможностях

А чему вы отдаете свое предпочтение?

Сегодня на повестке статья "Как организовать мультитенантность в кластерах Kubernetes".

В данной статье автор делится своим опытом об основных подходах, плюсах и минусах разных вариантов реализации Multitenancy в Kubernetes и как они с командой пришли к собственному решению. Из статьи вы узнаете:
- Что такое Multitenancy
- Чем хорошо и плохи отдельные кластера
- Нативная мультитенантность на базе Namespaces, где берем и крутим: RBAC, NetworkPolicy, ResourceQuota, PriorityClasses, LimitRange, sandbox/microvm, Taints/Tolerations или Node Affinity, PodSecurityStandart
- Возможности такой примочки как Hierarchical Namespace Controller (HNC)
- Проект Capsule, о котором уже недавно писали на канале
- Ресурс Project из проекта Rancher

В продолжении должно быть к чему пришла команда автора и кажется это будет базироваться на Control-planes-as-a-Service ;) Также больше информации будет в докладе в предстоящем докладе "Multi-tenant Kubernetes".