Запись моего выступления "Container escapes: Kubernetes edition" с секции Defensive Track конференции ZeroNights, что была 30 июня 2021.

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

И небольшой инсайд: в этом году я также планирую представить новое исследование на тему Kubernetes на ZeroNights 2022. На текущий момент это скорее всего будет исследование с рабочим названием "NetworkPolicy: родной межсетевой экран Kubernetes". Посмотрим на то как и что могут NetworkPolicy и как они устроены в различных CNI и куда они развиваются.

Хороший пост "What an SBOM Can Do for You", который все раскладывает по полочкам о текущем состоянии Software Bill of Materials (SBOM), если вы о нем раньше не слышали. Основные разделы:
- What Is Exactly an SBOM?
- The Two SBOM Standards – речь о CycloneDX и SPDX
- The Ultimate Purpose(s) of the SBOM
- Locate and Describe a Software Component
- Automation
- Licensing
- Security
- Status of Tools and Cooperation - отдельно выделю инструменты bom и syft
- The Future: Your Tool Will Be SBOMin’ Soon - особенно круто будет когда SBOM станет частью того же образа контейнера и в любой момент можно понять и проверить содержимое.

О SBOM для Kubernetes я уже писал и всегда можно посмотреть его для последних версий. Также я очень жду, когда кто-нибудь возьмет и напишет Kubernetes operator для генерации SBOM (по аналогии со Starboard) и хранения результатов в Custom Resources (иначе придется это делать самому). Все это полезно будет и для observability и для troubleshooting .

Довольно интересный репозиторий CKS-Exercises на GitHub, который содержит в себе упражнения призванные помочь в подготовке к экзамену на Certified Kubernetes Security Specialist о появлении которого я писал ранее.

В принципе, если вы даже его и не планируете получать, то проглядеть все равно его стоит - среди затрагиваемых тем с примерами:
- Cluster setup
- Cluster Hardening
- System Hardening
- Minimise Microservice Vulnerabilities
- Supply Chain Security
- Monitoring, Logging and Runtime security

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

Недавно довелось поиграться со сканером Kubei, которой состоит из двух частей:
- Сканера уязвимостей в images на базе Grype
- Сканера плохих практик в dokerfiles по CIS Docker Benchmarks на базе Dockle

Главной особенностью данного сканера (как считают авторы) является то, что его не нужно встраивать в CI/CD и никак интегрировать с image registry (все это верно и для Starboard operator). Как он работает:
1) Запускается в Kubernetes
2) Смотрит какие Pods там работают и какие images они используют
3) Создает Jobs, которые порождают Pods, и там производит сканирование

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

НО мне не понравилось, что вот эти сканирующие Jobs он создает в чужих Namespaces, что при условии наличия LimitRange, ResourceQuota может сыграть злую шутку. Поэтому по прежнему лучшей реализацией я считаю Straboard operator - он все делает внутри своего Namespace.

PS Цикл про сканеры.

Один из читателей канала недавно опубликовал (и поделился ссылкой) на эксплоит для нашумевшей уязвимости CVE-2021-25741 в kubelet.

Атакующий должен иметь права на создание Pods. После успешной эксплуатации можно получить доступ к файловой системе Node из Pod с возможностью писать и читать.

Напомню уязвимые версии:
Уязвимые версии:
- v1.22.0 - v1.22.1
- v1.21.0 - v1.21.4
- v1.20.0 - v1.20.10
- <= v1.19.14

Так что для тех, кто еще не обновил свой Kubernetes это дополнительный стимул ;)

Всем хорошей пятницы и выходных!

В белой-белой компании Luntry
Белый-белый хакер Дмитрий Евдокимов (@Qu3b3c)
Пишет прозрачно-белый observability для k8s
В таких условиях легко найти черный код... или не все так чисто?

Детективная история будет разворачиваться прямо у вас в ушах уже в эту cleaning-пятницу в 20:00 на подкасте в DevOps-курилке.
Шерлок Фиделина @fidelina_ru, Хомяк-Холмс @Asgoret и what's up?

