Идентификация угроз в Kubernetes

Всем привет!

Еще одна потрясающая статья от ребят из Exness! В ней Авторы делятся практиками, которые они используют для мониторинга и идентификации угроз, характерных для Kubernetes.

В первой части приводится описание используемых средств автоматизации. Выбор команды пал на Tetragon (в качестве агента) и Kubernetes Audit Log (для получения информации о том, что происходит с кластером).

Описываются плюсы и минусы использования open source, доработки, реализованные командой, а также Audit Policy, которую применяют в Exness.

Дальше – интересней! Поиск угроз:
🍭 System Binary Renaming
🍭 Privileged Container Detected
🍭 Suspicious Execution Activity Inside a Container
🍭 Cluster Admin Role Bound to the User и не только

Для каждой угрозы приводится ее классификация по MITRE и/или матрицей от Microsoft, краткое описание и возможные способы ее идентификации.

Очень и очень полезный материал для тех, кто работает с мониторингом ИБ сред контейнерной оркестрации. Рекомендуем! ☺️

Атаки на JSON Web Tokens (JWT)

Всем привет!

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

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

После минималистичной вводной (что такое JWT, из каких «частей» состоит, какие они бывают и т.д.) Автор переходит к самому интересному – атакам и уязвимостям, связанным с технологией!

Рассматриваются:
🍭 Signature Not Verified
🍭 None Algorithm Attack
🍭 Trivial Secret
🍭 Algorithm Confusion и не только

Для каждой уязвимости описано в чем ее суть, какое может быть воздействие/ущерб (impact), как ее можно эксплуатировать и как можно защититься.

Коротко, ёмко, без воды и по делу! То, что надо!

Безопасность CI/CD, рекомендации Wiz!

Всем привет!

По ссылке можно найти статью, посвященную безопасности CI/CD, подготовленную специалистами Wiz.

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

Далее Авторы приводят собственные рекомендации:
🍭 Automating Security Scans
🍭 Focusing on Runtime
🍭 Managing Secrets Effectively
🍭 Implementing Immutable Infrastructure и не только

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

P.S. Помимо этого в Wiz Academy множество прекрасных статей по разным DevSecOps-тематикам. Возможно, вы найдете для себя что-то интересное ☺️

Сравнение Gateway API

Всем привет!

В repo можно найти результаты сравнения Gateway API. В выборку попали: Cilium, Envoy Gateway, Istio, Kgateway, Kong, Traefik и Nginx.

Сравнение проводилось по следующим параметрам:
🍭 Attached Routes Test
🍭 Route Probe Test
🍭 Route Scale Test
🍭 Traffic Performance
🍭 Architecture

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

Помимо этого, для каждого из сравниваемых решений описаны нюансы, которые выявил Автор в процессе тестирования.

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

P.S. Да, есть те, кто не попал в выборку (HAProxy, Linkerd и не только). Причины такого решения можно найти в repo.

5 лет, 160 комментариев и уязвимость устранена!

Всем привет!

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

Началось все с того, что Автор наткнулся на CVE-2022-1471, эксплуатация которой могла привести к RCE при использовании SnakeYAML.

И это удивило Автора, ведь в статье, которой на тот момент было уже 5 лет, упоминалась ровно та же самая уязвимость (только ей не был присвоен CVE), а SnakeYAML приводился в качестве одного из примеров.

Дальнейшее разбирательство немного шокировало: project maintainer перевел ее в значение «won’t fix», аргументируя это тем, что надо «просто использовать безопасный вариант реализации».

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

С точки зрения Автора такой подход был в корне неверным. Ведь, если есть возможность, то лучше реализовать secure-by-default, а все остальное – на усмотрение пользователей.

Именно так и начался thread о том, что это надо исправить. На момент окончания обсуждения было порядка 160 комментариев.

Хорошая новость в том, что project maintainer все-таки согласился с тем, что можно сделать иначе и предоставил secure-by-default реализацию. Она попала в SnakeYAML 2.0.

В статье можно прочесть много интересных размышлений Автора:
🍭 О том, как используют средства анализа кода (иногда фокус смещается на создание новых правил для сканеров, а не на устранение существующих недостатков)
🍭 О том, что делать ИБ-исследователям, если они зашли в тупик при общении с «автором уязвимости»
🍭 О том, почему secure-by-default это важно и не только

Но это все лучше прочитать самим ☺️ Рекомендуем!

Анализ событий кластера с InfraSight

Всем привет!

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

