Тема сегодняшнего поста это 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".

Тема eBPF продолжает будоражить умы как защитников, так и атакующих! На конференции BlackHat USA 2022 были представлены доклады на интересы одних и других:
1) "Return to Sender - Detecting Kernel Exploits with eBPF" - для защитников будет полезно узнать как на базе eBPF можно бороться с эксплотацией ядерных уязвимостей в ядре Linux. Автор даже зарелизил инструмент - Kernel Runtime Integrity with eBPF (KRIe). Но по результатам всего этого автор приходит к выводу:"eBPF is not really the ideal technology to detect kernel exploits" Об таком же выводе я уже писал тут.
2) "eBPF ELFs JMPing Through the Windows" - для атакующих в этой презе можно посмотреть как поддержка eBPF в Windows расширяет attack surface и что там можно нафазить ;) А так вообще полезно посмотреть чем и как отличается eBPF в Linux и Windows.

P.S. eBPF Summit SEPTEMBER 28-29, 2022

Вышел Kubernetes 1.25 с новым лого и кодовым названием - Combiner! О самых интересных на мой взгляд нововведениях в безопасности - я уже писал тут.

Занимательный детектив "Who’s at the Helm?" или "Or, how to deploy 25+ CVEs to prod in one command!" - я думаю, что общий посыл понятен прям из названия! И да речь тут пойдет об open source supply-chain management.

Автор берет один Helm chart (в его случае это kube-prometheus-stack) и пытается разобраться, что реально появляется/ставится в его инфраструктуре и откуда и как это вообще было собрано. Есть там классный момент как автор пытается определить что за base image использовался при создании определенного образа - там идет почти reverse engineer с параллельными прыжками в ArtifactHub, GitHub, DockerHub, Quay =)

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

PS Сегодня в Москве - выступаю на OFFZONE 2022.

Я как разработчик решения под Kubernetes очень люблю низкоуровневые материалы о нем, когда люди прямо лезут в его "кишки" и начинают с ними разбираться, оптимизировать, улучшать и т. д. Одно из подобных работ является статья "Scaling Kubernetes to Thousands of CRDs". Уже сегодня невозможно представить Kubernetes продакшен кластер без сторонних Kubernetes operators с их Custom Resources и с каждым годом появляется все больше таких проектов: от security до Chaos engineering. И естественно рано или поздно можно упереться в тот или иной лимит при работе с Custom Resource Definition (CRD). И вот с чем столкнулись в данном вопросе и как решали и идет речь в данной статье от авторов Crossplane.

А что вы можете посоветовать такого почитать низкоуровневого про работу Kubernetes? Может быть, у вас есть какая-то любимая статья в таком духе?

Две очень короткие и хорошие заметки на смежные темы в официальном блоге Kubernetes:
1) PodSecurityPolicy: The Historical Context - в общем про становление и падение PSP
2) Kubernetes v1.25: Pod Security Admission Controller in Stable - про то что появилось/изменилось со времен статуса Beta

P.S. Обратите внимание, что сервис container registry куба переехал с k8s.gcr.io на registry.k8s.io! Некоторое время они будут работать одновременно.

Книга "Zero Trust Container Security for Dummies"

Цитата: "Zero Trust security takes a proactive approach to security. Instead of relying on reactive, signature-based protections, Zero Trust security is based on a declarative model in which you define acceptable behavior and block everything else. Allow lists are highly pronoscriptive and minimize the attack surface."

В этой мини книге (50стр) вы найдете хорошую теорию по ZeroTrust для контейнеров и рекламу решений SUSE.

kubectl-execws - утилита на Go, которая по сути является заменой kubectl exec, которая работает через WebSocket. Тоесть весь kubectl не нужен. При этом данная утилита может обходить Kubernetes API server (привет Kubernetes Audit Log!), благодаря прямому соединению с kubelet API, работающим на Nodes. Инструмент будет больше полезен для атакующих целей (привет сигнатуры на kubectl!).

