Использование ChaosMesh на примерах

Привет!

В блоге Flant есть отличная статья (и не только эта), посвященная использованию ChaosMesh! Если кто не в курсе, ChaosMesh – инструмент для воссоздания практик Chaos Engineering. Практик, при которых все может (и должно) пойти не так: «отвалился» доступ Клиентов к приложению, «упал» продуктовый сервер, изменилась конфигурация %чего-либо% в промышленном окружении…

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

И, конечно же, самое интересное! Тесты:
🍭 Допустим, перезагрузка node. Почему бы и нет
🍭 Отказы в работе PostgreSQL и RabbitMQ. Можно и такое! Притом разными способами
🍭 Тестирование сети! Да! Задержки, потери пакетов…

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

P.S. Это не первая статья Flant по теме ChaosMesh. Небольшое сравнение open source решений для chaos engineering можно найти по ссылке.

CTF от Snyk!

Всем привет!

Snyk анонсировали свой новый CTF, зарегистрироваться на который можно бесплатно. Само мероприятие пройдет 9-ого ноября. Можно участвовать самостоятельно, но лучше собрать команду до 5-и человек. Время проведения: с 16:00 до 22:00 (по Мск).

Что будет на CTF:
🍭 16 challenges (pwn, web, crypto, forensics)
🍭 Призы (не очень понятно какие, но какая разница! 😊)
🍭 Атмосфера (обычно мероприятия Snyk очень продуманны и интересны)

Если Вы никогда не участвовали в CTF, но очень хочется попробовать, то Snyk организовывает CTF 101 Workshop, который пройдет 2-ого ноября.

Решения заданий также будут опубликованы после завершения CTF. Для всех или только для зарегистрированных пользователей – пока непонятно, поэтому рекомендуем зарегистрироваться.

A Guide to Improving Security Through Infrastructure-as-Code

Всем привет!

По ссылке доступна большая обзорная статья, посвященная обеспечению ИБ при/с использованием подхода *-as-Code.

Статья содержит следующие разделы:
🍭 Что такое Infrastructure-as-Code (IaC)
🍭 Моделирование угроз (STRIDE, MITRE, CIS, материалы производителей средств защиты)
🍭 Управление доступом
🍭 Интеграция проверок в CI/CD (средства анализа конфигураций – Checkov, tfsec, KICS и другие)
🍭 Policy-as-Code (OPA, куда же без нее 😊)
🍭 Управление конфигурациями (средства конфигурирования и проверки реализованных конфигураций)
🍭 Мониторинг и контроль configuration drift
🍭 Зрелость IaC, уровни и их описание

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

Semgrep Supply Chain

Всем привет!

Have you ever gotten a "critical vulnerability in dependency" alert and when you look at it, it's something like “XML parser vulnerability in some buried transitive library that you actually use for parsing JSON and therefore aren’t affected by at all?”

Думаем, что это случалось и случалось не один раз. Одна из проблем анализа уязвимых open source компонентов – насколько они и правда уязвимы в конкретном ПО?

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

Именно для решения этой задачи – «is it reachable?» - и был придуман Semgrep Supply Chain, который позволит расставить приоритеты и подсветить, что реально важно.

На текущий момент поддерживаются следующие языки: (GA) Go, JavaScript/TypeScript, Python, and Ruby, (Beta) Java.

Единственным «недостатком» является то, что решение платное. Однако, чтобы опробовать его «в деле» можно попробовать получить 100 дней trial-использования (но это не точно).

Управление доступом к k8s с использованием Teleport

Привет!

Хорошая обзорная статья, посвященная Teleport и возможности его использования для предоставления доступа разработчикам к кластерам k8s через интеграцию с GitHub. Вполне подойдет, если вы хотите познакомиться с инструментом.

Первая часть статьи посвящена общим вопросам:
🍭 Что такое Teleport, что есть identity-based control
🍭 Возможности Teleport по анализу действий, совершаемых в кластере
🍭 Способы предоставления безопасного доступа, существующие интеграции

