DevSecOps Talks

И тот самый CIS Software Supply Chain Security Guide.

Документ «разбит» на части:
🍭 Source Code
🍭 Build Pipelines
🍭 Dependencies
🍭 Artifacts
🍭 Deployment

Каждый из вышеуказанных разделов содержит небольшие подразделы, всего в документе ~ 66 страниц. Приятного изучения!

Chain-Bench от Aqua Security: анализ безопасности Software Supply Chain

Всем привет!

Недавно и без того немалое семейство OSS продуктов от Aqua Security (которое включает в себя Kube-Bench, Kube-Hunter, Trivy, TFSec, Postee, Tracee, Starboard) пополнилось еще одним решением – Chain-Bench!

В отличие от своих «братьев и сестер» Chain-Bench направлен на анализ не k8s, а… Software Supply Chain.

«Под капотом» все достаточно стандартно:
🍭 Набор OPA-проверок, реализующих CIS Software Supply Chain Security Guide
🍭 И поддержка GitHub (надеемся, что будет расширение)

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

Кстати, тот самый CIS также вышел совсем недавно (июнь 2022). Его мы приложим сразу после этого поста.

И в заключение немного про Trivy! В последнем release (0.29.0) была добавлена возможность анализ RBAC k8s и не только! Подробнее можно прочесть тут.

Хранение k8s Secrets в git с использованием Bitnami Sealed Secrets

Всем привет!

Если вы любите/хотите использовать IaC подход при работе с Kubernetes, то он «сработает» для всего, за исключением Secrets.

Для решения этой задачи ребята из Bitnami сделали (и продолжают развивать) open source продукт Sealed Secrets.

В статье приводится обзор технологии и пример использования. Само решение состоит из нескольких компонентов:
🍭 Утилита/агент Kubeseal. Ее задача «создавать» Sealed Secret, в котором будет зашифрован интересующий нас Kubernetes Secret
🍭 Cluster Controller/Operator. Его задача следить за «трансформацией» (расшифровкой и превращением Sealed Secret в Kubernetes Secret). У него есть API endpoint, через который с ним можно взаимодействовать

Помимо этого, есть готовый dashboard для Grafana – на нем можно посмотреть сведения о Unsealed Secrets и ошибках.

Если хочется узнать больше, то рекомендуем ознакомиться с информацией в repo. Там, помимо прочего, есть сведения о ротации секретов и что под этим понимается в Sealed Secrets.

Deserealization Labs

Всем привет!

Ребята из NotSoSecure подготовили playground, посвященный уязвимостям, связанным с десериализацией (deserealization).

Он представляет из себя виртуальную машину, в которой собраны уязвимые приложения, написанные на:
🍭 Java
🍭 PHP
🍭 Python
🍭 Node

При решении лабораторных можно воспользоваться Serialized Payload Generator. А если совсем не получается, то в repo есть ссылки на решения, в которых все детально описано.

P.S. Все материалы, связанные с offensive предназначены только для обучения.

Chaos Engineering в Expedia Group

Привет!

Отличная статья, посвященная развитию практики Chaos Engineering в Expedia Group. В ней описан полный жизненный цикл – от идеи до реализации.

Авторы прошли следующий путь:
🍭 Понимание важности анализа доступности сервисов при различных обстоятельствах («смерть» pod, ограничение пропускной способности сети, наличие disk pressure и т.д.)
🍭 Выбор инструмента (spoiler: им стал Chaos Controller от DataDog)
🍭 Определение актуальных сценариев (fault injection) для Компании
🍭 Интеграция с кластером k8s, системами мониторинга, CD (в качестве которой был Spinnaker)
🍭 Создание собственного продукта – Chaos Engineering Product – который включил в себя опыт, полученный при реализации предыдущих этапов

Каждый шаг пути неплохо описан в статье, есть примеры и объяснения, как ребята к этом пришли. Отдельно рекомендуем прочитать про Chaos Controller от DataDog и примеры его использования.

Kubernetes Secrets: так ли небезопасно?

Всем привет!

Известно, что Secrets в Kubernetes это просто base64 encoded строка. В связи с этим очень часто встречается мнение, что это не безопасно и надо управлять секретами как-то «иначе».

В статье Автор пытается разобраться, а так ли это на самом деле? Он рассматривает следующие возможные угрозы:
🍭 Извлечение секретов из памяти
🍭 Root-доступ на Master/Worker Nodes
🍭 Физический доступ к Control Plane node
🍭 Иные атаки, которые могут появиться в будущем

Далее для каждой из них он описывает возможные способы противодействия – от использования возможностей k8s до применения key management systems (в том числе HashiCorp Vault).

