Обычно на каналах публикуют классные и полезные материалы. А я сегодня хочу показать пример неудачной статьи "Kubernetes Pentest: Checklist, tools and resources".

Автор начинает со слов "When you arrive at kube-world as a beginner (like me) nothing has sense. ". А дальше непонятно при каких условиях/обстоятельствах, от куда из Pod или с Node, с правами или без, инструментами что уже есть в контейнере или надо отдельно скачать и т.д.

По итогу если вы прям начинающий, то вас это только запутает/демотивирует, а не поможет. А для людей кто более-менее в теме это просто небольшой перечь базовых команд. Для pentest куда более полезнее будет упоминаемый мною ранее репозитарий PayloadsAllTheThings.

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

Дописывая пост, я вообще подумал, что автор специально дает такие вредные советы, чтобы ему было проще защищать свою Kubernetes инфраструктуру =)

Для Kyverno появился очень занимательный проект Policy Reporter, который позволяет отправлять и смотреть результаты работы данного policy engine в режиме аудита (не блокировки) в наши любимые и не очень:
- Grafana Loki
- Elasticsearch
- Slack
- Discord
- MS Teams
- Prometheus Metrics API
- Policy Reporter UI

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

Под капотом все на самом деле очень просто и крутится вокруг таких его Custom Resources как PolicyReport и ClusterPolicyReport из группы wgpolicyk8s.io. Это также идет в копилку работы Policy Working Group и приближению к концепции Everything-as-Code, а далее и к SOAR. По аналогии можно будет делать подобное с любым Custom Resources из группы wgpolicyk8s.io!

Вчера несколько друзей мне скинули статью "Hiding in Plaintext Sight: Abusing The Lack of Kubernetes Auditing Policies".

Cуть: Исследователь придумал использовать секцию annotations в K8s манифестах для скрытой передачи данных и организации С2 (C&C, Command and Control).

И все это для того, чтобы объяснить, что важно использовать Audit Log. Оригинально, но мудрено.

При этом нужно понимать, что для реализации представленного сценария у атакующего должны быть не малые права/возможности:
- Доступ из вне с возможности аннотации ресурсов
- Его вредоносный агент установленный на Node или в Pod с правами на получение аннотированного ранее ресурса.

Для большей скрытности можно еще за использовать Static Pods ;)

При выполнении annotate происходит 2 запроса: GET и PATCH, тоесть у атакующего должны быть get и patch verbs в RBAC Role на тот тип ресурсов, что он использует в качестве скрытого канала.

Из полезного могу выделить ссылки о том, как включить Kubernetes logging в AWS, GCP и Azure.

Альберт Эйнштейн говорил: «Только дурак нуждается в порядке — гений господствует над хаосом», но это не верно для работы нескольких департаментов (DEV,QA,SEC,OPS,SRE,...) и вообще в командой работе.

На мой взгляд систематизация и порядок являются важными составляющими надежной и безопасной системы. Особенно когда с системой работает много людей и происходит множество быстрых изменений, как в микросервисных приложениях.

В плане Kubernetes я для себя выделил 2 направления:
1) Подход к организации хранения Kubernetes манифестов - посмотрите "A Better Way of Organizing Your Kubernetes Manifest Files".
2) Подход к организации аннотаций в Kubernetes манифестах - посмотрите "Annotating Kubernetes Services for Humans".

Это позволяет и подход Policy-as-Code применить, и процесс troubleshooting'а упростить и ускорить.

Применяете ли вы такое? Или может у вас есть какие-то свои подходы? Можете поделиться своими наработками, советами в комментариях.

На днях прошел второй eBPF Summit. И уже доступны все записи докладов на YouTube! Я еще не успел все посмотреть, но обязательно после выходных расскажу о своем топе (с прошлого года можно посмотреть тут).

Про eBPF будет полезно послушать всем и тем кто работает с HighLoad системами, и тем кому просто интересны темы observability, network и security. В этом году все доклады имеют маркировку уровня сложности и разбиты на несколько блоков/тем:
- Keynote
- Observability
- Security
- Deploying BPF in Kubernetes
- Networking
- Writing BPF code
- Advanced

Если кратко пробежаться по самим докладам, то там затронуты такие области: SRE, GPU, Continuous Profiling, Attacks, Kernel Security Monitoring, IoT, Windows, Load Balancing, DNS, Firewall, BPF Library Ecosystem, Rust и многое другое.

Всем хороших, продуктивных выходных ;)

P.S. У себя в разработке мы активно используем eBPF и с недавних пор в сочетании с Rust.

Классная статья "Kubernetes — Running Multiple Container Runtimes" в стиле HOW-TO.

