k8s (in)security

2023-ий год продолжает радовать отчетами о security audit open-source cloud native проектов. На этот раз containerd прошёл audit fuzzing.

В ходе тестирования было написано 28 фаззеров, покрывающих следующий функционал:

- containerd’s CRI endpoints
- Metadata image handling
- Image importing
- Archive diffing
- Content store processing
- Stream decompression
- Filters parsing

По результатам аудита были обнаружены всего четыре уникальные некритичные проблемы. Это свидетельствует о хорошо написанной и поддерживаемой кодовой базе проекта containerd. Три из них были в самом containerd, а одна – в сторонней зависимости. Найденной проблеме был присвоен CVE-2023-25153.

С полными результатами аудита можно ознакомиться тут.

Сегодня пятница, а значит что выходные уже совсем близко! И если вы давно планировали, но постоянно откладывали почитать исходных код Kubernetes, то тут как раз для вас появился отличный цикл статей про Kubernetes API Server. Можно сказать разбор всей внутрянки/исходников сердца Kubernetes! Пока выложено 3 части:
1) Welcome to Kubernetes API Server Adventures
2) K8s ASA: The Storage Interface
3) K8s ASA: Watching and Caching

Это настоящие лонгриды ведущие по исходному коду и комментирующие все по определённому аспекту Kubernetes API Server. Обязательно для тех кто не только просто хочет пользоваться k8s, но и понимать как он работает.

Всем, привет!
Как вы уже знаете мы решили сделать с нашей командой Лантри конференцию по безопасности контейнеров и контейнерных сред. Сейчас успешно к этому идем: место и дата в последних согласованиях, программа (просто космос - гигантское спасибо нашим друзьям, коллегам, клиентам, знакомым, партнерам!) почти собрана, сайт в проработке. НО с чем мы никак пока не можем определиться так это с ее названием ...

Поэтому решили обратиться к сообществу и посмотреть насколько круто с фантазией у вас =) Было бы здорово придумать название для конференции, а мы уже какие-нибудь подарки со своей стороны подарили!

В общем, как по вашему должна называться российская специализированная техническая конференция по безопасности контейнеров и контейнерных сред?

Варианты пишите пожалуйста в комментарии к данному посту до 10 марта.

Заранее всем спасибо!

Месяц назад, на прошедшем CloudNativeSecurityCon North Amreica 2023, анонсировали новый сертификат от The Linux Foundation – Kubernetes and Cloud Security Associate (KCSA). Возможность пройти сертификацию появится в Q3 2023 года.

Экзамен включает в себя проверку следующих знаний:

- Developing security policies and procedures and helping ensure compliance with industry standards and regulations
- Identifying and assessing security risks and vulnerabilities and helping implement controls to mitigate those risks
- Assisting in incident response and forensic investigations, as well as testing and monitoring security systems 
- Educating and training employees on security best practices

В конечном итоге мы имеем пять сертификаций, посвященных Kubernetes от The Linux Foundation : CKA, CKS, CKAD, KCNA, KCSA.

Я уже неоднократно писал, что Kubernetes Audit Log является важной частью безопасность k8s. НО при активации этого механизма возрастает нагрузка на Kubernetes API Server и как-то надо вообще справляться с целым тайфуном сообщений от этой подсистемы. Конечно, разумным планом является оптимизаций того что логировать, а что нет. И одним из хороших вариантов оптимизации является вырезание событий/действий завязанных на системные субъекты (производимые ими). Идея в том чтобы вырезать доверенных роботов (и молиться чтобы Skynet оставался только в кино), которые в основном и шумят в логах.

В аттаче к этому посту вы можете видеть пример такой оптимизации. УЧТИТЕ что тут только пример оптимизации, тоесть это только часть политики, а не полная версия. Все это приводиться в качестве примера и ее нужно еще модифицировать с учетом вашего окружения!

Если у вас есть свои трюки и советы по оптимизации Kubernetes Audit Log, то предлагайте в комментариях ;)