Какой вывод сделал Автор? Рекомендуем прочитать статью, чтобы узнать ответ: она достаточно короткая и в ней много полезных размышлений.

Kubernetes API Server: что внутри?

Всем привет!

Когда схематично отображают архитектуру Kubernetes, зачастую рисуют всего один «квадратик» для обозначения API Server. Но так ли это?

Есть две статьи, которые отлично описывают, что происходит, когда выполняется команда kubectl apply -f pod.yaml.

В первой меньше деталей, но очень наглядно и понятно описываются шаги:
🍭 Получение запроса HTTP Handler’ом
🍭 Аутентификация (есть ли у вас доступ к кластеру)
🍭 Авторизация (можете ли вы делать то, что собрались)
🍭 Mutation Admission Controller (добавление «недостающего», например, ImagePullPolicy: always, если вы не указали иное)
🍭 Schema Validation (убеждаемся, что «все на своих местах и ничего не забыто»)
🍭 Validation Admission Controller (можно ли создать то, что вы просите? А если указан валидный, но не существующий Namespace?)
🍭 Resource Handler (десериализация сущности, создание объекта в памяти и помещение в etcd)

При этом многие из указанных «уровней» можно расширять – Mutating (например, Istio или Vault, которые добавляют свои параметры на основе аннотаций), Validating (тот самый OPA Gatekeeper и Kyverno), можно даже регистрировать собственные API. Да, k8s по факту – это большой «конструктор».

Во второй статье в разы больше деталей. Она дает еще большее представление о том, что происходит «под капотом»!!!

Поэтому, для беглого ознакомления рекомендуем прочесть первую статью (~ 4 минуты), а для вдумчивого погружения, когда есть достаточно времени – вторую.

Шифрование трафика в Kubernetes

Всем привет!

Первое, что приходит на ум при фразе «шифрование трафика в Kubernetes» - использование Service Mesh и их функционала mTLS.

Но что, если по какой-то причине не хочется использовать указанную выше технологию? Можно ли решить задачу как-то иначе?

В статье Автор рассматривает вариант использования Cert Manager. Сам подход состоит из нескольких этапов (при условии, что Cert Manager уже установлен и произведена базовая настройка):
🍭 Создание Issuer для CA-сертификата
🍭 Выпуск CA-сертификата
🍭 Распространение CA-сертификата во все необходимые namespace с использованием возможности Trust от Cert Manager (по факту – создание ConfigMap с необходимыми данными)
🍭 Создание ClusterIssuer для выпуска сертификатов
🍭 Выпуск сертификата и его дальнейшее использование

Больше про возможности Cert Manager можно прочитать в документации, доступной по ссылке.

Развитие проекта Horusec

Всем привет!

В 2020 году мы писали про проект Horusec – multi-tool из различных инструментов по анализу кода. На тот момент он включал в себя не так много решений, а документация была… на португальском!

Прошло 2 года… Проект не только обзавелся отличным сайтом, но и развил свой функционал. И да, появилась документация на английском!

Что есть внутри:
🍭 Cli, запуск которой анализирует на чем написан код и выбирает оптимальный инструмент анализа
🍭 Web-Application – по факту console, в которой отображаются результаты, есть различные метрики: уязвимости по разработчикам/языкам/проектам, сводная информация по уязвимостям во времени и т.д.
🍭 Количество «встроенных» инструментов также увеличилось. Теперь внутри содержатся: Bandit, Checkov, GitLeaks, GoSec, TFSec, Trivy, DependencyCheck и другие.
🍭 Работает в нескольких «режимах»: SAST, Leaks и Dependency Audit

Изменений/нововведений крайне много, поэтому рекомендуем ознакомиться с документацией.

Предотвращение tag mutation с использованием kbld и ArgoCD

Всем привет!

Существует хорошее правило не использовать tag: latest при разворачивании чего-либо в средах контейнерной оркестрации. Впрочем, это применимо не только к образам контейнеров, но и к зависимостям, артефактам и т.д.

Более того – это правило можно расширить еще больше и применить ко всем tag, т.к. не всегда можно гарантировать на что именно ссылается этот самый tag. С другой стороны, он всегда будет ссылаться на уникальный image digest.

Авторы статьи размышляют над тем, как можно проще перейти на использование этих самых digest. Одной из проблем является то, что они не очень human readable, длинные и есть вероятность ошибки/описки.

Для того, чтобы автоматизировать процесс работы с ними можно использовать kbld – open source утилиту, которая, в том числе обладает функционалом «замены» явного указания image:tag на его digest.