Статья о том (мало кто знает) как в Kubernetes можно запускать несколько Container Runtime и использовать их по ситуации (в зависимости от того, что запускаем). В техническом плане здесь описывается как на Nodes настроить containerd (высокоуровневый runtime) для работы с (низкоуровневыми) runC и Kata Containers (базируется на концепции microVM). И потом управлять какой workload где запускать с помощью Kubernetes ресурса RuntimeClass (стандартный ресурс с версии 1.14). При этом стоит отметить, что такое можно проворачивать с любым CRI совместимым Container Runtime, на пример, CRI-O, gVisor и т.д.

Алгоритм:
1) Настраиваем на нужной Node конфиг containerd для работы с Kata Containers
2) Устанавливаем Kata Containers на Node, где правили конфиг containerd
3) Инициализируем Kubernetes Control Plane
4) Помечаем Node с Kata Containers, используя taint и label, для запуска определённых workloads
5) Создаем ресурс RuntimeClass с описанием Kata Containers
6) Создаем workload с соответствующими параметрами для runtimeClassName, nodeSelector, tolerations для запуска в Kata Containers

Таким образом можно разграничивать доверенные и недоваренные workloads. Но не все так замечательно и поговорим об этом завтра.

P.S. Для тех, кому проект Kata Containers очень интересен рекомендую следить за их twitter аккаунтом

На конференции BlackHat USA 2020 было представлено исследование "Escaping Virtualized Containers".

В рамках данной работы исследователи проводили анализ Kata Containers (о котором я говорил в прошлом посте). По результатам их работы удалось совершить Container-to-Host Code Execution (побег) благодаря цепочки из 3-х уязвимостей:

- CVE-2020-2023 (Container-to-Guest)
- CVE-2020-2025 (CLH commits to VM image)
- CVE-2020-2026 (Mount Redirection)

Были найдены и другие уязвимости типа DoS. При этом авторы отмечают, что многое зависит от настроек runtime и то какими capability обладает контейнер. Есть ли там еще подобные уязвимости - точно да! Авторы говорят: "Shared Directory is a Big Attack Surface". MicroVM это не какая-то магия, а только ограничение attack surface через уязвимости ядра хостовой ОС. Есть и другие способы побега ;)

На мой взгляд с учетом изменений в версии 1.22 и грамотного подхода к capability и классические контейнеры дадут высокий уровень безопасности. При этом они также дадут и прекрасный уровень observability, того, что происходит внутри контейнера (когда MicroVM это blackbox). Выход из контейнера не самоцель для атакующего, он также может атаковать и другие сервисы оттуда (или майнить) и от этого MicroVM не защитит, а скорее затруднит обнаружение.

В индустрии ИБ сейчас многие ставят Detection и Response важнее, чем Prevention.

Крутая картинка со систематизацией Kubernetes Privilege Escalation! (Автор не известен.)

И Red team и Blue team это все очень полезно знать.

P.S. Сегодня на ZeroNights - буду рад пообщаться лично, пообсуждать Kubernetes ;)

Небольшой, но очень технический доклад "Cracking the kernel adventures with kernel exploits in Kubernetes" с большим количеством примеров и демо. MUST SEE!

Картинка: "Open source dependency feelings".

Вы уже наверняка сталкивались с таким выбором или просто не задумывались о втором варианте и всегда выбирали один из них =)

Не зря время это один из самых (если не самый) важных ресурсов, а еще с учетом высокой скорости жизни. В индустрии разработки это ощущается еще больше: Agile, time-to-market и т.д. Тут самое место вспомнить и про Supply Chain атаки (готовые библиотеки, образы, YAML ресурсы, HELM чарты,). На самом деле проверить все полностью невозможно. И как я уже не однократно писал в постах в индустрии на первое место выходят Detection и Response, обгоняя Prevention.

Всем хороших выходных!

P.S. Планировал юмористический пост, а получился не очень ...
P.S.S. На следующем KubeCon + CloudNativeCon North будет уже отдельная секция SupplyChainSecurityCon! Рассписание и доклады уже опубликованы.

Cloud Native Security Map is LIVE!

Данный проект создан он на основе документа Cloud Native Security Whitepaper от SIG-Security. О данном документе я уже писал пару раз [1,2]. По сути, это маппинг разных популярных security инструментов на разделы данного документа. В оригинальном документе описываются только сами принципы, а примеры инструментов отсутствуют. Очевидно, что данный проект многим будут очень полезен.

Я со своей стороны скажу, что в нем на текущий момент отсутствует много, очень много чего интересного и полезного. Правильнее даже будут сказать, что в документе присутствует только то, за чем стоят какие-то компании, чьи сотрудники отвечают за продвижение своих проектов. Так что не смотрите на данный список как на истину последней инстанции.