Состоит она из 4-х элементов:
🍭 Controller. Управляет eBPF-агентами в кластере
🍭 Agent. Анализирует события с использованием eBPF-программ
🍭 Server. Обрабатывает данные, полученные от Agent для последующего сохранения в базе данных
🍭 ClickHouse. Высокопроизводительная база данных, в которой хранятся события, полученные от InfraSight

На текущий момент решение позволяет отслеживать следующие системные вызовы: execve, open, chmod, connect и accept.

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

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

Важно: проект достаточно молодой и скорее всего есть нюансы, связанные с его работой 😊

The Kubernetes Networking Guide

Всем привет!

Если не знаете, что почитать на выходных, то рекомендуем обратить внимание на Kubernetes Networking Guide.

На этом ресурсе собрано очень много информации о том, как устроено сетевое взаимодействие в кластере.

На сайте можно найти информацию о:
🍭 Network Model
🍭 CNI
🍭 Services
🍭 Ingress & Egress
🍭 Network Policies
🍭 DNS и не только

Многие разделы содержат подразделы. Так, например, в блоке про CNI есть дополнительная информация о Flannel, Weave, Calico, Cilium.

Помимо теоретической части, включающей описания и различные схемы, на ресурсе доступны лабораторные работы (не для всего).

То, что надо, чтобы лучше понять устройство сети в Kubernetes и как с ней работать!

P.S. Некоторые разделы все еще находятся «Under Construction». Если вы хотите чем-либо дополнить материал, то можно сделать PR вот в этот repo.

Dependency Management Report

Всем привет!

В приложении можно скачать отчет (~ 46 страниц), подготовленный Endor Labs и посвященный вопросу управления зависимостями и их уязвимостями.

Отчет содержит несколько частей:
🍭 Identifying Dependencies & Their Vulnerabilities. Раздел содержит сведения о нюансах, связанных с корректным определением зависимостей: достижимость, «фантомные зависимости» и т.д.
🍭 Discrepancies and Shortcomings of Vulnerability Databases. «Тонкости работы» с базами данных об уязвимостях и почему использование только NVD далеко не всегда является достаточным
🍭 Why Remediating Known Vulnerabilities Is Hard. Почему нельзя «просто взять и обновить зависимости»
🍭 Software Composition Analysis and its role in dependency management. Рассуждения о функционале SCA-решений, который может помочь в решении описанных в отчете проблем

Для каждого раздела приводятся примеры, статистика, ссылки на полезные материалы по теме.

Отчет приятно читать, он содержателен и в нем практически нет маркетинга и «воды»

OWASP: Business Logic Abuse

Всем привет!

Еще один Top 10 от OWASP, на этот раз посвященный вопросам бизнес-логики: OWASP Top 10 for Business Logic Abuse (кстати, получилось довольно забавное сокращение – BLA 😊)

Он включает в себя:
🍭 Lifecycle & Orphaned Transitions Flaws
🍭 Logic Bomb, Loops and Halting Issues
🍭 Data Type Smuggling
🍭 Sequential State Bypass
🍭 Data Oracle Exposure и не только

Как обычно, описание и примеры доступны на сайте OWASP.

Материл достаточно свежий, поэтому деталей не очень много.

🔍 Semgrep меняет условия: новая лицензия и создание Opengrep

Всем привет!

13 декабря 2024 в блоге Semgrep вышло обновление “Important updates to Semgrep OSS”.

OSS-версия переименована в Community Edition (CE), ядро под LGPL 2.1 осталось нетронутым, но правила перевели на Semgrep Rules License v1.0 с Commons Clause – запрещено использовать их в конкурирующих SaaS. А через 4 года (декабрь 2028) все Rules перейдут под Apache 2.0 (как указано в BSL).

Уже в январе 2025 после обсуждений, группа компаний запустили форк Opengrep (LGPL-полная открытость правил и движка).

🎯 Детали всей истории и обзор Opengrep — в небольшой статье

Проверяете лицензии инструментов, которые добавляете в пайплайны? 🧐

Kubewall: интерактивный UI для Kubernetes

Всем привет!

Kubewall – еще один проект, цель которого – упростить взаимодействие пользователя с кластерами Kubernetes за счет предоставления графического интерфейса.

Он позволяет:
🍭 Централизованно работать с множеством кластеров
🍭 Просматривать ресурсы, созданные в кластере (конфигурация, события, логи)
🍭 Редактировать ресурсы за счет встроенного YAML-editor
🍭 Получать информацию об изменениях в кластере в режиме реального времени и не только
Устанавливается просто, не требует значительной конфигурации и практически сразу «готов к работе».

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

P.S. Конечно же, главный функционал в наличии! Можно менять темы на «светлую/темную» ☺️

Что такое CNI и как он работает

Всем привет!

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

