DevSecOps Talks

Генерация SBOM при помощи Trivy

Всем привет!

В статье описано, как можно генерировать SBOM при помощи Trivy. В начале приводится общая информация о том, что это такое, о форматах (SPDX/CycloneDX) и их отличиях.

Далее всего несколько команд, чтобы можно было:
🍭 Получить перечень пакетов: trivy -q image --ignore-unfixed --format json --list-all-pkgs %imagename%
🍭 Сделать из нее SBOM: trivy -q image --format cyclonedx %imagename%

В одной из последних версий процедуру еще больше упростили, добавив команду sbom (рекомендуем обновиться, если она отсутствует).

На текущий момент времени Trivy позволяет генерировать SBOM только в формате CycloneDX.

Отдельно рекомендуем изучить trivy sbom --help. Можно найти много интересного, например, --artifact-type, который позволяет создавать SBOM для image, fs, repo и archive или --severity, который позволит контролировать уязвимости, попадающие в выборку

Шифрование данных в etcd

Всем привет!

В статье представлен пример того, как можно шифровать секреты, хранимые в etcd (data at rest encryption).

Процедура достаточно простая:
🍭 Необходимо сгенерировать произвольный ключ, который будет использован для шифрования
🍭 Подготовить манифест для kind: EncryptionConfiguration, указав в нем недавно созданный ключ
🍭 «Активировать» флаг --encryption-provider-config=%path/to/file% в манифесте kube-apiserver
🍭 Настроить необходимые mounts и готово! Все «вновь созданные секреты будут зашифрованы в etcd.

Что делать с теми, что уже были? Ответ можно найти в статье, также как и информацию по обновлению (ротации) используемого ключа шифрования.

Кстати, это еще и одна из рекомендаций – 1.2.30, прописанная в CIS Kubernetes Benchmark, v1.23. При помощи подобного подхода можно шифровать не только Secrets, но и другие ресурсы. Подробности описания компонентов манифеста можно посмотреть в документации.

Обратная процедура – «расшифровать все» проста: необходимо поместить параметр identity: {} первым в списке providers

Анализ API-трафика

Всем привет!

Mizu – удобный инструмент, который позволяет анализировать API трафик микросервисных приложений для поиска ошибок (troubleshooting).

При помощи Mizu можно анализировать HTTP запросы, REST и gRPC API вызовы.

Решение обладает минималистичным web-интерфейсом, в котором собрана информация о запросах, представлены детали о Request/Response.

Еще одной возможностью Mizu является составление Service Dependency Map – наглядного графического представления о взаимодействии сервисов.

Как обычно, больше информации можно посмотреть в документации.

Open source web scanners

Всем привет!

В repo собрана небольшая подборка по доступным OSS web-scanners.

Автор структурировал ее на блоки:
🍭 General Purpose Web Scanner (ZAP, Arachni, Hetty и т.д.)
🍭 Infrastructure Web Scanner (Nuclei, Nikto, Tsunami и т.д.)
🍭 Fuzzers / Brute Forcers (Dirsearch, Ffuf, Wfuzz и т.д.)
🍭 CMS Web Scanners (WPScan, Volnx, CMSScan)
🍭 API Web Scanners (Automatic API Attack Tool и Cherrybomb)
🍭 Specialized Scanners (SQLmap, Comix, XSSScrapy)

Удобно, что в самой repo есть информация о последнем commit, contributors и количестве «звездочек». Кроме того, есть несколько ссылок на аналогичные подборки от OWASP и не только

CI/CD Goat (заведомо уязвимый CI/CD)

Привет!

Ребята из Cider Security подготовили repo, который позволяет провести небольшой CTF в CI/CD. «Испытуемое окружение» состоит из Gitea, Jenkins, LocalStack и Lighttpd.

В качестве «вдохновения» авторы использовали собственные наработки, посвященные уязвимостям, которые могут быть характерны для сборочного контура.

В CTF можно найти 10 challenges:
🍭 Insufficient Flow Control Mechanisms
🍭 Inadequate Identity and Access Management
🍭 Dependency Chain Abuse
🍭 Poisoned Pipeline Execution (PPE)
🍭 Insufficient PBAC (Pipeline-Based Access Controls)
🍭 Insufficient Credential Hygiene
🍭 Insecure System Configuration
🍭 Ungoverned Usage of 3rd Party Services
🍭 Improper Artifact Integrity Validation
🍭 Insufficient Logging and Visibility

Рекомендуем прочесть информацию на сайте Cider Security или на их GitHub про уязвимости в CI/CD. С одной стороны – полезно, с другой – может помочь при решении challenges

