На канале не раз упоминалось о важности сбора и анализа SBOM (1,2,3). Более того, этот функционал есть и в нашем Luntry. При сборе SBOM, довольно трудно понять насколько полноценную информацию удаётся собрать.

Сегодня хочу поделиться инструментом, который поможет количественно оценить сгенерированный SBOM. В sbom-scorecard довольно большая система метрик, по которым выносится конечная оценка SBOM (она еще развивается и дополняется):

- Spec compliant
- Generation Info
- IDs
- Versions
- Licenses

Тулзу можно попробовать и без установки. Для этого достаточно перейти на сайт и загрузить SBOM.

Наше с коллегой выступление "eBPF в production-условиях" с конференции HighLoad++ Foundation 2022 в Москве стало доступно и в текстовом формате на Хабре (слайды и видео доступны тут). Материал до сих пор актуальный, в данном вопросе пока ничего не поменялось.

Почти год назад на канале был пост, в котором рассказывалось каким образом можно посмотреть и где найти в коде встроенные системные Roles, ClusterRoles, RoleBindings и ClusterRoleBindings в Kubernetes.

Недавно, мне самому понадобилось собрать такую информацию – и решение проблемы оказалось очень простым! Оказывается, что все системные Roles, ClusterRoles, RoleBindings и ClusterRoleBindings имеют лейбл kubernetes.io/bootstrapping=rbac-defaults. Поэтому для того чтобы получить список встроенных объектов RBAC достаточно выполнить команду:

kubectl get roles,rolebindings,clusterroles,clusterrolebindings -A -l kubernetes.io/bootstrapping=rbac-defaults

Kubernetes постоянно развивается – где-то заезжают новые фичи, где-то отказываются от того, что не зашло. Это также отражается и на встроенных RBAC объектах. Если сравнить две мажорные версии кубера, можно заметить, что количество ClusterRoles в них отличается.

P.S. Читайте документацию =)

P.S.S. Лейбл можно накинуть на любой не кастомный объект RBAC

Очень оперативно на YouTube уже стали доступны выступления с первого дня CloudNativeSecurityCon 2023 в Seattle (это уже порядка 45 докладов), о котором я писал недавно. Думаю, что со второго дня все доклады будут доступны уже завтра! Также на сайте в разделе программа для некоторых докладов доступны и слайды ;)

На днях вышла новая версия Kyverno – 1.9. Нововведений достаточно много, но интересными мне показались следующие:

– Policy Exceptions . Это новый CRD, в котором можно указывать исключения для политик. По сути, это такой своего рода bypass, для уже действующих политик в кластере. Безусловно, возможность создания таких ресурсов нужно ограничивать RBAC.

– Cleanup Policies. Еще один новый CRD. Позволяет подчищать кластер от ненужных ресурсов, поддерживает JMESPath и всё это работает в формате CronJob – по заданному расписанию.

Настоятельно рекомендую обновиться тем, кто уже использует Policy Engine у себя в кластере, а тем, кто ещё не дошел до этого – почитать о его пользе и необходимости [1, 2], при выстраивании Defence-in-Depth в Kubernetes.

Доносятся последние отголоски наших прошлогодних выступлений - на Хабре стала доступна статья по мотивом выступления "SOAR в Kubernetes малой кровью".

И мы уже с нашей командой Luntry создаем новый уникальный контент на этот год! Среди тем которым мы уже точно затронем:
- Причудливости и премудрости Kubernetes RBAC
- Альтернативный взгляд на матрицу угроз для Kubernetes
- Жизнь с AppArmor в Kubernetes
- Специализированный образ для pentest в Kubernetes
- Уровни зрелости при работе с уязвимостями в образах контейнеров

При этом уже есть первый анонс - "Локальная инфраструктура для разработки k8s-native ПО", что прозвучит на DevOpsConf 2023!

Сегодня хочу рассказать про очень крутой dashboard для Grafana – Cilium Policy Verdicts. Если вы смотрели доклады с прошедшего CloudNativeSecurityCon 2023, то должны были его заметить :)

С помощью него можно удобно смотреть в каких моментах Egress или Ingress политика пропустила трафик, а в каких нет. Будет очень полезным, если вы хотите убедится в том, как работают сетевые политики, примененные к workloads. Есть удобные фильтры по namespace.

Чтобы всё заработало, предварительно, при установке Cilium нужно включить метрику hubble_policy_verdicts_total.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В статье 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)

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

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

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

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

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

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

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

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

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

В продолжение вчерашнего поста, хочется поделиться ещё одним ресерчем. 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