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 и примеры его использования.

Deserealization Labs

Всем привет!

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

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

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

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

Хранение 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.

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 и не только! Подробнее можно прочесть тут.

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

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

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

Пропадающие Secrets в Kubernetes

Всем привет!

Интересная статья от Rory McCune, где он размышляет о секретах в Kubernetes. При создании ServiceAccount (SA) Kubernetes создает ей Secret. Но можно сделать и наоборот – при создании Secret с использованием Annotations можно указать к какой SA он должен «прикрепиться».

А что, если указать несуществующую SA? Применить такой манифест получится, в ответ мы получим, что Secret был создан, вот только… его не будет. Rory попробовал сделать аналогичное упражнение с существующей SA – все работает. Забавно, что при Edit-операции и изменения существующей SA на несуществующую Secret опять пропадет. При этом он пропадет и из ETCD.

Причиной стал один их многих Controllers K8S, а именно – Token Controller, который, в том числе «watches ServiceAccount token Secret addition, and ensures the referenced ServiceAccount exists, and adds a token to the Secret if needed», но удаляет ли он что-либо?

Для проверки гипотезы (что Token Controller удаляет Secret при отсутствии валидной SA) Rory сделал простенькую Audit Policy и посмотрел, что именно ему вернет Kube-ApiServer при попытке создания Secret. Итог – "kind": "DeleteOptions". Такое вот интересное поведение, подробнее о котором можно прочесть в самой статье.

State of Open Source Security, 2022 от Snyk

Привет!

В приложении доступен отчет, посвященный безопасности использования open source, подготовленный Snyk.

Внутри можно найти информацию:
🍭 Мнение компаний о важности анализа OSS, наличия практик контроля
🍭 Кто развивает практики обеспечения ИБ OSS
🍭 Небольшая статистика по использованию зависимостей, связанная с языками программирования
🍭 «Каналы» получения информации об уязвимостях и многое другое

Сам по себе отчет достаточно небольшой, всего 35 страниц.

Exposed Kubernetes Clusters

Всем привет!

Ребята из Cyble провели небольшое исследование по анализу кластеров Kubernetes, доступных из сети интернет.

Получились неоднозначные результаты: с одной стороны все не так и плохо, с другой misconfigurations все же встречаются, чем может воспользоваться потенциальный злоумышленник. Самыми частыми exposed ports оказались: 443/6443 и 10250.

Статистика примерно такая:
🍭 ~ 975k вернуло 403 ошибку, forbidden, RBAC «не пропустил»
🍭~ 5k вернуло 401 ошибку, unauthorized
🍭~ 800 вернуло 200 (!), что означает возможность взаимодействия с кластером

Вывод простой – не надо пренебрегать настройками Kubernetes, которыми можно воспользоваться для повышения уровня ИБ кластера. Подробнее с результатами исследования можно ознакомиться в самой статье.

Обучающий курс по Sigstore!

Всем привет!

Недавно ребята из Chainguard совместно с Linux Foundation и OpenSSF запустили бесплатный обучающий курс, направленный на изучение инструментов Sigstore.

Курс включает в себя:
🍭 Introducing Sigstore
🍭 Cosign: Container Signing, Verification, and Storage in an OCI Registry
🍭 Fulcio: A New Kind of Root Certificate Authority For Code Signing
🍭 Rekor: Software Supply Chain Transparency Log
🍭 Sigstore: Using the Tools and Getting Involved with the Community

Курс содержит теоретическую часть и лабораторные работы. После завершения «главы» есть небольшой Knowledge Check, а в самом конце будет Final Exam!

KubeClarity: SBOM и обзор уязвимостей в образах контейнеров

Всем привет!

KubeClarity – инструмент визуализации информации об уязвимостях в образах контейнерах и о том, что находится «внутри» (Software Bill of Materials, SBOM).

Отличительной особенностью решения является наличие графического интерфейса и dashboards, содержащих информацию:
🍭 Уязвимости, которые можно устранить с разбивкой по уровню критичности
🍭 Top 5 уязвимых компонент (приложения, ресурсы, пакеты)
🍭 Тренды по уязвимостям
🍭 Пакеты по типу лицензий
🍭 Пакеты по языкам программирования

В качестве «анализаторов» используются Grype и Syft, которые предоставляют информацию по уязвимостям и компонентному составу.