P.S. Насколько я понимаю это первая публичная версия и авторы очень ждут feedback.

Сегодня хотелось бы всех познакомить с проектом Gatekeeper Policy Manager (GPM). Это UI для просмотра OPA Gatekeeper политик с их статусами, предупреждениями и т.д. По сути, со всеми Custom Resources, что привносит данный оператор.

Подобный проект для другого policy engine - Kyverno я рассматривал несколько дней назад здесь.

Определённо данные и подобные проекты многим позволят упростить использование policy engine в своих инфраструктурах и привлечь больше команд (Dev, Ops, Sec - зависит от того с чей стороны исходит инициатива) в своих проектах, что значительно большой плюс для построения надежного и безопасного Kubernetes кластера.

За последнее время появилось много статей про опцию SeccompDefault, появившуюся в версии 1.22. Данная опция меняет дефолтный seccomp профиль с Unconfined на RuntimeDefault.

На мой взгляд самыми полезными статьями являются:
1) "Enable seccomp for all workloads with a new v1.22 alpha feature" от специалиста из Red Hat с официального блога Kubernetes
2) "How to enable Kubernetes container RuntimeDefault seccomp profile for all workloads" от специалиста из Azure

В первой статье, упор больше идет на то, как это правильно включить и постепенно активировать во всем кластере без вреда вашим приложениям. Конечно, тут упоминается и Security Profiles Operator. Во второй статье, автор больше отвечает на вопрос: что такое этот RuntimeDefaults профиль и что он дает.

Интересные моменты:
- У каждого Container Runtime есть свой RuntimeDefaults профиль, и они отличаются
- Включать данную опцию можно постепенно или только на определенных узлах, а не на всем кластере
- Приложение на заблокированный syscall получит ответ EPERM хотя обсуждения есть и про ENOSYS

И замечательная цитата: "Developers, site reliability engineers and infrastructure administrators have to work hand in hand to create, distribute and maintain the profiles over the applications life-cycle."

P.S. Не забываем и про то что можно сделать и указать свой кастомный еще более строгий seccomp профиль

Неделю назад на сайте Service Mesh Istio вышла новая Security Bulletin под названием "Multiple CVEs related to AuthorizationPolicy, EnvoyFilter and Envoy". Речь в ней идет аж о 6 CVE и все они связаны с Envoy (который является частью sidecar):

1) CVE-2021-39156 (CVE-2021-32779) - bypass Istio’s URI path-based authorization policies
2) CVE-2021-39155 - potentially bypass an Istio authorization policy
3) CVE-2021-32777 - incomplete authorization policy check
4) CVE-2021-32778 - excessive CPU consumption
5) CVE-2021-32780 - Envoy to terminate abnormally
6) CVE-2021-32781 - Envoy accessing deallocated memory and terminating abnormally

То, что в Istio/Envoy есть уязвимости не удивительно и ни чего страшного - они есть у всех. Но осознавая, то, что для обновления требуется перезапустить все Pod'ы внутри которых есть sidecar, невольно задумываешься о простоте и удобстве ремонтопригодности той или иной технологии ...

P.S. А если еще задуматься где вообще Envoy применяется, то ...

Картинка смешная, а ресеч "Real Life Story of the 1st Mainframe Container Breakout" с конференции DEF CON 29 по мотивам данной картинки классный! Лично мне нравится, когда люди так креативно подходят к исследованиям.

Ситуация у них была следующая: "IBM zCX is a Docker environment running on a custom Linux hypervisor built atop z/OS - IBM’s mainframe operating system.", а итог побег (escape) на zCX хост.
Самое интересное (само исследование) начинается на 13:40. Основной рывок им дала возможность обращаться к Docker API по сокету /var/run/docker.sock из контейнера =)
Матрешка: Container -> Linux Docker Engine -> Linux kernel -> zCX - > z/OS. Как видно они добрались до предпоследнего уровня, но в планах дойти и до последнего - z/OS.

Всем хороших выходных!

Недавно вышел достаточно увесистый отчет "Kubernetes Control Plane Vulnerability Assessment", в рамках которого аудиторы рассматривают, что и как может атакующий, получивший доступ к Node (на пример, через побег из контейнера).

Весь анализ происходит на K8s версии 1.21.0 и идет в разрезе темы multi-tenancy и безопасности Control Plane. Правда по факту тут они касаются только node-based multi-tenancy, а других подходов, что рассматривает сейчас рабочая группа не затрагивают.

По отчету есть небольшая запись в блоге "Looking at the Kubernetes Control Plane for Multi-Tenancy". Но по мне она совсем не передает сути работы и лучше читать оригинал - там много классных, тонких моментов для ценителей ;)

