Kubernetes From Scratch

Всем привет!

Продолжаем неделю базовых обучений для погружения в технологию.

В приложении можно найти небольшую книгу (~ 72 страницы), посвященную базовым концептам Kubernetes и способам работы с ними.

Материал содержит:
🍭 Архитектура Kubernetes, назначение каждого компонента и его роль
🍭 Основные сущности Kubernetes (те, с которыми предстоит работать большую часть времени)
🍭 Взаимодействие с кластером через kubectl
🍭 «Инструкцию» по установке и настройке своего первого кластера
🍭 Сетевое взаимодействие ресурсов в Kubernetes
🍭 Работа с хранилищами и не только

Материал хорош тем, что там нет ничего лишнего. Лишь лаконичные объяснения и примеры от Автора.

Поэтому книга может отлично подойти тем, кто только делает (или думает сделать) свои первые шаги в Kubernetes.

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

P.S. Поблагодарить Автора и написать ему слова благодарности можно вот тут.

Безопасны ли skills?

Всем привет!

Да, skills очень похожи на ту самую «волшебную таблетку» - стоит только пожелать и они сделают то, что хочется (по крайней мере так кажется).

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

Но у медали всегда 2 стороны: некоторые skills не так «безобидны»: они могут красть чувствительные данные, перехватывать контроль над агентами и делать ещё много чего «интересного».

Из-за этого появился новый «класс» средств защиты – Skill Scanners, задача которых разобраться в том, что именно делает skill и, если это что-то «нехорошее» - сообщить пользователю, а ещё лучше – заблокировать такую активность.

Но любое средство защиты не идеально и всегда найдётся способ его «обойти». Именно эту задачу поставила себе команда Trail Of Bits!

Они проанализировали ClawHub’s Malicious Skill Detector, Skill Scanner от Cisco и все сканеры, доступные на skill.sh.

Итог? У команды получилось успешно «обойти» все сканеры и на всё про всё ушло менее одного часа.

Притом многие используемые техники оказались весьма «банальными». Как именно это получилось у Trail of Bits и что они сделали – описано в статье.

Рекомендуем!

EPSS v5

Всем привет!

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

Но со значительным ростом уязвимостей этот подход перестал оправдывать себя. Особенно во времена, когда с использованием AI нахождение новых CVE сократилось до часов.

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

Альтернативным предложением стала EPSS – система, которая (в теории) предоставляет ответ на вопрос: «С какой вероятностью эксплуатация той или иной CVE будет осуществлена в течение 30 дней?».

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

Тем не менее, подход развивается и недавно была представлена 5-ая версия EPSS. Согласно «разработчикам», она на 23% более эффективна, чем предыдущая версия.

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

Подробнее об EPSSv5 можно прочесть тут и тут.

А что вы думаете по поводу использования EPSS для решения задачи расстановки приоритетов устранения уязвимостей?

HackLabs: лабораторные работы по AppSec

Всем привет!

HackLabs – набор из 43 лабораторных работ по безопасной разработке. Да, большинство из них посвящено OWASP Top 10 (Web), но есть и иные задания.

Внутри можно найти:
🍭 Задания по OWASP Top-10 (Web) – от A1 до A10
🍭 Атаки на ИИ
🍭 Побег из контейнера
🍭 Ошибки, связанные с бизнес-логикой и не только

Задания распределены по уровням риска – Средний, Высокий, Критический. Дополнительно можно настроить «уровень сложности», влияющий на уровень защиты лабораторных работ.

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

А по завершению будет разблокирован бесплатный «сертификат», подтверждающий спешное прохождение всех лабораторных работ.

Подробности об установке, лабораторных работах, примеры того, как это выглядит можно найти в GitHub-репозитории проекта.

Единственный нюанс: ¿Hablas español? 😅

Meshery: self-service engineering platform

Всем привет!

Хотя так и может показаться из названия, но нет! Meshery это не ещё одно ServiceMesh-решение.

Meshery – это open-source платформа, которая позволяет управлять Kubernetes-based инфраструктурой и приложениями, которые на ней запущены.

Ключевой функционал Meshery можно разделить на блоки:
🍭 Управление жизненным циклом ИТ-инфраструктуры
🍭 Управление несколькими Kubernetes-кластерами и облаками из «единого окна»
🍭 Анализ производительности кластеров с возможностью генерации нагрузки на запущенные в кластере приложения
🍭 Получение информации о событиях, генерируемых ресурсами, запущенными в кластере
🍭 Возможность реализации GitOps-подхода для управления ресурсами кластера и не только