Синхронизация ConfigMap/Secret между Namespace и не только

Всем привет!

Config Syncer (ранее – Kubed) – утилита, которая позволяет синхронизировать данные ConfigMap и/или Secret между namespace и/или cluster.
Для чего это может быть применимо?

Например, требуется, чтобы во всех или в нескольких namespaces был один и тот же Secret, который содержит данные для ImagePull. Или для распространения и поддержки в актуальном состоянии любых других ConfigMap/Secret, которые используются более чем одним namespace или cluster.

Небольшой сценарий использования представлен в документации:
🍭 Создается базовый (source) ConfigMap в Namespace “Demo”
🍭 К нему добавляется одна annotation: kubed.appscode.com/sync: ""
🍭 После этого все namespace (как существующие, так и вновь созданные) получат этот ConfigMap
🍭 В случае, если произойдет обновление (в примере меняют “leave” на “live” в блоке data), то ConfigMap обновится везде.

Возможна гибкая настройка Config Syncer: можно управлять перечнем namespace, которые будут получать ConfigMap/Secret, можно их удалять.

Об установке, параметрах конфигурации и иных сценариях использования можно прочитать в документации.

Vault plugin для ArgoCD

Привет!

По ссылке доступен plugin, который позволяет упростить получение секретов из Vault при использовании ArgoCD.

На текущий момент поддерживаются следующие типы Vault backends:
🍭 HashiCorp Vault
🍭 IBM Cloud Secrets Manager
🍭 AWS Secrets Manager
🍭 GCP Secret Manager
🍭 AZURE Key Vault
🍭 SOPS
🍭 Yandex Cloud Lockbox
🍭 1Password Connect

Ставится просто и быстро, а для инъекции секретов необходимо указать требуемые параметры в annotations для последующего извлечения секрета по пути.

О настройках определенных типов backend можно посмотреть в документации – все детально и с примерами.

Добавление прав в Kubernetes

Привет!

В одном из предыдущих постов мы писали про то, как предоставить доступ к кластеру Kubernetes (AuthN – authentication).

Закончилось все тем, что у пользователя нет никаких полномочий что-либо делать, ведь вопросы AuthZ (authorization) не были адресованы.

В продолжении Автор описывает, что из себя представляет ролевая модель Kubernetes на базе RBAC и как ее настроить.

Рассматриваются такие аспекты как:
🍭 Какие бывают роли?
🍭 Из чего состоит роль в Kubernetes?
🍭 Кому и как можно назначать роли?
🍭 Примеры, примеры и еще раз примеры

Статья достаточно базовая, но в ней все очень удобно собрано и детально объясняются очень значимые вещи, особенно с точки зрения информационной безопасности.

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

Identity provider на базе Authentik

Всем привет!

Authentik – open-source identity provider, который можно использовать для настройки аутентификации.

Из коробки доступны следующие providers:
🍭 OAuth2
🍭 SAML
🍭 LDAP
🍭 Proxy Provider

Инструмент также позволяет настраивать политики. Например «Have I Been Pwned Policy» проверяет есть ли пароль, созданный пользователем в одноименной базе данных, а политика «Password-Expire Policy» позволяет реализовать механизм ротации паролей.

Вместе, целевая система, политики и providers формируют application, одну из ключевых сущностей Authentik. Именно они будут использованы для дальнейшего подключения к целевым системам.

На сайте можно найти сводную табличку, в которой представлено небольшое сравнение Authentik с Keycloak, MS AD, Okta и т.д.

Кроме того, решение обладает минималистичным web-интерфейсом, в котором можно посмотреть всю необходимую информацию.

P.S. С документацией и исходным кодом можно ознакомиться тут и тут соответственно

Добавление пользователя в Kubernetes

Всем привет!

Ложки пользователей не существует, есть только сертификаты. Наверное, каждый сталкивался с некоторым недоумением, когда пытался понять – а как добавить пользователя для доступа к кластеру Kubernetes? Где вводить логин и пароль? Как их можно посмотреть и т.д.?

Если вам это только предстоит, рекомендуем прочитать статью, в которой описано что к чему на наглядном примере и почему не следует рассматривать процесс добавления пользователей в Kubernetes с «привычной точки зрения».

В статье, в качестве AuthN рассматривается использование X.509 сертификатов и весь путь, который надо пройти:
🍭 Создание ключевой пары, генерация Certificate Signing Request
🍭 Понимание того, какой именно Certification Authority должен его подписать (да, их может быть и скорее всего будет несколько)
🍭 Что делать с полученным Certificate, как его использовать для доступа – использование KubeConfig
🍭 Что такое Context и как его создать; что делать, если надо подключаться к нескольких кластерам и переключаться между Context и т.д.

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

