Сегодня хочу рассказать про один интересный/забавный момент, что недавно со мной поделились SOC команды из наших клиентов.

Но сначала поясню что у нас в Luntry есть функциональность Runtime Security, которая позволяет строить поведенческие модели для микросервисов (выглядят они в виде графа взаимоотношений между процессами). Отхождения от модели поведения создаёт аномалию и на неё уже реагирует SOC. Это как бы их классический сценарий работы.

Но порой они лезут глубже и изучают что вообще микросервисы делают и из чего состоят. И находят просто ужас/кошмар разработки. На пример, цепочку вызовов: java -> python -> bash -> perl …ну и это уже эскалируют на Лидов разработки, которых такое тоже повергает в шок =)

PS Для SOC такие цепочки вызовов также выглядят очень подозрительно и напоминают закрепление ;)

На просторах сети попалась очень добротная статья "Kubernetes Security Best Practices Part 2: Network Policies" - про нативные NetworkPolicy (не забываем что есть и кастомные от Calico и Cilium).

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

Отдельно обращу ваше внимание на раздел про "Deny-all NetworkPolicy", так как далеко не все понимают истинный смысл данной политики (и скорее используют на автомате, бездумно).

А так же в статье отдельно четко прописан момент про "NetworkPolicies have to be defined on both sides" - не забывайте ;)

После релиза PCI Security Standards Council документа "Guidance for Containers and Container Orchestration Tools" исследователи продолжают его анализировать и оценивать его применимость к Kubernetes. Так в новой статье "The Challenges of Assessing Kubernetes clusters for PCI Compliance" автор рассматривает проблемы/вызовы с которыми может столкнуться аудитор при рассмотрении сред Kubernetes в виду их разнообразия (не забываем, что Kubernetes это фреймворк и каждый его готовит и использует по своему). Фундаментально автор рассматривает 2 важных аспекта:
1) Managed against Unmanaged - тут и возможность проверить настройки Control Plane и точное расположение файлов и имен или вообще как отдельный кейс OpenShift.
2) Kubernetes Versions - достаточно сказать об очень динамичном развитии Kubernetes с появлением новых возможностей (в стадиях “alpha” , “beta”, “GA”), так и с исчезновением старых (“deprecated”).

Так что некорректное соотношение гайдов к окружению может дать абсолютно непрогнозируемые результаты (false positive или false negative).

В официальном блоге появилась емкая и короткая заметка c очень говорящим названием "Kubernetes 1.25: alpha support for running Pods with user namespaces".

Если кратко, то она о фичи которая позволяет контейнерным процессам работать в отдельном пространстве (user namespace), отличном от хостового. И root в одном не является root в другом. Что также позволяет уменьшить возможный ущерб в случае эксплотации ряда уязвимостей в контейнере.

Для работы с этой фичей необходимо:
1) Включенный UserNamespacesStatelessPodsSupport feature gate
2) Настройка "hostUsers: false" в спецификации Pod
3) Container Runtime с соответствующей поддержкой: CRI-O >= v1.25 или containerd >= 1.7 (еще не вышла)

Также в документации есть более детальный пример использования данной фичи в разделе "Use a User Namespace With a Pod".

P.S. Кстати, не путайте эту фичу с KubeletInUserNamespace, появившейся в 1.22.

P.S.S. Для полного погружения в тему изучите 1 и 2.

На днях прошла конференция KubeHuddle 2022 в расписании которой есть много всего интересного, а видео уже доступно [1,2,3,4]. На пример:

- eBPF or sidecars?
- Securing Kubernetes with Open Policy Agent
- Hacking Kubernetes Like a Beginner with kdigger 🔥
- Secret Management: The Soft Way

- Hacking Kubernetes: Live Demo Marathon 🔥
- Who Can You Really Trust?
- Step by step Kubernetes observability with eBPF
- How to protect your Kubernetes cluster using Crowdsec
- Policy + Cloud Controllers = Secure Scalable Dev-Centric Infrastructure.

- EBPF and Kubernetes - Next level observability
- BumbleBee: Or How I Learned To Stop Worrying And Love eBPF

P.S. Видео с eBPF Summit 2022 также уже доступно ;)

Статья "Exploiting Distroless Images" с прикольной техникой эксплотации в контейнерах на базе gcr.io/distroless/base, которая позволяет читать, писать произвольные файлы и выполнять команды в этом distroless image!

А все это базируется на присутствующей внутри этого образа OpenSSL! Да, shell внутри такого образа нет, но зато можно использовать interactive command prompt от OpenSSL ;)

