Cloud Native Threat Report от Aqua Security

Всем привет!

В приложении можно скачать отчет от Aqua Security, посвященный Cloud Native (апрель 2022).

Для получения данных ребята из Aqua использовали несколько подходов – собственная honeypot сеть, а также анализ общедоступных образов контейнеров.

Примеры того, что можно найти в отчете:
🍭 Фокус на атаки web-интерфейсов Kubernetes
🍭 Многие общедоступные образы содержат вредоносное ПО (например, mimikatz, metasploit и т.д.)
🍭 Supply chain атаки (что особенно «ярко» было выражено в 2021 году и продолжается в настоящее время) и т.д.

И, как обычно – статистика, ссылка на внешние источники и на «значимые» примеры, которые произошли за последнее время в ИБ-мире cloud native.

Безопасность Etcd

Всем привет!

Неплохая обзорная статья, посвященная безопасности Etcd. Сперва Автор описывает, что это такое, зачем она нужна, из каких компонентов состоит и как Etcd «связана» с Kubernetes.

После небольшой вводной части описываются значимые недостатки ИБ, которые могут быть реализованы в случае некорректной конфигурации:
🍭 client-cert-auth не используется, вследствие чего не проверяется валидность сертификатов при обращении к Etcd
🍭 Доступность порта 2379 «извне»
🍭 Использование SSRF уязвимости для получения доступа к Etcd
🍭 Утечка сертификата Etcd

Для каждого недостатка приводятся причины почему это плохо и к чему это может привести.

В продолжении статьи Автор описывает возможные векторы атак. Одним из них является компрометация токена, «привязанного» к Cluster Wide роли с дальнейшим его использованием при обращении к кластеру Kubernetes.

Завершают статью размышления Автора на тему того, как можно сделать лучше/более безопасно.

Troubleshooting Kubernetes

Привет!

Про эту схему мы уже писали, но… проект продолжает развиваться, что не может не радовать! Последнее обновление – от мая 2022 года.

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

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

Всем привет!

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

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

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

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

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

Всем привет!

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

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

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

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

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

Лабораторные работы по 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 часа, теория и практика.

ИБ-практики при использовании 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 есть раздел, посвященный информационной безопасности.

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

Привет!

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

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

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

IDE plugin Trivy для VS Code

Всем привет!

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

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

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

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

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

Привет!

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

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

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

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

Несколько контейнеров в 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).

Инъекция 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 с необходимыми материалами можно найти тут.

Всем привет!

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/

Предотвращение 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-ролик с демонстрацией.

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

Всем привет!

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

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

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

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

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

Всем привет!

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

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

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

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

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 Secrets: так ли небезопасно?

Всем привет!

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

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

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

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

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.