И самое интересное в конце – без корректной Role созданный пользователь может сделать… ничего. Но это уже про AuthZ (авторизацию) и ролевую модель Kubernetes

Исследование на тему HPA

Всем привет!

YoYo-attack - атака, цель которой - использование доступных механизмов по масштабированию ресурсов против объекта, осуществляющего масштабирование.

В статье ребята эмулируют атаку на кластер K8S, расположенный в облаке. Они посылают большое количество трафика, horizontal pod autoscaler (HPA) начинает создавать новые pods. Со временем атака прекращается. Через некоторый промежуток времени (примерно 5 минут, которые, по умолчанию, выжидает HPA для восстановления исходной картины) атака повторяется.

В качестве тестового приложения ребята взяли 4 сервиса. A - взаимодействует с клиентом; B и С взаимодействующие с А и сервис D, который взаимодействует с D.

Вопросы, на которые хотелось найти ответы:
🍭 Как быстро отреагирует кластер и начнет создавать pod?
🍭 Какой сервис (A, B, C или D) будет "отмасштабирован" первым?
🍭 Как быстро, после прекращения атаки, все вернется в исходное состояние?
🍭 Новые реплики какого сервиса будут удалены первыми?

Ответы, графики мониторинга и размышления на тему следующего эксперимента можно найти в статье

Open source версия StackRox!

Всем привет!

После того, как Red Hat купил StackRox в 2021 году ребята создали community для формирования open source версии продукта. И... случилось!!!

Вышла open source версия StackRox, при этом Red Hat продолжит развивать "родственный проект" - Red Hat Advanced Cluster Security for Kubernetes (ACS). ACS позиционируется, как Enterprise-ready.

Функций у StackRox много:
🍭 Анализ всего и вся - dockerfile, образы контейнеров, манифесты и т.д.
🍭 Автоматизация создания Network Policy
🍭 Собственный Admission Webhook
🍭 Профилирование контейнеров и многое другое!

Крайне рекомендуем ознакомиться с документацией, чтобы больше узнать о функционале решения. Документация на ACS и StackRox едина на текущий момент времени.

Отличительной особенностью StackRox является Kubernetes-native подход. Т.е. он никак не влияет на логику работы контейнеров и оркестратора

Vault Agent Injector Tutorial

Всем привет!

В статье приводится много-много-много информации о Vault Agent Injector. Основной его задачей является подстановка (инъекция, injection) секретов в pod, запускаемые в кластере среды контейнерной оркестрации.

Начинается статья с описания принципов работы Agent и того, чем он является – Mutating Webhook, который «перехватывает» события create/update для pod и анализирует их на предмет наличия определенных annotations.

Описывается назначение и функциональная разница Init/Sidecar-контейнеров, которые используются Vault Agent’ом.

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

В завершении статьи приводятся примеры конфигурации Vault и pod’s для того, чтобы реализовать инъекцию секретов через Vault Agent Injector.

Если «никогда не пробовали, но очень хотели» - то статья вам точно подойдет! Все подробно, детально, с большим количеством примеров и пояснений

Анализ состояния ИБ Kubernetes

Всем привет!

В цикле статей (статья 1, статья 2) приводится общая информация о том, как можно получить доступ к кластеру Kubernetes и развить атаку.

Во многом статья базируется на постулате: «Обычно это отключено, но если конфигурация некорректна, тогда…». Приводится много примеров, в том числе команд и описание действий для самостоятельного анализа.

В частности, в статьях рассмотрены такие моменты, как:
🍭 Получение информации об exposed портах кластера
🍭 Взаимодействие с API-endpoints API-server/ETCD для получения информации
🍭 API-запросы к Kubelet, использование утилиты kubelectl для упрощения взаимодействия с API Kubelet
🍭 Получение сведений о Service Account Token и как его можно использовать для развития атаки
🍭 Способы совершения «побега» из контейнера
🍭 hostPathMount и его «особенности» с точки зрения ИБ
🍭 Использование конфигурационного файла kubectl (при условии, что он был компрометирован)

В статье нет «готовых рецептов» как и что сделать, но приводится много справочной информации, к тому же все достаточно удобно структурировано

Уведомления о проблемах в pods

Привет!

Kwatch – утилита, которая позволяет получать информацию о некорректной работе приложений (с точки зрения pods) в режиме реального времени и направлять информацию, например, в Telegram!