Таким образом, атакующий, получивший доступ к Kubernetes кластеру, может, через установленный OpenSSL в distroless base образе, прочитать service account tokens (SA), прокинутые secrets и даже получить интерактивное выполнение команд через загрузку custom shell.

Помните в одном из прошлых постов писал, что не все Distroless Images одинаковые (static/base/cc/interpreted)?!

Так что distroless images это не панацея, а лишь одна из техник усиления (hardening) - и никто behavior monitoring, AppArmor не отменял.

P.S. О данной проблеме/особенности было сообщено Google в августе 2021 и они решили не фиксить это.

Обновляя свой тренинг по безопасности Kubernetes до соответствующей последней доступной версии 1.25, поймал себя на мысли, что она для меня стала в один ряд с версией 1.22 по вкладу в аспекты безопасности. То есть стала одной из любимых, если так можно по этому вопросу выразиться) Понятное дело, что много классных нововведений и изменений там еще находиться в стадии alpha, но это не принижает их вклада.

Также сегодня хочу сказать, что наша небольшая команда Luntry продолжает медленно, но верно расти и искать новых единомышленников! Сейчас мы ищем:
- Middle/Senior Go Developer - работа с Kubernetes operators и высокой нагрузкой.
- Frontend/Full-stack-разработчик (Middle/Senior) - работа с незаурядными интерфейсами, графиками, графами и API.

Можно откликаться как там, так и писать на прямую мне - репост приветствуется =)

Из статьи "Introducing Wolfi – the first Linux (Un)distro designed for securing the software supply chain" вы узнаете о дистрибутиве Wolfi (хотя авторы для него придумали название undistro) для supply chain security и он сфокусирован на container/cloud-native окружениях с рядом специализированных особенностей/возможностей:
- Наличие SBOM во время сборки для всех пакетов
- Минималистичный образ
- Поддержка apk package формата
- Полностью declarative и reproducible билд система
- Поддeржка glibc и musl

С помощью данного проекта как раз и создают Chainguard Images, а это у нас реализация distroless образов! Подробнее о таких образах можно узнать из статьи "Minimal Container Images: Towards a More Secure Future" и понять что вам самим может проект Wolfi.

В первую очередь проект будет интересен тем кто хочет делать свои собственные distroless образы и тщательно следить за supply chain security.

Достаточно хорошее сравнение Policy Engine: Gatekeeper и Kyverno в статье "Kubernetes Policy Comparison: OPA/Gatekeeper vs. Kyverno".

А вот тут можно посмотреть наше с коллегой сравнение - оно сделано немного на другом уровне.

О сравнение этих движков с PSP и PSA я писал ранее тут.

А так я лично отношусь к ним обоим нормально (поэтому в Luntry есть поддержка одного и второго), но предпочтение отдаю Kyverno ;)

Сегодня я хочу поделится с вами записью и слайдами своего keynote-доклада "Заметки путешественника между мирами: ИБ, ИТ" с конференции OFFZONE 2022.

Большое спасибо организаторам за возможность открыть конференцию, поделиться своим опытом, знанием и идеями/взглядами с сообществом!

Если вам хочется понимать как в современных реалиях нужно подходить к ИБ и просто хочется лучше понимать мои взгляды на ИБ, то доклад определенно стоит посмотреть - я в него вложил много своего опыта и знаний.

Некоторое продолжение/развитие данная тема получит у меня в докладе "Сочетание несочетаемого в Kubernetes: удобство, производительность, безопасность" на HighLoad++ в Москве 24-25 ноября.

Недавно в комментариях к посту спрашивали, что такое Image Registry lookups и Image Verification в контексте Policy Engine. Сегодня я подготовил подборку по этой теме того, что уже писал и не писал на канале. Основные герои это Sigstore Cosign и Kyverno, которые хорошо дружат между собой. И так поехали:

- "Signing And Verifying Container Images With Sigstore Cosign And Kyverno" - краткий видео экскурс в тему
- "Securing GitOps Supply Chain with Sigstore and Kyverno" - выступление с примером кода для реализации с учетом ArgoCD
- "Protect the Pipe! A Policy-based Approach for Securing CI/CD Pipelines" - выступление с примером кода для реализации с учетом Tekton
- Пошаговая инструкция по использованию Cosign и Kyverno
- Пост про политики, ограничивающие/контролирующие Image Registry

В сети стала доступна видеозапись доклад "Pentesting Kubernetes: From Zero to Hero" (и слайды) от моего коллеги Сергея Канибора с VolgaCTF 2022!