Далее, можно автоматизировать deploy процесс при помощи ArgoCD, ведь он отлично «понимает» манифесты, которые были сгенерированы при помощи kbld.

P.S. Если кто-то хочет посмотреть на это «в действии», в статье есть ссылка на youtube-ролик с демонстрацией.

Всем привет!

ESO – это Kubernetes оператор (набор CRD), который интегрируется с внешними системами управления секретами (такими как HashiCorp Vault, Senhasegura и пр) и синхронизирует получаемые значения в объекты Secret кластера. Хотя, кроме систем управления секретами, возможна интеграция как с GitLab, так и с Kubernetes. Полный перечень систем представлен в документации вместе с примерами настройки.

Устанавливается ESO в кластер через HELM. После установки необходимо создать:
🍡Secret с токеном для подключения
🍡SecretStore (или ClusterSecretStore) с конфигурацией подключения к системе управления секретами и референсом на секрет
🍡ExternalSecret (или ClusterExternalSecret) с конфигурацией самого секрета и референсом на SecretStore

В случае успеха новые Secrets создаются в кластере, которые в дальнейшем могут использоваться приложениями (в случае изменения секрета на уровне системы, они автоматически синхронизируются с кластером). Более подробную информацию можно почитать тут - https://external-secrets.io/v0.5.6/

Инъекция PKI-сертификатов в pod при помощи HashiCorp Vault Agent Injector

Привет!

В статье приводится небольшой how2guide, посвященный тому, как можно «подставлять» PKI-сертификаты в pod с использованием Vault Injector. Включая PKI, которые НЕ были сгенерированы самим HashiCorp Vault.

Сам Injector представляет из себя Kubernetes Mutating Webhook, который подставляет данные в конфигурацию pod на основе указанных аннотаций (annotations), что позволяет ее изменять (mutate).

В статье рассмотрены следующие шаги:
🍭 Установка HashiCorp Vault
🍭 Создание сертификатов с использованием openssl, помещение их в хранилище Vault (pki secret engine)
🍭 Создание роли (role) и политики (policy) с указанием возможных действий ранее созданной роли
🍭 Настройка метода аутентификации Kubernetes
🍭 Тестирование собранной конфигурации на примере pod

Что хорошо – в статье есть не только сами команды, но и описание того, что именно делает Автор. Есть захочется повторить самостоятельно, то ссылку на repo с необходимыми материалами можно найти тут.

Несколько контейнеров в pod: различные patterns

Всем привет!

Обычно, когда слышишь о том, что в одном pod есть несколько контейнеров, то на ум приходят sidecar контейнеры и init-контейнеры (чуть реже). Однако, их несколько больше. Если обобщить, то основная задача приведенных ниже patterns – дать некоторый функционал приложению без непосредственного изменения исходного кода этого самого приложения.

Есть несколько patterns, которые применяются:
🍭 Ambassador. Пример – создание TLS-соединения за счет использования Nginx внутри pod, который будет терминировать трафик. В этом случае трафик до Nginx будет шифрован, а между Nginx и другими контейнерами внутри pod – нет.
🍭 Adapter. Пример – добавления контейнера, который будет выполнять роль Prometheus Exporter для ElasticSearch.
🍭 Sidecar. Пример – сбор логов в stdout, в случае если приложение не поддерживает такой формат предоставления логов и пишет все в файл.
🍭 Init. Запуск контейнера, который делает «предварительную работу» для запуска основного приложения.

Если тема вам интересна, то рекомендуем прочесть статью, в которой подробно разбираются рассмотренные выше patterns. Все наглядно, с примерами и ссылками на иные источники для более детального ознакомления с темой. Кстати, есть еще очень интересная статья от Google по этой тематике (небольшая, 6 страниц А4).

Прохождение Insekube CTF

Привет!

Insekube CTF - набор интерактивных заданий, реализация которых позволит получить заветный "флаг". Для каждого шага есть подсказки/намеки на то, как его можно реализовать.

В статье описаны шаги, которые предпринял Автор для прохождения Insekube CTF. Ресурс доступен, поэтому вы можете попробовать пройти СTF самостоятельно до прочтения статьи.

Путь решения CTF, предлагаемый Автором:
🍭 Enumeration и получение «хоть-какой-нибудь» информации о кластере
🍭 Reverse shell через уязвимость приложения, запущенного на кластере
🍭 Discovery: поиск уязвимых компонентов, которым стала Grafana
🍭 Подбор данных для эксплуатации уязвимости CVE-2021-43798 (Path Traversal) в Grafana для получения Token
🍭 Подготовка и запуск pod, содержащего hostPath и privileged с последующим «побегом» на node