Рекомендации: Чтобы следить за ходом расследования желательно подключаться с desktop машинки, так будет виднее)

При поддержке @k8security <—- Дмитрий Белый Евдокимов именно здесь обитает) @devops_ru @devops_jobs
——-

Проект sbom-operator поможет вам собрать все Software Bill of Materials (SBOM) для ваших images в Kubernetes кластере и результат положить в Git.

Очень новый проект, но и очень многообещающий. Под капом у данного Kubernetes оператора проект Syft и библиотека go-containeregistry, которая позволяет скачать нужный образ для анализа с различных реджистри. В официально поддерживаемых:
- ACR (Azure Container Registry)
- ECR (Amazon Elastic Container Registry)
- GAR (Google Artifact Registry)
- GCR (Google Container Registry)
- GHCR (GitHub Container Registry)
- DockerHub

В дальнейшем данную информацию можно использовать и для организации безопасности supply chain и для контроля развития ваших микросервисов (в какой версии какие зависимости каких версий использовались).

Лично мне еще не хватает возможности получения результата работы в виде отдельного Custom resource, ссылающегося по ownerReference на ту же ReplicaSet, чтобы можно было быстро оценить картину на текущий момент.

Если перед вами (как и перед одним из читателей канала) стоит задача переехать с PodSecurityPolicy (PSP) на PolicyEngine, то сегодняшний пост определенно для вас и вам не стоит напоминать, что PSP уходит в прошлое в 1.25 (а его замена PodSecurity Admission Controller вам не близка).

И так ситуация: вы в компании используете PSP и вам надо перебраться с минимальными усилиями на PolicyEngine. Как быть? Делать ли все вручную?!

На помощь спешит проект PodSecurityPolicy Migrator!

Он поддерживает (в разной степени) перевод PSP в политики для:
- Gatekeeper
- Kyverno
- Kubewarden
- k-rail

Помимо CLI реализации проекта, есть и online версия, с которой можно поиграться прямо сейчас.

Также не забывайте, что авторы большинства PolicyEngines уже у себя в репозиториях [1,2,3] сделали базовые политики на базе PSP и вы можете туда также смотреть ;)


P.S. Большое спасибо всем читателям, что делятся своими находками при решение свои задач и проблем!

В официальном блоге Kubernetes появилась запись "Securing Admission Controllers". И посвящена она как нетрудно догадаться безопасности такого важно для Kubernetes механизма как Admission Controllers. На нем базируется, по сути, Kubernetes operators и те же PolicyEngines.

И данная запись на самом деле приурочена к выходу whitepaper под названием "Kubernetes Admission Control Threat Model" от SIG Security. В документе вы найдете:
- Attack Tree - дерево атак, связывающее начальные условия, угрозы, защиты и возможные последствия
- Threat Model - всего выделили 16 угроз.
- Mitigations - 8 штук

Особое внимание обратите на угрозы с ID: 4,6,11,17. При их реализации атакующий сможет:
1) Запустить workload, который по идее уязвимым Admission Controller был бы запрещен
2) Получить доступ к чувствительной информации, с которой работает Admission Controller

Хардкорная блоговая запись "CVE-2022-0185 - Winning a $31337 Bounty after Pwning Ubuntu and Escaping Google's KCTF Containers" еще один прекрасный пример (на ряду с CVE-2021-22555) побега из контейнера через kernel уязвимость хоста в рамках kCTF. Код эксплоита.

Основные моменты:
- Уязвимость позволяет в Kubernetes совершить побег из Pod на Host.
- Уязвимость появилась с 5.1-rc1 в марте 2019.
- Для атаки атакующий должен иметь доступ к контейнеру с CAP_SYS_ADMIN privileges (что само по себе считай побег) или к команде unshare(CLONE_NEWNS|CLONE_NEWUSER), которая даст CAP_SYS_ADMIN privileges в новом user namespace
- SeccompDefault в значении RuntimeDefault благодаря блокировке unshare способен замитигейтить данную багу (и все это только с 1.22)