Данный доклад скорее является RoadMap, а не полной инструкцией по пентесту Kubernetes. Уместить некоторые моменты в пределах одного доклада не представляется возможным. Так же как и рассказать о всех возможных техниках и нюансах с которыми можно столкнуться при пентесте Kubernetes кластера. Но мы постарались это рассказать максимально компактно и понятно.

Если вы только начинаете свой путь в этом направлении, то это прям MUST WATCH!

В заметке "Learn about Kubernetes security best practices for your cloud native application development" из блога CNCF мое внимание привлекло не само содержимое текста, а то какие там материалы были использованы (да бывает и такое).

1) Правильная мысль и цитата: "By integrating security as early as possible throughout the development lifecycle, or even earlier with interactive developer training, security organizations can enable preventative security rather than reactive security." из Cloud Native Security Whitepaper.

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

2) Ссылка на очень старый материал "9 Box of Controls" от ребят из BlackBerry. Заглавная картинка как раз от туда.

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

version-checker это простенький инструмент для Kubernetes, который смотрит какие версии образов контейнеров запущены в кластере и на сколько они соответствуют последним версиям данного проекта. Тоесть позволяет очень просто контролировать актуальность используемых образов. Результаты проверки вывешиваются как Prometheus metrics, отображаются на dashboard и могут информировать об этом оператора.

При этом поддерживается порядочный набор registries:
- ACR
- Docker Hub
- ECR
- GCR (включая k8s.gcr.io)
- Quay
- Self Hosted (Docker V2 API совместимые реджистри типа artifactory и т.д.)

На конференции OFFZONE 2022 в этом году у меня было аж два доклада и второй из них (видео и слайды) это "Безопасность Kubernetes: Фаза Deception" (первый - это мой `keynote`-доклад).

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

Данный доклад будет полезен Red и Blue team, работающих с Kubernetes.

P.S. В комментариях можно предлагать свои идеи - я уверен, что в данном направлении можно придумать еще много всего интересного ;)

Буквально недавно открыл для себя https://www.kubernetes.dev/ - где очень удобно можно следить за Kubernetes Enhancement Proposals (KEPs) (также искать/копаться в них) и на страничке Release смотреть какие фичи появятся в новой версии (Enhancements Tracking Sheet) и в какие даты выйдет (kubernetes/sig-release v1.26 milestone).

Так, на пример, я/мы/все теперь могу намного проще следить за "KEP-2091: Add support for AdminNetworkPolicy resources". О нем я уже как-то писал тут, но с тех времен ресурс ClusterNetworkPolicy переименовали в AdminNetworkPolicy.

Недавно наткнулся на политику "Verify Image Check CVE-2022-42889" в постоянно расширяемой библиотеке политик Kyverno (уже 232 политики).

Она позволяет проверить есть ли в образе последняя нашумевшая уязвимость в Apache Commons Text library или нет и решить разрешить ли выкатку микросервиса с таким образом или нет.

Все это делается на основании информации из SBOM, которая предварительно генерируется в CI, а далее в самой политике прописываем где она лежит, в каком форма, название какого компонента нас интересует и какой версии.

За деталями реализации помимо самого примера для данной уязвимости будет полезно почитать разделы:
- Verify Images - проверка образов
- JMESPath - JSON язык запросов

Также можно обратить внимание на следующие политики связанные с работой с уязвимостями:
- "Require Image Vulnerability Scans" - есть скан на уязвимости не старше 1 недели
- "Check Tekton TaskRun Vulnerability Scan" - скан на уязвимости не содержит уязвимости с рейтингом больше 8.0

Сегодня в 11:00 (по Мск) я (от лица Luntry) в приятной компании буду участвовать в онлайн-конференции AM Live «Российский DevSecOps в условиях импортозамещения». По мне это прекрасная возможность послушать как различные вендоры, интеграторы и дистрибьюторы смотрят на вопрос DevSecOps.

Вместе с командой сейчас работаем над добавлением в Luntry функциональности связанной с Compliance, а именно CIS Kubernetes Benchmark. Предварительно мы проанализировали множество OpenSource и коммерческих решений - первые на уровне кода и UI, вторые чисто на уровне UI. Остановимся на первых и обсудим к каким не утешительным выводам мы пришли. И так, обнаруженные проблемы:
- Отсутствие реализации проверок - идет как TODO или manual check
- Не полная реализация проверок - этот факт даже отмечается в комментариях (partial check)
- Отсутствие поддержки новых версий Kubernetes - для кого-то может быть новостью, но CIS Kubernetes Benchmark обновляется с новыми релизами Kubernetes.

В итоге, запуская/используя тот или иной инструмент с этими проблемами вы получаете не корректную картину по своей инфраструктуре.

P.S. Не ленитесь читать код OpenSource проектов!