На ближайшем DevOpsConf 2023 в Москве наш коллега Станислав Проснеков в рамках доклада "Локальная инфраструктура для разработки K8s-native ПО" расскажет, как у нас устроена разработка и тестирование нашего продукта Luntry по защите Kubernetes. Во главе угла тут стоит наша другая внутренняя разработка (она и главный герой презентации – пару слов о ней я уже писал тут), которая в несколько кликов для разработчиков и тестировщиков позволяет за несколько минут создать один из 1050 вариантов (и эта цифра продолжает расти) возможных конфигураций Kubernetes инфраструктур!

Это не только удобно при отладки тех или иных кейсов клиентов, к инфраструктурам которых у нас нет доступа, но и для R&D когда мы проверяем разные трюки, фичи и наши гипотезы по защите и атаке Kubernetes инфраструктур. В общем в полной степени развязывает нам руки =)

В продолжение вчерашнего поста, хочется поделиться ещё одним ресерчем. Kubernetes in the wild report 2023 – довольно интересное исследование по использованию Kubernetes в компаниях в production среде.

Вот ключевые моменты из этого репорта:

- Kubernetes moved to the cloud in 2022
- Kubernetes infrastructure models differ between cloud and on-premises
- Kubernetes is emerging as the “operating system” of the cloud
- The strongest Kubernetes growth areas are security, databases, and CI/CD technologies
- Open-source software drives a vibrant Kubernetes ecosystem
- Java, Go, and Node.js are the top 3 programming languages for Kubernetes application workloads

Тут хорошие ребята запустили исследование состояния DevOps в РФ 2023. Сcылка на сам опросник ТУТ. Если вам несложно и есть чем поделиться с сообществом, то будет здорово если вы поучаствуете в этом исследовании и внесете свой вклад в развитие нашей индустрии ;)

P.S. Результаты предыдущего исследования за 2021 год можно посмотреть тут.

Отличный специалист Rory McCune начал очередной цикл статей (думаю все помнят его цикл статей про PCI DSS в Kubernetes) "Container security fundamentals: Exploring containers as processes".

Он доступно, наглядно и с примерами показывает как можно работать с контейнерами теме же инструментами, что вы привыкли работать и с обычными Linux процессами. При этом обращает внимание на то как это затрагивает security, как со стороны защищающегося, так и атакующего. Маленький спойлер: доступ на Node (container escape и т.д.) открывает атакующему аттракцион невиданной щедрости)

Это должно отлично зайти абсолютным новичкам в данной теме. Следите за данным циклом!

Вы знали, что с помощью инструкции COPY в Dockerfile можно копировать любые файлы из интересующего нас образа? Потенциально это позволяет излекать чувствительные файлы без авторизации из любого образа.

Так например из образа madhuakula/hacker-container копируется директория /root/pwnchart в образ alpine по пути /pwnchart.

Импакт может быть довольно существенный, но я надеюсь никто не хранит чувствительные данные внутри контейнера :)

Рассматривая тенденцию ухода от sidecar proxy в Service Mesh, я уже писал, что полностью отказать от них и все перенести в eBPF нельзя. И вот есть прекрасная картинка иллюстрирующая это. С левой стороны, то что можно и уже перенесли в eBPF, а справа что нельзя. Особое внимание заслуживает раздел Security.

В статье Process monitoring: How you can detect malicious behavior in your containers отражены главные мысли по поводу runtime защиты в Kubernetes.

Автор также рассказывает почему традиционные системы мониторинга, типа EDR или AV не применимы в Kubernetes. Единственный правильный способ отслеживать работу приложений в Кубере – собирать информацию на всех уровнях, начиная с инфраструктуры и заканчивая самим приложением, работающим в контейнере. Используя при этом такие механизмы как eBPF, ptrace, kprobes.

Далее описываются основные техники и способы выстраивания такого рода мониторинга:

- Kubernetes Audit Log
- Сбор логов с инфрастуктуры
- Отслеживание и блокировка syscalls, а также изменений файловой системы контейнера
- Использование NetworkPolicy
- Приостановка контейнера (DFIR)

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