Это далеко не просто «ещё один Kubernetes UI», т.к. Платформа предлагает множество дополнительных возможностей.

Описать их все не получится, поэтому рекомендуем обратиться к документации, в которой всё достаточно подробно описано.

P.S. Проект уже отмечен CNCF и находится у них в Sandbox!

GraphQL Cop: аудит безопасности GraphQL

Всем привет!

GraphQL Cop – open-source утилита, которая позволяет выявлять ИБ-дефекты при работе с GraphQL API.

С её помощью можно протестировать API еще до того, как он попадёт в среду эксплуатации.

Грубо говоря, набор скриптов, которые идентифицируют ИБ-дефекты и которые можно встроить, например, в конвейер непрерывной сборки.

Она поддерживает следующий набор тестов:
🍭 Batch Queries (DoS)
🍭 POST based Queries using urlencoded payloads (CSRF)
🍭 Field Suggestions (Info Leak)
🍭 Directives Overloading (DoS)
🍭 Mutation support over GET methods (CSRF) и не только

Утилита является небольшим Python-приложением, проста в установке. Возможен вариант с запуском через Docker-контейнер.

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

Kogaro: «гигиена» Kubernetes

Всем привет!

При работе с Kubernetes-ресурсами важно понимать, какие есть недостатки в используемых конфигурациях. Это характерно как для ИБ, так и для ИТ.

Да, есть различные Policy Engine, для которых можно использовать существующие политики или написать свои и решить задачу.

Но, если нужно нечто минималистичное, что включает в себя множество самых «распространенных» проверок, то можно воспользоваться Kogaro.

Основная идея, которую он преследует – простота и полнота. «Внутри» он содержит более 60 проверок.

Они подразделяются на типы:
🍭 Reference Validation (11 проверок)
🍭 Resource Limits validation (10 проверок)
🍭 Security Validation (12 проверок)
🍭 Image Validation (5 проверок)
🍭 Networking Validation (9 проверок)

Конечно, его функциональность несравнима с Kyverno, OPA Gatekeeper и его аналогами, но! Иногда и правда требуется что-то простое, с чего можно начать.

Подробнее о способах установки, настройки и правилах проверки можно прочесть в GitHub-репозитории проекта.

K8s Diagram Generator

Всем привет!

Небольшой пятничный пост! K8s Diagram Generator – проект, при помощи которого можно создавать диаграммы связи сущностей ресурсов Kubernetes в графическом интерфейсе.

Работает очень просто: выбираете необходимые ресурсы (Ingress, Service, Deployment, Pod, Sidecar и т.д.), переносите их в «рабочую область» и «соединяете».

Ресурсы можно «адаптировать» - указывать Labels, наименования, необходимые порты, Selectors и т.д.

При создании схемы автоматически генерируются YAML-файлы, которые описывают созданную в диаграмме конфигурацию.

Можно и наоборот – загрузить YAML и тогда K8S Diagram Generator «построит» его графическое представление.

Реализованы проверки: например, нельзя настроить взаимосвязь между Deployment и Ingress без Service - K8s Diagram Generator явно сообщит об этом.

Дополнительно доступен небольшой набор «уроков» по написанию YAML-файлов.

Подробнее о проекте и его возможностях можно узнать в GitHub-репозитории.

OpenEverest: управление базами данных в Cloud Native

Всем привет!

OpenEverest – ещё один интересный проект из «песочницы» CNCF, задача которого – предоставить пользователю удобный инструмент управления базами данных в Cloud Native мире.

Его основная функциональность заключается в:
🍭 Автоматическое создание баз данных (с использованием простого и интуитивного UI)
🍭 Управление базами данных на всех этапах жизненного цикла (перезапуск, остановка, восстановление из резервных копий)
🍭 Управление безопасностью и резервным копированием (SSO, управление сессиями, TLS)
🍭 Мониторинг и помощь в поиске проблем c использованием PMM

Работает с MySQL, PostgreSQL и MongoDB в любых окружениях – облака, локальные и гибридные инсталляции, включая установку в Kubernetes.

Подробности о возможностях OpenEverest можно узнать в документации. Там много всего!

Рекомендуем ознакомиться ☺️

GitHub и утёкшие секреты!

Всем привет!

Утечки секретов – очень парадоксальная вещь. Да, про это все знают. Да, никто не спорит, что так делать не надо. Да, репозитории сканируют.

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

Небольшой эксперимент провёл Автор статьи. Он проанализировал около 1443 GitHub-репозиториев и нашёл около 4000 подтверждённых секретов.
Из хорошего – после того, как он сообщил об утечке, 95% из них были обновлены в течение двух недель.