Все достаточно детально описано, с примерами и пояснениями для самостоятельного воспроизведения.

IDE plugin Trivy для VS Code

Всем привет!

Проект Trivy продолжает активно развиваться, добавляются новые функции и улучшается опыт использования (user experience).

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

Он позволяет запускать сканирования из IDE, а удобный Findings Explorer упростит процесс анализа ИБ-дефектов за счет структурирования результатов и «подсвечивания» проблемных участков.

P.S. О недавнем обновлении Trivy с новым функционалом мы писали тут.

Вопросы и задачки по DevOps

Привет!

По ссылке доступна подборка, в которой содержатся вопросы и упражнения по тематике DevOps. Если верить описанию repo, то сейчас в ней 2292 вопроса/упражнения!

Все удобно структурировано по тематикам, например:
🍭 Continuous Integration и Continuous
🍭 Delivery
🍭 Ansible
🍭 Git
🍭 Containers
🍭 Operating System и многое другое

Подборку можно использовать по-разному: узнать новое, проверить собственные силы, взять вопросы для собственного quiz на очередном meetup/hackathon для развлечения аудитории и многое другое!

ИБ-практики при использовании ArgoCD

Привет!

Еще одна неплохая обзорная статья про безопасность при использовании ArgoCD. Про общие практики использования ArgoCD, не имеющие отношения к ИБ мы писали тут.

Автор выделяет следующие области:
🍭 Use a dedicated project for the control plane. Рекомендации GitOps практик при управлении GitOps Control Plane ArgoCD
🍭 Argo resources are for Argo admins only. Ресурсы группы argoproj.io должны быть только в тех repo, которые принадлежат администратором ArgoCD
🍭 Delete the “default” project. Удаление «базового» проекта, создаваемого по умолчанию
🍭 Block ClusterRoleBindings in (most) projects. Управление доступом (least privilege) на уровне кластера
🍭 Narrow roles on remote clusters. Корректное управление доступом при управлении несколькими кластерами при помощи одного instance ArgoCD
🍭 Have a CVE response plan ready. Создание процесса управления уязвимостями

Для каждой из вышеуказанных тем приводится обоснование «почему это важно?» и советы о том, как это можно реализовать. Кстати, у самого проекта ArgoCD есть раздел, посвященный информационной безопасности.

Лабораторные работы по eBPF

Всем привет!

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

На текущий момент доступны следующие лабораторные работы:
🍭 Getting Started with Cilium OSS
🍭 Getting started with Isovalent Cilium Enterprise: Network Policies
🍭 Getting started with Isovalent Cilium Enterprise: Connectivity Visibility
🍭 Getting Started with eBPF
🍭 Security Observability with eBPF and Cilium Tetragon

Лабораторные работы имеют разный уровень сложности – от beginner до advanced. Для доступа к материалу надо указать немного информации о себе – ФИО, почта (можно указать персональную) и т.д. По времени – от 30 минут до 1 часа, теория и практика.

Возможное количество TCP-соединений

Всем привет!

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

Началось все с того, что Автор видел множество размышлений в стиле: «Всего 65 536 TCP портов (2^16), значит только 65 536 клиентов могут установить соединение с 1 TCP-сервером».

Тогда как различные компании поддерживают миллионы соединений? Они обманывают? У них стоит много-много-много серверов и балансировка? «Что-то тут не так…» - подумал Автор и решил посчитать самостоятельно.

Ответ Автора – 2^48, а это очень большое число. Почему это так – описано в статье, основная суть в том, что для listening-порта входящие соединение не «поглощает/занимает» порт на сервере.

А если хочется проверить вручную, то и это возможно – Автор написал простенькую программу, при помощи которой можно реализовать PoC.

Инструкция: Cosign + Gatekeeper

Всем привет!

Подпись образов – важный аспект информационной безопасности, про который мы уже писали и не раз.

Если есть общее понимание, но хочется простой и понятной конкретики «А как сделать-то?», то рекомендуем обратить внимание на эту статью.

В ней детально (с примерами кода и конфигураций) объясняется следующее:
🍭 Создание job в CI-pipeline для подписи образа (в примере используется Tekton, но сам подход запросто можно адаптировать по ваши CI)
🍭 Создание ContsraintTemplate и самого Constraint для Gateeper с целью проверки валидности (наличия) подписи у образа
🍭 Настройка External Data Provider для Gatekeep, чтобы он умел «общаться» с Cosign. Для этого используется официальное решение от Sigstore – Cosign-Gatekeeper-Provider
🍭 Небольшой тест созданной конфигурации

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