О том, что еще есть внутри, как установить и какой roadmap развития продукта можно почитать в самой repo.

Buildg: интерактивный debugger для Dockerfile

Всем привет!

При помощи buildg можно упростить процесс поиска ошибок при проработке Dockerfile. При помощи него можно:
🍭 Управлять процессом выполнения команды, устанавливать breakpoints
🍭 Взаимодействовать с образом через interactive shell

С перечнем команд, доступных утилите, можно ознакомиться здесь. А в последнем релизе была добавлена интеграция с IDE (в том числе VS Code), чтобы сделать debug-процесс еще более наглядным и удобным.

Для ознакомления с принципами и процессом работы можно ознакомиться со статьей от Авторов buildg.

Inspektor Gadget: анализ действий контейнера

Всем привет!

Inspektor Gadget – набор утилит, которые могут быть использованы для повышения уровня ИБ кластера.

Функционально он разделен на блоки:
🍭 Advice. Поможет с генерацией network policy на основе анализа трафика или с созданием seccomp профиля через анализ записанных syscalls
🍭 Audit. Передача сведений о syscalls в лог-файл
🍭 Profile. Получение данных о stack traces
🍭 Snapshot. Сбор сведений о запущенных процессах
🍭 Top. «Визуализация» чего-либо (активных сессий, чтения/записи и т.д.)
🍭 Trace. Сведения о создании новых процессов

Функционала достаточно много, рекомендуем ознакомиться с ним лично. Что удобно – для каждой функции есть описание того, что она делает, примеры запуска и наглядные результаты ее работы.

Architecture as Code

Привет!

Многие слышали про Compliance as Code, Infrastructure as Code, Documentation as Code и т.д. Суть простая – описать что-либо в формате исходного кода (будь то конфигурация или описание процесса), разместить на условном GitHub и взаимодействовать (развивать) как с обычным «приложением».

Вероятно, автор Diagrams подумал, а почему бы не сделать такое для описания архитектуры? В итоге получился проект, который поддерживает написание архитектуры на Python для следующих платформ: AWS, Azure, GCP, Kubernetes, Alibaba Cloud, Oracle Cloud.

Например, вот такой код:

# imports

with Diagram("Exposed Pod with 3 Replicas", show=False):
    net = Ingress("domain.com") >> Service("svc")
    net >> [Pod("pod1"),
            Pod("pod2"),
            Pod("pod3")] << ReplicaSet("rs") << Deployment("dp") << HPA("hpa")

Нарисует красивую схему exposed pods, с количеством replica равным 3. Как это будет выглядеть «по факту» можно узнать в документации, а заодно поближе познакомиться с Diagrams.

P.S. Если вам в целом интересна тема автоматизации создания диаграмм/процессов, то рекомендуем обратить внимание вот на эту подборку.

P.P.S. Вообще есть много разных "XXX as Code". В этой статье автор попытался собрать все возможные случаи и их получилось больше 50.

Хранение секретов в git: подходы и способы автоматизации

Всем привет!

Мы писали про разные способы безопасного хранения секретов в git, но нигде не было единого материала, в котором вся эта информация систематизирована и доступно описана.

И вот он появился! Статья от Jann Fischer и Raffaele Spazzoli, посвященная тому, как можно безопасно хранить секреты в git.

Ребята разбирают 2 группы подходов:
🍭 Шифрование секретов в git. При использовании такого подхода в git хранятся секреты в зашифрованном виде (например, Custom Resource – Sealed Secret для k8S). Использование Sealed Secrets, Mozilla SOPS
🍭 Указание «ссылок» на секреты. В этом сценарии в самих конфигурационных файлах хранятся не секреты, а указатели на системы, где эти самые секреты можно получить. Использование External Secrets и Kubernetes Secret Store CSI

Каждый концепт и подход описан, приводятся примеры использования, а также много ссылок на полезные материалы по теме.

«Гигиена» CI/CD credentials

Всем привет!

Статья, в которой собраны размышления о том, как можно повысить уровень ИБ и снизить вероятность компрометации секретов, используемых в CI/CD.

Авторы рассматривают 3 основных вектора:
🍭 Unrotated Static Credentials. В качестве «противодействия» предлагается использование 3-ей стороны и OIDC provider
🍭 Overly Accessible Credentials. Грамотная настройка прав доступа на различных «уровнях» (Global/User/Repo/Branch)
🍭 Credentials Exposed in Console Logs. Использование возможностей по маскированию