P.S. Как работает kubectl exec можно узнать/вспомнить тут.

Всех поздравляю с 1 сентября! С Днем Знаний!

И хотел бы сегодня поделиться знанием, почему наше решение по безопасности для Kubernetes называется Luntry ("Лантри"). Хотя некоторые нас порой называют "Люнтри" и как вы увидите дальше это в принципе тоже верно.

И так, Luntry ("Лантри") это выдуманное слово, образованное от французского слова "Lune" (Люн), что в переводе значит Луна. Так что "Люнтри" это можно сказать произношение на французский манер =)

Почему Луна?
1) Как и многое в теме контейнеров и Kubernetes ("Штурвал") мы пошли от морской темы. Луна является для моряков спутником, светилом, ориентиром в темное время. Мы также являемся для пользователей Kubernetes – показываем и подсказываем что, где и как работает (плохо/хорошо/опасно/безопасно).
2) Обратная сторона Луны — часть лунной поверхности, которая не видна с Земли. И Лантри как возможность эту сторону увидеть, понять и контролировать ;)
3) Альбом "The Dark Side of the Moon" группы Pink Floyd никакого отношения к названию не имеет, но в легенду ложиться просто супер ;)

P.S. Интересно ли вообще информация о внутренней кухне, о разработке или лучше чисто писать про безопасность Kubernetes?

Сегодня хочу поделиться своими мыслями и наблюдениями (на наших клиентах) на тему NetworkPolicy (хотя это применимо не только к ним) и работе/поддержке/сопровождению их - по-модному Day 2.

Многие думают, что, написав или сгенерировав ресурс NetworkPolicy для микросервисов, дело сделано, но по факту все только начинается ... Теперь становится нужно контролировать что:
1) политики применились к чему нужно и не более
2) политики находятся в актуальном состоянии и вовремя обновляются
3) политики не отвалились ввиду изменений в микросервисах
4) все ваши департаменты в курсе того какой микросервис как ограничен
5) все ваши процессы учитывают наличие политик

Опять же повторюсь это применимо не только к NetworkPolicy и становится очень заметно, когда у вас в кластере не пара десятков микросервисов.

Ко мне самому осознание этого пришло не сразу, а в процессе, когда мы делали соответствующую функциональность, помогающему клиенту решить эти проблемы в момент, когда количество его NetworkPolicy сильно перевалило за сотню.

Так что если вы только на пути к NetworkPolicy - не забывайте о том, как вы будете с ними жить в Day 2 ;)

В официальной документации Kubernetes появился раздел Security Checklist. Он состоит из самых базовых рекомендаций по аспектам:
- Authentication & Authorization
- Network security
- Pod security
- Enabling Seccomp
- Enabling AppArmor or SELinux
- Pod placement
- Secrets
- Images
- Admission controllers

Отдельно обратите внимание на предупреждение в начале раздела, чтобы у вас не сформировалось ложного представления об этом checklist'е!

P.S. На канале публиковались и другие подобные чеклисты [1,2] ;)

Если вы до сих пор задаетесь вопросом что такое Distroless Images, то крутецкая статья "What's Inside Of a Distroless Image - Taking a Deeper Look" даст вам ответ на этот вопрос и посмотреть еще глубже, что у них там под капотом! Краткое содержание:
- Сложности работы с scratch containers
- Вариант distroless/static и его специфика
- Вариант distroless/base и его специфика
- Вариант distroless/cc и его специфика
- Вариант для interpreted или VM-based languages
- Общая оценка использования distroless images
- Классная подборка дополнительных материалов по теме

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

Так что после прочтения статьи вы поймете что distroless images бывают разные =)

Сточки зрения ИБ я повторюсь [1,2,3,4], что это позволяет уменьшить attack surface, усложнить закрепление атакующему, снизить шум от сканеров известных уязвимостей, тоесть вещь MUST HAVE!

P.S. Результату голосования по данной теме тут.