Наткнулся тут на любопытную заметку "Restricting cluster admin permissions", где ребята показали как они с помощью политики Policy Engine Kyverno ограничивают права высоко привилегированного пользователя с Cluster Role cluster-admin (и не только, в политике вообще есть раздел subjects). Напомню что штатными средствами Kubernetes отбирать права нельзя.

На этой волне я вспомнил свою идею, про приманку (honeytoken) в виде заманчивого/привилегированного SA token, который может получить злоумышленник, а мы его поймать и не дать сделать ничего критичного с помощью этого SA token =)

Если вы не очень понимаете о чем я, то рекомендую посмотреть мой доклад "Безопасность Kubernetes: Фаза Deception".

Часто людей, которые работают с Kubernetes по-шутке называют YAML-программистами.

Сегодня делюсь довольно простой, но очень полезной подборкой трюков и фишек при работе с YAML в Kubernetes.

Помимо этого, вам также могут быть полезны следующие инструменты:

- Online YAML linter
- YAMLLint
- VS Code YAML extension
- yq

Стал доступен отчет security audit для проекта CNI Cilium. Помимо списка найденных проблем и баг (22 всего) для широкой аудитории определенно будет интересно и полезно ознакомиться составленными для данного проекта:
- Cilium architecture
- Threat actor enumeration (на скриншоте)
- Threat surface enumeration

К сожалению, аудиторы совсем не уделили внимание вот этому странному моменту с identity о котором я писал ранее.

Вы знали, что можно отслеживать кто и когда пуллит ваши docker образы? В статье “Fun with Containers – Adding tracking to your images” как раз рассказывается об этом.

Тут очень важно отметить, что используется OCI image spec, а не дефолтный образ формата Docker, который обычно получается после сборки. OCI image spec довольно обширна и включает в себя большое количество компонентов. Одним из таких компонентов является descriptor с необязательным (!) полем urls, куда как раз-таки можно подложить вебхук.

В статье автор показывает, как модифицировать образ, добавив туда дополнительное поле, пофиксить возникающие из-за этого проблемы и отгрузить image в registry. В конце приводятся примеры прилетающих запросов.

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

Маленькая познавательная статья "The life of a DNS query in Kubernetes" о работе DNS в K8s.

Будет полезна как для общего понимания работы приложений в Kubernetes, так и для проведения сетевых атак в нем ;)

Если по какой-то причине вам нужно мигрировать с политик OPA Gatekeeper на Kyverno – вот отличная заметка о том, как это сделать.

Схема довольно простая: ставим в кластер Kyverno (OPA уже был), раскатываем соответствующие политики Kyverno в audit режиме, смотрим на то как они себя ведут, если всё ок – переводим политики Kyverno в enforce режим, а OPA политики сносим.

Но не стоит забывать о существовании Mutation policy, ведь там всё может быть немного сложнее. Дело в том, что две работающие Mutation политики от разных Policy Engine могут привести к перезаписи объектов. Для таких случаев, и вообще любых других случаев, где вы сомневаетесь в том как работает политика есть команда kyverno test (почитать про неё можно здесь).

Также авторы прикладывают таблицу смапленных политик Kyverno и OPA Gatekeeper.

В официальной документации Kubernetes есть замечательная страничка "Deprecated API Migration Guide", которая будет полезна как опытным специалистам, так и только начинающим. Kubernetes активно развивается и ряд фичей (API) не проходят испытание временем по тем или иным причинам (порой совсем непонятным).

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

Например, Helm у себя в секретах в списках релизов чарта хранит все манифесты. В итоге в процессе установки новой версии чарта (обновления чарта) после обновления Kubernetes, обновляем чарт на новые версии, манифесты, задеплоенные в Kubernetes он обновляет самостоятельно. При этом то, что Helm положил в историю релизов остается нетронутым. При апгрейде запускается процедура трехстороннего мержа, Helm достает из секретов сохраненные манифесты с deprecated version и пытается отдать их API куба. И в результате все падает с невразумительными ошибками …

Также стоит знать что есть и разные вспомогательные инструменты: kube-depre, pluto, kubepug, kube-no-trouble, ...

P.S. За идею поста и почти за весь пост - спасибо читателю канала ;)