Кроме общих рекомендаций приводится небольшой обзор возможностей таких CI/CD-систем как: GitHub Actions, CircleCI, Jenkins и GitLab CI.

Attacking the API: Mindmap инструментов и подходов

Всем привет!

В repo содержится много общей информации, которая может быть полезна, если вы хотите ознакомиться с анализом ИБ API.

Материал разбит на 2 основных блока:
🍭 Recon // Исследование API. Например, HTTP Method Discovery, API Type Discovery и т.д.
🍭 Attacking // Способы атаки на API. Например, Improper Asset Management, Broken User Authentication, Injection и т.д.

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

Визуализация результатов Kube-Bench в Kyverno Policy Reporter

Всем привет!

У Kyverno есть удобный инструмент визуализации данных – Policy Reporter. При помощи него можно посмотреть сводную информацию по проверкам, а также направлять данные и уведомления в такие каналы, как: Grafana Loki, Elastic Search, Slack, Microsoft Teams и т.д.

Еще одной «особенностью» Policy Reporter является возможность его расширения. Например, можно сделать так, чтобы результаты Kube Bench отображались прямо в интерфейсе.

В статье описан простой алгоритм достижения цели:
🍭 Установить Policy Reporter
🍭 Добавить Policy Report CRD
🍭 Установить Kube-Bench Adapter для Policy Reporter (написанный ребятам из Nirmata)

Готово! При желании можно написать собственные CRD и добавить их в общий Dashboard.

P.S. С документацией Policy Reporter можно ознакомиться по ссылке.

Salus: SBOM Tool от Microsoft

Всем привет!

Тематика анализа и контроля состава ПО становится все актуальнее. И вот недавно Microsoft сделали проект Salus «открытым».

Этот инструмент используется для генерации SPDX 2.2 SBOM, которая содержит характерную информацию:
🍭 Document creation information. Общая информация – кто и когда создал, наименование ПО и т.д.
🍭 File section. Перечень файлов, из которых «состоит ПО», включая SHA-1/256 hash-значения
🍭 Package section. Перечень пакетов, используемых при создании ПО. Для каждого пакета указывается версия, «поставщик» (supplier), SHA-1/256 значение и т.д.
🍭 Relationship section. Описание взаимосвязи компонентов: например, Package и File

И, как обычно, чуть больше info в самом repo проекта: установка, «ключи» запуска и описание некоторых нюансов работы утилиты в определенных окружениях.

TripleCross: Linux eBPF offensive rootkit

Всем привет!

TripleCross – rootkit, который демонстрирует offensive возможности eBPF. Проект появился на свет в качестве работы h3xduck для защиты степени бакалавра в университете Мадрида.

Доступны следующие «модули»:
🍭 Library injection
🍭 Execution hijacking
🍭 Local privilege escalation
🍭 Backdoor with C2 capabilities
🍭 Rootkit client that allows an attacker to establish 3 different types of shell-like connections
🍭 Persistence
🍭 Stealth

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

P.S. Напоминаем, что подобные инструменты надо использовать строго в образовательных целях. И не использовать в production.

Trousseau: использование KMS provider для шифрования данных в Kubernetes

Всем привет!

Для шифрования данных в ETCD можно использовать штатные механизмы Kubernetes. Однако, есть нюанс, что ключи шифрования надо поместить на nodes, иначе возможны сбои. Альтернативный вариант – использование функционала KMS provider: третьей стороны, которая будет отвечать за шифрование, в том числе управлять ключами. При этом в ETCD будут попадать уже зашифрованные сущности.

Для упрощения подобной схемы ребята из Ondat сделали Trousseau – посредника между Kubernetes и KMS (например, HashiCorp Vault).

Схема получается следующая:
🍭 Пользователь создает сущность (например, Secret)
🍭 Kube-apiserver перенаправляет запрос в Trousseau
🍭 Он, в свою очередь просит зашифровать данные у HashiCorp Vault
🍭 Далее шифрованные данные направляются на хранение в ETCD

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

Если хочется «потрогать» руками, то есть удобная интерактивная лабораторная работа. В ней сперва настраивается encryption method, происходит конфигурация Transit Secret Engine в Vault, а затем демонстрируются зашифрованные секреты в ETCD.