Как и в прошлый раз я рекомендую: используйте AppArmor/SeLinux/seccomp профили для приложений, а также всегда имейте возможность смотреть что происходит внутри ваших контейнеров - прокачивайте observability.

Статьи по теме от вендоров [1,2].

Одним из самых популярных вопросов на всех форумах по Kubernetes это: "А кто, как ставит Kubernetes?"

Не знаю кто как, но так точно hard way =)

Всех с пятницей и всем хороших выходных!

Чем опасен доступ к nodes/proxy в RBAC?

Именно на этот вопрос исследователи дают ответ в заметке "Node/Proxy in Kubernetes RBAC".

По итогу:
- Возможность работы с Pods на Node напрямую через Kublet API в обход Kubernetes API
- Право GET позволяет читать, например, получить список Pods на Node
- Право CREATE позволяет читать, например, выполнить команду в Pods
- Доступ к портам, что закрыты firewalls
- Обход средств контроля безопасности, таких как Kubernetes Audit Log и Admission controls

Отдельно стоит еще посмотреть на заметку "Detecting direct access to the Kubelet". По итогу, понять какой именно пользователь обращался к node proxy в Audit log нельзя, но можно увидеть, что кто-то обращался к nodes/proxy sub-resource по записям в логе о TokenReviews и SubjectAccessReviews ресурсах от kubelet.

Заодно ребята еще проверили багу 2019 года с “Abusing Kubernetes API server proxying” и убедились что она работает до сих пор.

P.S. Также не забывайте про "*" ;)

secureCodeBox это kubernetes-based модульный toolchain от проекта OWASP на базе множества open source сканеров для continuous security scans. Это какая-то мечта любого DevSecOps специалиста!

Смотрите сами:
- Поддержка более 15 сканеров: Amass, Git Repo Scanner, Gitleaks, Kubehunter, Kubeaudit, Nikto, Nmap, Nuclei, Semgrep, Trivy, ZAP и другие.
- Встраивание в CI/CD pipeline или Kubernetes окружение
- Наличие собственного Dashboard, интеграции с DefectDojo и Kibana (ELK Stack) или кастомная интеграция
- Управление и контроль через его Custom Resources: Scan, ScheduledScan, ScanType, ParseDefinition, ScanCompletionHook, CascadingRule (еще один шажок в направлении Security-as-Code)

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

Статья "Hardening Kaniko build process with Linux capabilities" о повышения уровня безопасности процесса сборки при использовании Kaniko. Вопрос сборки образов внутри Kubernetes/containers мы уже как-то поднимали и обсуждали момент с преимуществами такого подхода. Но это статья не о простом использовании Kaniko, а о том, как можно улучшить, обезопасить процесс.

Ситуация с Kaniko следующая - его контейнер запускается от пользователя root. Можно, конечно, предположить, что ему для работы нужны далеко не все capabilitys =)

План: забираем все capabilitys и явно добавляем только нужные!

Автор в своих изысканиях с Kaniko пришел к такому результату: CHOWN, SETUID, SETGID, FOWNER, DAC_OVERRIDE.

Как вы понимаете такой подход работает и для других приложений ;)

Повсюду говорят о важности безопасности supply chain, но реализовать это не просто ведь состоит это не из одного какого-то действия, а из целой цепочки и ряда разнообразных типов инструментов. И тут руки опускают и включается режим ожидания “комбайна”, который сделает все сам через одну красную кнопку ...

Но если вы не ждун и руки чешутся все это реализовать здесь и сейчас, то статья "Improve supply chain security with GitHub actions, Cosign, Kyverno and other open source tools" как раз для вас как ориентир.

Тут вам и генерация, и проверка checksum, SBOM, подписи образа с помощью Docker Content Trust (DCT), Cosign, Syft, Kyverno, а также сканирование на уязвимости с помощью Trivy и все через GitHub actions!

Отдельно выделю раздел "Further improvement or study" о том, как еще можно улучшить данную цепочку.

Появилась мысль создать стикерпак канала "k8s(in)security" =)

Все же любят наклейки?!

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

