Последнее время я много пишу про безопасность образов. И возникает вопрос, а как дела обстоят у нашего Luntry и как мы смотрим на данный аспект. Ведь в нашем составе также есть сторонние компоненты и в них появляются известные уязвимости. И так по порядку, что мы делаем и что предоставляем:
1) Стараемся своевременно все патчить. Но это не всегда просто и все равно есть окно между моментом, когда это находит наш же сканер (да у нас есть сканер на известные CVE) и моментом когда обновленная версия раскатывается клиентом.
2) Переходим на distroless образы. Снижаем false positive срабатывания сканера на известные CVE, уменьшаем attack surface и возможности для атакующего.
3) Предоставляем модели поведения (behaviour models) для Luntry на наши микросервисы. В случае попыток эксплуатации известных CVE или не известных уязвимостей (0-days) наш движок обнаружит аномалию и проинформирует клиента.
4) Предоставляем AppArmor для наших микросервисов. В случае попыток эксплуатации известных CVE или не известных (0-days) подсистема ядра Linux просто не даст запуститься тому, что не прописано в AppArmor профиле.
5) Предоставляем NetworkPolicy для наших микросервисов. Если атакующий каким-то образом все-таки смог запустить вредоносную логику, то по сети он не сможет общаться с сервисами клиента, да и вообще не со всеми компонентами нашей системы.

На мой взгляд это супер набор, который сторонний вендор может сделать и предоставить клиенту, для обоснование безопасности своего продукта на ряду со SBOM. И в моем идеальном мире будущего - сторонний вендор, аутсорсер должен предоставлять это на свою разработку, а клиент только использовать и контролировать, реализую концепцию ZeroTrust.

Сегодня поговорим об одном тонком моменте связанным с автоматической генерацией NetworkPolicy. Реализуя данную фичу в нашем Luntry, мы предварительно проанализировали подобную функциональность в других решениях и с удивлением обнаружили, что никто не учитывал специфику labels, которые есть у Pods ...

Если сказать проще, то при генерации NetworkPolicy в этих решениях в podSelector попадали абсолютно ВСЕ labels - типа pod-template-hash, minor-version и подобные легко/часто меняющиеся labels. Это автоматом означало, что при их изменении, применение NetworkPolicy просто отваливалась. В итоге, с такими политиками приходится еще и возится вручную или часто их пере генерировать и пере применять.

Так что важно при работе с NetworkPolicy выделить/определить labels по которым будет применяться сетевая политика ;)

Сегодня и завтра пройдет ежегодный eBPF Summit . Старт в 18:30 по Мск. Трансляцию всех докладов всех двух дней можно посмотреть здесь:
- День 1
- День 2

Там море интересных докладов! Я же для себя отметил:
- Signed eBPF Programs: A Cross-Platform Analysis
- When you need to overcome your fear and build your own data-driven eBPF firewall
- Securing systems with eBPF Linux Security Module
- Using eBPF in system security
- Applied eBPF for cross platform security research
- Analysis of offensive capabilities of eBPF and implementation of a rootkit

P.S. Для ряда презентаций первого дня в описании доклада уже доступны слайды!

Сегодня хочу рассказать про один интересный/забавный момент, что недавно со мной поделились 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.