Вторая часть – демо! С большим количеством примера, настроек и конфигурации:
🍭 Установка Teleport, создание первого пользователя
🍭 Настройка GitHub SSO
🍭 Настройка доступа пользователя к кластеру k8s
🍭 Просмотр действий, совершенных в кластере пользователем

В целом получился отличный how-to-guide для знакомства с решением. Конечно, больше информации о возможностях Teleport и не только можно получить из документации.

HashiCorp Developer

Всем привет!

Материалы HashiCorp можно назвать одними из лучших. Много документации, видео-уроков, tutorials и лабораторных работ.

И они продолжают радовать и делать материалы удобнее и доступнее для community. В июне 2022 года был запущен (beta) сайт HashiCorp Developer.

Он собрал в себе все необходимые материалы по продуктам HashiCorp:
🍭 Vault
🍭 Terraform
🍭 Nomad
🍭 Vagrant и другие

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

Сравнение Semgrep и CodeQL

Всем привет!

По ссылке можно найти достаточно объемное сравнение популярных инструментов анализа исходного кода для идентификации ИБ-дефектов – Semgrep и CodeQL.

Рассматривались такие критерии сравнения, как:
🍭 Поддержка языков программирования
🍭 «Глубина» анализа, работа lexer/parser
🍭 Pre/post опции сканирования (исключения, фильтрация, отключение проверок и т.д.)
🍭 Правила
🍭 Управление ИБ-дефектами («собственные» возможности, интеграции с ticketing systems и т.д.)
🍭 Время сканирования

По каждой из групп в сравнении приводятся примеры и некоторые benchmark по производительности.

PCI Compliance for Kubernetes in detail: Part 2 - Authorization

Всем привет!

Обзорная статья от Rory McCune, посвященная анализу требований PCI Compliance for Kubernetes и Authorization в частности.

Рассматриваются:
🍭 Принцип минимальных привилегий
🍭 Корректное использование групп
🍭 Контроль предоставления доступа, проведение периодических аудитов выданных прав

К каждому из вышеуказанных требований Rory добавляет собственные рассуждения. Получается коротко, емко и информативно.

В целом, в этой части стандарта описаны простые и понятные требования, которые применимы не только к Kubernetes и являются «образующими» (т.е. без них почти везде никуда). А реализация таких требований точно повысит степень защищенности кластера. Особенностью Kubernetes может быть способ реализации указанных требований и не самая прозрачная ролевая модель.

P.S. С общими рассуждениями Rory про PCI Compliance for Kubernetes и про первую его часть, Authentication, можно познакомиться тут и тут соответственно.

Аутентификация в Kubernetes: основы

Всем привет!

Во многих стандартах, требованиях, рекомендациях и т.д. можно встретить вполне понятное требование по контролю аутентификации. Первое что приходит на ум – пароль, ключевая фраза, токен или еще что-либо, что пользователь вводит для подтверждения своей «личности».

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

Чтобы со всем разобраться и понять, что же происходит «под капотом» рекомендуем ознакомиться со статьей, в которой на базовом примере curl https://api-server-address:6443/api/v1/namespaces объясняется что к чему:
🍭 Кто может делать запросы к api-server
🍭 Какие способы аутентификации доступны и что реализовано «из коробки»
🍭 Можно ли изменять «стратегии» аутентификации
🍭 Разрешено ли одновременно использовать несколько способов аутентификации в одном кластере

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

Dependency Confusion

Всем привет!

Dependency Confusion – одна из «популярных» уязвимостей 2021 года. Суть ее достаточно проста. Допустим есть локальная библиотека «libone» версии 1, которая разработана в Компании N. Злоумышленник может сделать свою версию библиотеки с таким же наименованием и разместить ее в публичном репозитории. А версию указать выше, чем у той библиотеки, что есть в локальном репозитории Компании N. Возможны сценарии, когда сборщик будет использовать более старшую версию, а значит ту, что создал злоумышленник.