Взаимодействие с дизайнерами, печать я возьму на себя.

В дальнейшим данный стикерпак буду раздавать на конференциях или высылать в качестве призов/подарков. А авторам чьи идеи войдут в реализацию будут среди первых кто получит стикерпак ;)

В общем пишем и предлагаем в комментариях!!!

P.S. Идеи буду собирать до конца февраля.

А помните или знаете ли вы как начинался Kubernetes?

Если нет, то прекрасным занятием на выходные будет просмотр фильма "Kubernetes: The Documentary"! Сейчас доступно 2 части (не знаю будут ли еще):
- PART 1 (25 мин)
- PART 2 (31 мин)

Снято это проектом Honeypot и у них есть и другие документалки про Vue.js, GraphQL, Elixir, Ember.js.

Всем хорошей пятницы и выходных!

В комментариях на той неделе написали, что в теме безопасности supply chain обязательно нужно и рассказать и о таком проекте как Tekton. И только я взялся за подготовку поста про него, как вышла замечательная статья "How Citi is building the secure software factory with Sigstore and Tekton".

В рамках статьи авторы рассказали о проекте Secure Software Factory, который является прототипом реализации для CNCF's Secure Software Factory Reference Architecture, которая базируется на CNCF's Software Supply Chain Best Practices White Paper и SLSA guidelines.

Свою реализацию ребята в будущем планируют сделать доступной в рамках OpenSSF Supply Chain Integrity. Пока можно посмотреть видео работы их системы.

Безопасность supply chain совсем скоро будет просто и доступна всем и останется только (и самое сложное) адаптировать уже существующие процессы компании под это.
Изучив все документы – вас никто не сможет удивить в теме безопасности supply chain!

P.S. Пост про проект Tekton это не отменяет ;)

Я как один из членов программного комитета конференции ZeroNights рад объявить, что мы опубликовали детали конференции этого года. Конференция будет 0xB по счету и проходить 1 день 23 июня в белые ночи в Санкт-Петербурге в отличном месте на берегу Финского залива.

Уже сейчас можно подать заявку на доклад - CFP открыт. Ждем доклады как на атакующие темы, так и на защитные (ранее мы их выделяли в отдельный Defensive track). Я лично буду очень рад заявкам на темы контейнеров, Kubernetes и облаков ;)

В этом году я также планирую представить новое исследование на тему Kubernetes на ZeroNights 2022. На текущий момент это скорее всего будет исследование с рабочим названием "NetworkPolicy: родной межсетевой экран Kubernetes". Посмотрим на то как и что могут NetworkPolicy и как они устроены в различных CNI и куда они развиваются. На текущий момент мы с моим коллегой накидываем идеи и готовим заявку)

Cloud Native мир дарит нам много сюрпризов!


Уязвимость CVE-2022-21701 в Istio

В случае если у атакующего есть права на создание Custom Resource под названием gateways.gateway.networking.k8s.io, то он может создать другие Kubernetes ресурсы, которые он по идее (правам) создавать не может, на пример, Pods, что может привести к повышению привилегий (Privileged Escalation).


Уязвимость CVE-2022-24348 в ArgoCD

В случае если у атакующего есть возможность подготовить вредоносный Helm-чарт, то он может позволить ему сдампить Secrets и другую критичную информацию других приложений из кластера, что может привести к повышению привилегий (Privileged Escalation).


Два абсолютно разных проекта, но насколько же однотипные (одной природы) уязвимости - не находите? ;)

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

В эту среду 09.02.2022 в 16:00 мой коллега и я будем гостями крутого подкаста linkmeup с темой "eBPF и ни слова про сети". И все это в преддверии нашего выступления на конференции HighLoad++ 17-18 марта в Москве с докладом "eBPF в production-условиях".

Если вам интересно что может дать eBPF кроме обработки сетевых пакетов, XDP и всего такого (об этом есть другой крутой выпуск этого же подкаста – очень рекомендую сначала послушать его ), то welcome на выпуск!

Ссылка на прямую трансляцию на YouTube.