Для поиска секретов он использовал несколько подходов. Первый заключался в использовании LLM и простого prompt: «Найди в commit что-то, что может являться секретом» (пример полноценного prompt приведён в статье).

После этого Автор попросил модель предоставить ему шаблоны (patterns), на основании которых модель принимает решение об истинной природе секрета.

Это позволило улучшить результаты. Последним рубежом стало использование Trufflehog для того, чтобы найти ещё больше.

Результаты: статистика, интересные примеры того, что удалось найти, детальное описание подхода – всё это приведено в статье.

P.S. кстати, аналогичное упражнение делали и с GitLab. Про это мы писали вот тут.

Wapiti: сканер для поиска уязвимостей в Web!

Всем привет!

Wapiti – open-source сканер, который позволяет искать уязвимости в web-приложениях. Им просто управлять и настраивать, можно ставить сканирования на паузу и продолжать, добавлять собственные payloads и т.д.

Если говорить о поддерживаемых «атаках», то это:
🍭 Различные инъекции (SQL, LDAP, XXE и т.д.)
🍭 XSS (reflected, permanent)
🍭 File Disclosure
🍭 Folder and File Enumeration
🍭 CSRF Detection и не только

Для запуска потребуется Python 3.12, 3.13 или 3.14, а установить можно с использованием pip.

Подробнее с возможностями Wapiti можно ознакомиться в GitHub-репозитории, сайте или Wiki-странице проекта.

What happens when…

Всем привет!

… you run kubectl apply? Есть разные статьи на тему «Что происходит если…». Например, удаление pod, работа планировщика Kubernetes и т.д.

Сегодня же речь пойдёт о том, что происходит «внутри» Kubernetes при запросе создания/изменения ресурса, получаемого от пользователя.

Сам по себе ресурс не управляется YAML-файлом, который его создал. Например, с Deployment могут взаимодействовать различные участники: kubectl, Helm, ArgoCD, HPA и т.д.

И когда несколько участников могут взаимодействовать с ресурсом возникает вопрос – а как именно происходит контроль его состояния?

Именно этому и посвящена статья. Для примера рассматривается пример создания символичного Deployment.

Далее описываются все этапы его «приключения» до тех пор, пока он не будет создан в кластере. Все запросы, комментарии и пояснения к ним от Автора.

Помимо этого, рассматривается что происходит при изменении ресурса (да, похоже на создание, но именно что похожа), как работают Merge и т.д.

Завершает статью пример использования флага --server-side: сценария, при котором желаемое состояние направляет apiserver и уже он, а не kubectl принимает решение о том, что надо изменить.

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

CWE пакетных менеджеров

Всем привет!

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

После этого он собрал и систематизировал информацию о CWE, которые встречаются как на стороне клиента, так и на стороне реестра.

Например:
🍭 Archive extraction writes outside the target directory
🍭 Argument injection into git, hg, svn, and friends
🍭 Integrity checks that fail open
🍭 Stored XSS in rendered package pages
🍭 Publishing or replacing someone else’s package и не только

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

Для каждой CWE приводится краткое описание (именно от Автора) и примеры CVE, на основании которых был сделан вывод.

Package Proxy: защита supply chain с Cloudflare

Всем привет!

Package Proxy – open-source инструмент, который содержит в себе набор встроенных проверок для работы с пакетами, получаемыми с и использованием популярных пакетных менеджеров: npm, pip, uv и cargo).

Примеры проверок:
🍭 Выпущен не более 10 дней назад (можно параметризировать)
🍭 (Не) входит в перечень разрешённых к установке версий
🍭 Версия пакета не является «yanked»
🍭 Способ загрузки пакета в индекс (не) изменился и не только

Дополнительно можно указать webhook-url, на который будет отправлена информация о заблокированном пакете.

Из нюансов – «локально» установить не получится, решение работает только с Cloudflare.

Подробнее можно прочитать в GitHub-репозитории или вот в этой статье.

Модели угроз пакетных менеджеров

Всем привет!

Недавно мы писали про CWE, характерные для пакетных менеджеров. Но это лишь «начало истории».

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

Именно её перевела на русский язык команда CodeScoring и разместила на Habr’e.

Самое интересное то, что Andrew рассматривает механизмы, которые «работают так, как и задумано», поэтому на них не заводят CVE, но их можно использовать для совершения атак.

Как и в предыдущей статье, внимание уделяется как клиентской части (логике пакетного менеджера), так и серверной (логике пакетного индекса).