В Kubernetes за это отвечает CNI – Container Network Interface – и его реализации (plugin’ы). О том, как это работает можно прочитать в статье.

В ней Автор описывает:
🍭 Из каких «компонентов» состоит CNI plugin, какие его основные задачи
🍭 Как pod «подключается» к сети
🍭 Логика работы CNI plugin’a «под капотом» (создание Virtual Ethernet Pair, назначение IP pod и т.д.)
🍭 Обеспечение сетевой связности между узлами кластера и не только

Для каждого раздела Автор подготовил наглядные диаграммы, примеры используемых команд.

В завершении статьи есть ссылка на GitHub Repo, в котором представлен минималистичный CNI plugin для того, чтобы можно было изучить вопрос более детально.

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

Kube Composer

Всем привет!

Нет, это не то, о чем вы подумали! ☺️ Это не утилита, которая превращает compose-файлы в Kubernetes-манифесты.

Kube Composer – это интуитивно понятный YAML-генератор ресурсов кластера, которые вы хотите создать.

Представляет он из себя небольшое web-приложение, которое можно развернуть «у себя», так и воспользоваться playground’ом.

Он позволяет:
🍭 Описывать требуемые ресурсы и их параметры непосредственно в UI
🍭 Работает с Deployments, Services, Volumes, Ingress и не только
🍭 Наглядно показывает связность между разными Kubernetes
🍭 И, конечно же, генерирует YAML-файлы, которые потребуются для создания ресурсов

Не зря говорят, что лучше один раз увидеть, чем сто раз услышать. Поэтому предлагаем вам посмотреть на его возможности воочию.

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

P.S. А еще там можно посмотреть специально подготовленное demo

Как работают Validating Admission Policy?

Всем привет!

Еще одна статья, в которой описывается «как оно работает под капотом?». На этот раз речь пойдет про Validating Admission Policy и их реализацию в Kubernetes.

Вкратце этот механизм позволяет анализировать создаваемые в кластере ресурсы на соответствие предъявленным требованиям.

После небольшой вводной Автор переходит к описанию того, что это такое из чего оно состоит в Kubernetes. Рассматривается «собственный механизм», а не сторонние (Kyverno, Gatekeeper и т.д.).

В статье рассказано о:
🍭 API Definition. Из каких API состоит Validating Admission Policy
🍭 Controller Reconciliation. Из чего она состоит, какие задачи выполняются
🍭 Resource Admission. Как осуществляется проверка создаваемых в кластере ресурсов
🍭 Expression Cost Analysis. Контроль того, что Kubernetes API Server’у не станет «плохо» от проверок

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

Завершает статью немного примеров анализа манифестов и как можно реализовать мониторинг Validating Admission Policy с использованием Prometheus.

Управление доступом: SSH ключи или сертификаты?

Всем привет!

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

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

А что, если попробовать использовать не SSH ключи, но SSH-сертификаты? В теории это может решить проблемы, описанные выше. Именно этому посвящена статья.

Идея в том, чтобы:
🍭 Создать сервис, который будет выпускать недолго живущие сертификаты
🍭 Пользователь запрашивает такой сертификат. 🍭 Сервис решает можно ли его выдавать
Получив сертификат, пользователь инициирует SSH соединение с целевым хостом
🍭 SSH daemon хоста проверяет валидность сертификата, осуществляется проверка прав подключения
🍭 Пользователь получает доступ

Больше деталей о том, как это работает и что именно предлагает Автор можно найти в статье.

В этом сценарии получаем централизованное решение, которое позволит точечно управлять доступом и не беспокоиться о том, что «что-то забыли удалить».

А что вы думаете? Имеет ли такой механизм место быть или лучше использовать «привычные» подходы?

Обновление Jet Container Security Framework (JCSF)

Всем привет!

Свершилось долгожданное: мы учли пожелания всех заинтересованных и обновили JCSF!

Основные изменения:
🦴 Появился маппинг JCSF на CIS Benchmark for Docker
🦴 Появился маппинг JCSF на CIS Benchmark for Kubernetes
🦴 Появился маппинг JCSF на 118 Приказ ФСТЭК России
🦴 Актуализированы (дополнены, изменен текст) некоторые практики JCSF, а также частично перемещены в другие домены
🦴 Появился домен по безопасности Docker и Docker Swarm
🦴 Улучшилось визуальное оформление, исправлены опечатки и ошибки, добавлены новые

Качайте, анализируйте документ и вашу контейнерную инфраструктуру!
Присоединяйтесь к совершенствованию JCSF и становитесь контрибьютором (мы открыты к любым предложениям и отзывам)!