Ключевые слова по отчету это: Taints & Tolerations, Node Authorizer, NodeRestriction. Не знаете, что это и зачем нужно в security - читайте отчет и со всем разберетесь!

Вишенкой на торте является раздел "Threat Model".

Распределенная трассировка (Distributed Tracing) у многих ассоциируется только с сетевым взаимодействием собственных сервисов, за которыми идет наблюдение, ну и, конечно, с решениями Jaeger, Zipkin, OpenTelemetry.

Но со временем все больше интересных возможных применений находят трассировке. И сегодня хочется рассказать о ряде таких:
1) В Kubernetes v1.22 в alpha стадии добавили API Server Tracing, который позволяет замерять и смотреть как выполняется та или иная активность на API Server.
2) Проект kspan, позволяющий представлять Kubernetes Events в виде spans и также наблюдать за работой Kubernetes.
3) Работы в духе "Detecting Cyber Security Attacks against a Microservices Application using Distributed Tracing" для обнаружения аномалий связанных с нарушением безопасности.

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

В продолжение моего недавнего поста про безопасность при node-based multi-tenancy - в официальном блоге Kubernetes вышла статья "Advanced Kubernetes pod to node scheduling"

В ней очень просто, понятно с примерами рассматриваются такие Use Cases для Pod-to-Node Scheduling, как :
- Running pods on nodes with dedicated hardware
- Pods colocation and codependency
- Data Locality
- High Availability and Fault Tolerance

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

В статье рассматриваются следующие механизмы и стратегии:
- nodeSelector
- Node Affinity
- Inter-Pod Affinity
- Taints and Tolerations
- Pod Anti-Affinity

Вообще за последнее время вышло много статей по данной теме и можно сказать, что это какой-то тренд или нет ;)

И еще раз продолжая тему распределения рабочих нагрузок (Pod) по Nodes, рассмотрим ситуацию когда нужно чтобы нагрузка выполнялась на Nodes с определенными устройствами. На пример, таких как FPGA, GPU, high-performance NICs, InfiniBand adapters, что очень актуально при текущем развитии и распространённости машинного обучения (ML). Но не все хорошо сейчас в этом направлении (там каждый кто во что горазд) ...

И вот, рабочая группа Container Orchestrated Device (COD) сейчас работает над Container Device Interface (CDI), которая является спецификацией для container runtimes, для поддержки разных сторонних устройств через общепринятую, понятную всем систему плагинов. По сути, это продолжение линейки: CRI, CNI, CSI, SMI, CPI.

По мне так или иначе они должны будут затронуть тему безопасности - ведь нужно контролировать какая нагрузка к каким устройством может иметь доступ, а к каким нет. Злоумышленники, которые уже нацелены на мощное железно для майнинга, как мы знаем, уже были замечены. И работа в данном направлении может стать дополнительным эшелоном защиты.

Легкий пятничный пост.

Те, кто занимаются пентестами и имеют дело с Linux и Windows окружениями определённо должны знать о таких проектах как:
- GTFOBin для Linux
- LOLBAS для Windows (есть даже drivers)

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

Так вот пользователь twitter подметил, что всеми нами любимый kubectl с флагом --raw отлично подходит для замены тех же curl и/или wget, если их нет под рукой, и отлично подходит для пополнения данных проектов!

Месяц назад гремела новость про "Kubernetes Hardening Guidance" от NSA (и я об этом писал), затем все писали про инструмент Kubescape для проверки по данному гайду (я об то не писал).

И пока совсем без внимания остается статья "NSA & CISA Kubernetes Security Guidance – A Critical Review" от известной security компании. Статья состоит из 3-х частей: что хорошего, что плохого и что забыто в данном гайде.

На том что там хорошего - останавливаться не будем, лишь процитирую авторов по этому поводу: "Each of these points relate back to the generic guidance for almost any platform, regardless of the technology in use"

Про плохое (страдает точность, актуальность и полнота):
- PSP Deprecation - про данный факт ни слова.
- Admission Controllers - практически не упоминаются, хотя это мощнейший инструмент k8s.
- Inconsistencies/Incorrect Information - опечатки/неточности про порты.
- Authentication Issues - ошибка что в k8s нет аутентификации по умолчанию.

Последнюю часть характеризует цитата: "With a project as complicated as Kubernetes, it is not possible to cover every option and every edge case in a single document, so trying to write a piece of one size fits all guidance won’t be possible. "). То есть там авторы говорят о том, что вообще не было рассмотрено в документе:
- Levels of Audit Data
- Sidecar Resource Requirements
- External Dependencies are essential
- RBAC is hard
- Patching Everything is hard