Установка и настройка очень просты:
🍭 Необходимо определить количество строк лога, которые хочется получать. Или выбрать вариант – «покажи все!»
🍭 Указать интересующие namespace, pods которых будут проверяться на наличие проблем
🍭 Настроить интеграцию с интересующим messenger
🍭 И установить несколько флагов – например, игнорировать FailedGracefullShutdown или проверки на обновления Kwatch
🍭 Применить подготовленный манифест конфигурации и манифест самого Kwatch

Готово! Кстати, он не требует избыточных полномочий, только ClusterRole с ["get", "watch", "list"] для ["pods", "pods/log", "events"]

Перечень container breakout уязвимостей

Привет!

По ссылке доступна сводная информация об уязвимостях, которые могут привести к несанкционированному доступу из контейнера на уровень хоста или к «побегу из контейнера».

Подборка структурирована следующим образом:
🍭 Linux CVE
🍭 runC CVE
🍭 Containerd CVE
🍭 CRI-O CVE
🍭 Docker CVE
🍭 Kubernetes CVE

Для некоторых уязвимостей, помимо общего описания, приводится дополнительная информация. Например, PoC-реализации или статьи с детальным описанием уязвимости.

Это может быть полезно, например, для изучения принципов «побега из контейнера» или для анализа сред контейнерной оркестрации на предмет отсутствия указанных CVE.

Управление правами Cluster Admin

Всем привет!

Некоторые утилиты, по умолчанию, требуют привилегий Cluster Admin. Это «удобно», но не всегда нужно и зачастую бывает избыточным.
Что можно делать в таких случаях? Вариантов несколько.

Первый – использование принципа «запрещено все, что явно не разрешено». Т.е. можно сделать Role, в которой явно прописать что и с чем можно делать. Однако, такой подход может быть достаточно ресурсоемким.

Второй вариант – использование принципа «разрешено все, что явно не запрещено». И тут появляется сложность: ролевая модель Kubernetes может давать права, но не может их отбирать. Как быть в таком случае?

Ребята из GiantSwarm решили использовать Admission Controller для решения задачи – Kyverno. Они написали политику, которая фильтровала запросы по параметрам – объект воздействия, автор запроса, действие. Таким образом, они смогли "отобрать права" на некоторые действия, даже у Cluster Admin.

Помимо рассматриваемого примера есть еще несколько use case применения Admission Controller применительно к управлению RBAC, которые описаны в статье.

Управление инфраструктурой через… Kubernetes!

Привет!

Любите Kubernetes, любите YAML (вы правда есть?), любите писать CRD и хотите управлять всей инфраструктурой, как сущностями Kubernetes?

Тогда проект Crossplane для вас! Согласно документации, он «превращает ваш K8S кластер в универсальный control plane, что позволяет ему (кластеру) управлять ИТ-инфраструктурой и managed-сервисами».

Работает все это через CRD, которых "из коробки" достаточно много, например:
🍭 Helm
🍭 Terraform
🍭 SQL
🍭 GitLab
🍭 Styra

И другие (полный перечень можно найти по ссылке). После установки и настройки Crossplane создаем YAML-файлы с описанием, например, БД, применяем их на кластере и «общаемся» с ними через знакомые kubectl get ... и т.д.

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

Если хочется узнать больше про архитектуру, сценарии использования, рекомендуем почитать вот этот документ.

P.S. У Crossplane открытая документация, с которой можно ознакомиться по ссылке.

Бесплатные курсы по Dev(Sec)Ops

Всем привет!

По ссылке приводится емкий обзор бесплатных курсов по тематике Dev(Sec)Ops. Примеры того, что можно найти «внутри»:
🍭 GitOps Fundamentals
🍭 Certified Calico Operator: Level 1
🍭 Gitlab 101 Certification
🍭 Elastic Observability Fundamentals
🍭 Introduction to Service Mesh with Linkerd

И много другое! Есть как «просто курсы», так и подборки материалов (видео/статей) по теме, как, например, VMWare Kube Academy или Aqua Cloud Native Academy

Профилирование приложений для оптимизации их работы

Привет!

Для поиска проблем в работающем ПО зачастую обращаются к логам. Но этого может быть не всегда достаточно.

В статье автор предлагает рассмотреть возможность профилирования приложения для идентификации «проблемных мест» (bottlenecks).

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

В качестве инструмента рассматривается open source продукт – Pyroscope. Автор приводит принципы его работы, сведения о поддерживаемых языках и об архитектуре.

В завершении – установка, настройка и несколько примеров встраивания для Python, .Net и Golang.

Полученную информацию можно фильтровать и анализировать для того, чтобы идентифицировать наиболее ресурсоемкие/длительные операции и разбираться «а должно ли оно быть так на самом деле?»

P.S. Ссылка на открытую документацию Pyroscope