Для проведения PoC реализации Dependency Confusion ребята из Doyensec создали Confuser – утилиту, которая автоматизирует часть этапов (на примере npm).

Работает она по следующему сценарию:
🍭 Поиск пакетов, которых нет в публичных репозиториях
🍭 Создание payload используя особенности npm и install hooks
🍭 Передача информации обратно в сторону злоумышленника - callbacks

С подробностями, включая сложности поиска и особенности эксплуатации Dependency Confusion, можно ознакомиться в статье (рекомендуем к прочтению), а сам Confuser доступен вот тут.

Если до сих пор не верится, что такое встречается в «реальном мире» - можно прочесть статью «Researcher hacks over 35 tech firms in novel supply chain attack». В ней описано, как Alex Birsan заработал $130,000 на bug-bounty программах, эксплуатируя эту самую уязвимость.

P.S. Напоминаем про то, что это лучше не повторять. Статья исключительно для образовательных целей и лучшего понимания того, как и что может произойти

Kubectl-Ice

Всем привет!

Kubectl-ice – plugin для kubectl, которые может быть полезен для получения информации о контейнерах и поиска ошибок.

Он может:
🍭 Показывает все контейнеры в namespace («обычные», init, ephemeral)
🍭 Может показать перечень всех образов контейнеров, которые используются в namespace
🍭 Отобразить информацию по всем SecurityContext и POSIX cabapilities
🍭 Информацию об используемых ресурсах контейнерами
🍭 Сведения о mount, которые используются контейнерами и не только

Доступна фильтрация данных и отображение в различных форматах. В repo можно найти небольшой demo-ролик, в котором наглядно показано, как можно использовать kubectl-ice.

Trivy vs Trivy-Operator

Всем привет!

На первый взгляд может показаться, что Trivy и Trivy-Operator это одно и тоже. Разница лишь в том, что Trivy-Operator запускается в качестве operator’a в кластере, а Trivy работает локально. Но это не совсем так.

В статье приводится основная разница между этими решениями. Если кратко, то Trivy-Operator использует Trivy в качестве сканера. При большом желании можно «подключить» свой сканер, для этого надо реализовать несколько интерфейсов.

Так в чем же разница?
🍭 Trivy передает результат в терминал, можно делать выгрузку в различных форматах, в т.ч. json. Результаты работы Trivy-Operator представляют из себя Custom Resources Kubernetes
🍭 Разный объем результатов, что отчасти связано с ограничением по умолчанию на запись в etcd в размере 1,5 MB.
🍭 Trivy запускается локально (на рабочей станции, в CI/CD). Trivy-Operator «устанавливается» на кластер и анализирует сущности по мере их создания и на периодической основе.

Таким образом, можно сказать, что Trivy более удобный инструмент для анализа в моменте разработки, а Trivy-Operator – на момент эксплуатации.

Arbitrary command execution через… Snyk CLI

Всем привет!

Интересная статья от Imperva, в которой рассказано о том, как команда нашла CVE-2022-40764, эксплуатация которой позволяет реализовать «arbitrary command execution» при использовании Snyk CLI.

Статья читается как небольшой детектив и на одном дыхании! Получился примерно такой путь:
🍭 Monkey patch для Snyk CLI с целью журналирования значимых NodeJS действий (например, доступ к файлам, запуск shell)
🍭 Да, все так, оказалось, что shell запускается! Дальнейшее исследование привело к идентификации причины: файл vendor.json и поле ignore
🍭 Первый payload, подготовленной командой не сработал из-за особенностей «обработки» значения, указанного в поле ignore
🍭 А вот второй… уже позволил запустить калькулятор на рабочей станции пользователя!

Реализацию подобной атаки выполнить сложно. Однако, у Snyk есть VS Code plugin, который использует CLI для автоматического сканирования кода при открытии IDE. Остается только сделать так, чтобы пользователь открыл «интересующий» код в VS Code. PoC-ролик, примеры monkey patch, payload’ов и код обработки поля ignore можно увидеть в статье.