Внутри можно найти:
🍭 Выполнение кода до/в момент установки
🍭 Однозначная идентификация имени пакета
🍭 Распределение имён
🍭 Неизменяемость опубликованных версий
🍭 Происхождение от исходного кода до артефакта и не только

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

Это помогает лучше понять, как оно «работает на самом деле» и чего стоит ожидать.

Кроме этого, в статье очень много отсылок на «Package Manager CWEs», что делает её ещё более наглядной.

Однозначно рекомендуем к прочтению!

Secrets Ninja: валидация секретов

Всем привет!

Secrets Ninja – open-source проект, задача которого помочь в валидации найденных секретов, например, при анализе ПО или конфигурационных файлов.

Он поддерживает много сервисов, среди которых:
🍭 Bitbucket, GitLab, GitHub
🍭 Jira
🍭 MongoDB
🍭 NpmToken
🍭 PostgresQL и не только

Работает максимально просто: выбираем нужны сервис, указываем секрет, копируем curl-запрос и смотрим на ответную реакцию.

Можно установить локально (через npm или с использованием Docker) или использовать online-сервис (но лучше всё-таки для целей ознакомления с сервисом).

Observability с Monoscope

Всем привет!

Если вы в поисках observability-решения, которое работает с S3 и использует возможности LLM, то, возможно, Monoscope может вас заинтересовать.

Основные возможности Monoscope:
🍭 Возможность написания запросов «на обычном» языке с использованием LLM
🍭 Подключение агентов, которые будут сообщать об аномалиях
🍭 Оповещения, направляемые по электронной почте
🍭 Наличие графического web-интерфейса, в котором можно посмотреть информацию по событиям

Возможна локальная установка через Docker Compose.  Есть ещё облачная версия, которая обладает большими возможностями (разница приведена в GitHub-repository).

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

k8scout: визуализация путей атак в Kubernetes

Всем привет!

k8scout решает простую, но интересную задачу: «Допустим, что в кластере есть pod с RCE. К чему это может привести?».

Утилита анализирует возможности компрометированного pod и пытается совершить разные «нехорошие действия».

Например:
🍭 Повышение привилегий до cluster-admin
🍭 Горизонтальное перемещение (exec в другие pod, «кража» их токенов)
🍭 Побег из контейнера (через привилегированные контейнеры, hostPID, hostNetwork, hostPath и т.д.)
🍭 Попытки изменения ресурсов кластера
🍭 Изменение конфигурации webhooks, созданных в кластере и т.д.

Результаты работы представлены в виде интерактивной карты (пример которой можно увидеть в GitHub-репозитории проекта).

Каждая сработка содержит идентификатор MITRE ATT&CK, уровень риска и пошаговый путь того, как это было сделано.

Подробности, по классике, в GitHub-репозитории проекта.

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

AppSec: вопросы для собеседований

Всем привет!

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

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

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

Примеры рассматриваемых вопросов:
🍭 Базовые. Объяснить несколько уязвимостей из OWASP Top 10, разница между SAST и SCA и т.д.
🍭 Общие. Точки «встраивания» ИБ в процессы разработки, что и кто делает и т.д.
🍭 Сценарные. Вы нашли X уязвимостей от инструмента Y, что вы будете с ними делать и почему?
🍭 Синтетические. Перед вами пример исходного кода. Есть ли тут уязвимость, какая и чем она опасна, при каких условиях?
🍭 Концептуальные. Как противодействовать brute force атакам, как именно SSL/TLS помогает в защите, разница между шифрованием и хэшированием и т.д.

Помимо безопасной разработки в репозитории есть аналогичные «опросники» и по иным темам: API Security, AI Security, Container Security и не только.

State of MCP Security 2026

Всем привет!

В приложении можно найти небольшой (~ 10 страниц) отчёт, посвященный безопасности MCP-серверов.

«Мы просканировали более 11 000 публично доступных MCP серверов. В отчёте можно найти нюансы, связанные с безопасностью, что мы нашли» - так начинается отчёт.

Примеры статистики из отчёта:
🍭 232 сервера позволяли выполнять произвольный код, запускать команды, десериализировали непроверенные данные и т.д.
🍭 78% из проверенных серверов не использовали dependency pinning
🍭 1617 содержат известные уязвимости. Перечень наиолее часто встречающихся приведён в отчёте
🍭 260 – запускали install scripts на рабочем месте пользователя
🍭 В 31% случаев наблюдались нюансы, связанные с аутентификацией (возможность анонимных вызовов)

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

Кстати, Авторы заметили интересную корреляцию – чем больше у MCP-сервера «звёзд» на GitHub, тем больше у него нюансов с безопасностью.