Команда Snyk, в свою очередь, достаточно оперативно устранила дефект и выпустила соответствующий патч 😊

Kubernetes Security Profiles Operator

Привет!

Основная задача Security Profile Operator – сделать использование и управление SELinux, AppArmor и Seccomp профилями более простыми и удобными для пользователей. Предысторию его появления можно узнать в этом RFC.

Он представляет из себя Operator, который управляет Custom Resources, с которыми можно ознакомиться тут.

Обладает следующими возможностями:
🍭 Создание профилей через CRD
🍭 Применение профилей для Pod
🍭 Автоматическая генерация профилей (частично, пока только для Seccomp)

Для лучшего ознакомления с Security Profile Operator, вариантами запуска, возможностями и принципами работы рекомендуем ознакомиться со статьей. Roadmap дальнейшего развития проекта представлен в repo в виде диаграммы ☺️

P.S. А В этом repo можно найти очень-очень-очень много AppArmor профилей

Совместное использование Snyk и ArgoCD

Всем привет!

В статье приводится tutorial, который позволит анализировать приложения, контролируемые ArgoCD при помощи Snyk.

Последовательность действий:
🍭 Создание приложения в ArgoCD
🍭 Настройка PreSync Hook в ArgoCD, который будет запускать анализ запускаемых сущностей при помощи Snyk
🍭 Просмотр результатов: в ArgoCD и в консоли Snyk

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

Seccomp в Kubernetes: 7 базовых вещей

Всем привет!

Использование Secure Compute Mode (Seccomp) позволит сократить поверхность атаки за счет возможности ограничения/разрешения syscalls, которые могут быть «запущены». Базовый профиль содержит несколько основных блоков: defaultAction – действие, которое будет применено «по умолчанию», architectures (syscalls могут обладать разными id в зависимости от архитектуры), syscalls – перечень системных вызовов. Но как его правильно «приготовить»?

Частично ответ на это есть в подробной статье от Paulo Gomes, в которой он раскрывает важные аспекты, про которые не стоит забывать, например:
🍭 Устанавливайте allowPrivilegeEscalation в значение false. Да, это влияет на Seccomp. Как именно – описано в статье
🍭 Назначайте Seccomp профиль на уровне Container, а не Pod (статья 2019 года, возможно причина уже не актуальна)
🍭 Используйте default профили только в экстренных случаях. Лучше напишите свои
🍭 Запускайте Seccomp в режиме аудита для «тонкой настройки». Да, так можно
🍭 Whitelisting лучше, чем Blacklisting

Для каждого рассмотренного совета Paolo приводит аргументацию, почему предложенный вариант является оптимальным и несколько примеров. Отличная статья, чтобы начать изучение Seccomp.

P.S. В документации Docker можно ознакомиться с обоснованием того, почему тот или иной syscall «заблокировали» и он не попал в Seccomp профиль.

Seccomp в Kubernetes: создание профиля

Привет!

Вторая часть статьи от Paolo Gomes, посвященная Seccomp! В ней Paolo рассуждает на тему того, как можно создать whitelist-профили и как решить самую значимую задачу – определить, какие именно syscalls используются приложением.

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

Например:
🍭 Использование strace для получения syscalls, используемых командой
🍭 Анализ приложения для сбора всех syscalls. Paolo сделал PoC для программного обеспечения, разрабатываемого на golang
🍭 Запуск Seccomp в режиме «аудита» ("defaultAction": "SCMP_ACT_LOG")
🍭 Brute force! Да, тот самый «подход в лоб»: разрешаем все и удаляем, пока не найдем нужное состояние. Или наоборот – отбираем все и разрешаем по одному, наблюдая изменения в ошибках

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

P.S. Кстати, Paolo один из разработчиков Kubernetes Profile Operator, про который мы писали тут.

P.P.S. Еще один популярный инструмент, который позволяет генерировать Seccomp-профили (и не только) – Docker Slim.

Kubernetes Storage: Basics

Всем привет!!!

Хорошая обзорная статья про то, что такое Storage в Kubernetes, зачем они нужны, какие они бывают и в чем между ними разница.

В статье разбираются следующие моменты:
🍭 hostPath и почему лучше не использовать его, а обратить внимание на NFS
🍭 ConfigMap/Secret as Volume и как с их использованием можно передать данные в Pod
🍭 PersistentVolume (PV) и PersistentVolumeClaim (PVC) – что это, какие VolumeTypes, AccessModes и RetainPolicy бывают
🍭 Dynamic Provisioning, зачем нужен StorageClass и как все это связано с PV и PVC

Примеры, код манифестов, диаграммы для упрощения восприятия, ссылки на полезные материалы – все на месте и хорошо структурировано.

Статья очень базового уровня, и поясняет основные понятия и механизмы проброса persistent storage в кластер Kubenetes.

Из статьи понятно, что хорошо и просто живется лишь тем, кто в облаках ☺️ Для тех, кто "на земле" - рекомендуется посмотреть в сторону NFS. Мы со своей стороны при этом рекомендуем не забывать, что в NFS нет никакого встроенного механизма квотирования ресурсов, и может случиться так, что один контейнер занимает всю шару.

Поэтому соблюдайте осмотрительность, и посмотрите в сторону специализированных CSI от производителей внешних СХД, если вдруг такая задача у вас возникнет.

Chain-bench: GitLab

Всем привет!

Сегодня будет короткая, но весьма приятная новость. На предыдущей неделе в Chain-bench от Aqua Security была добавлена поддержка GitLab (v 0.1.5). Судя по всему, добавлены не все проверки, но движение в этом направлении есть и это уже хорошо.

Chain-bench – open source решение, которое позволяет анализировать настройки окружения (например, систем управления исходным кодом) на соответствие требованиям ИБ.

В качестве «источника данных» используется CIS Software Supply Chain Security Guide. Про Chain-bench и CIS мы писали тут и тут соответственно.

Fine grained personal access token в GitHub

Привет!

До недавнего времени personal access tokens (PAT) GitHub’a предоставляли достаточно широкие полномочия. Например, предоставлялся доступ ко всем repo, к которым был доступ у пользователя, генерирующего PAT. Это не всегда было удобно разработчикам и точно не соответствовало практикам ИБ. Например, такой подход не соответствует need-to-know и least privilege принципам.

18 октября GitHub открыл доступ к fine grained personal access tokens, которые находятся в стадии beta. Их задача – сделать предоставление доступа к repo максимально гибким и удобным.

Например:
🍭 Можно давать доступ ко всем repo или только к тем, которые выберет разработчик
🍭 Доступ только к Issues определенного repo
🍭 Возможность просмотра pull requests и многое другое

Всего добавлено более 50 granular permissions, которые можно устанавливать в значения «no access», «read», «read and write». Еще один приятный бонус – возможность просмотра использования токенов и их отзыв владельцами в случае необходимости.

Подписи и аттестации

Всем привет!

Когда говорят про контроль supply chain зачастую вспоминают про подпись чего-бы-то-ни-было. Все как обычно – есть пара private/public key, используя которые можно гарантировать, что мы получили артефакт именно от его Автора.

Но есть небольшой нюанс. Может случиться так, что Автор подписывает сам артефакт без анализа того, что находится внутри. Например, анализа кода, который помещается в контейнер, анализа open source зависимостей, анализа образа контейнера и т.д.

Как быть в такой ситуации? Ответ отлично разобран в статье "Policy and Attestations", в которой рассматривается термин «Аттестация». Грубо говоря – набор некоторых утверждений, которые характерны для того или иного артефакта, подписанные электронной подписью. Например, те же результаты сканирования образа.

Именно так (анализируя аттестации) Kyverno может проверять когда последний раз образ был просканирован и принять решение – стоит ли его запускать. Об этом use case мы писали тут, там тоже есть немного про аттестацию и то, как она реализуется в Cosign.