DevSecOps Talks

AuthN/Z в Kubernetes Всем привет! Если вы хотели разобраться с тем, как работает аутентификация и авторизация в Kubernetes, но не знали с чего начать, то рекомендуем обратить внимание на вот эти статьи (1, 2, 3, 4). В них Авторы очень детально, подробно и доступно объясняют что к чему и как это всё устроено. Всего доступно 4 статьи: 🍭 Kubernetes Authentication: Users and Workload Identities. Как пользователи и ресурсы (нагрузки) аутентифицируются при взаимодействии с Kubernetes API Server 🍭 The mechanics of Kubernetes RBAC. Взаимосвязь Roles, ClusterRoles, ServiceAccounts, RoleBindings и ClusterRoleBindings 🍭 Implementing a custom Kubernetes authentication method. Настройка «стороннего» Identity Provider’a на примере LDAP-каталога 🍭 Authentication between microservices. Аутентификация запросов между несколькими сервисами, запущенными в кластере Каждая статья достаточно большая сама по себе. В ней собрано много теоретических и практических примеров, а также много диаграмм, которые повышают читаемость и упрощают восприятие материала. Самое «то» для погружения в механизмы аутентификации и авторизации в Kubernetes. Рекомендуем!

Автоматический анализ PR’ов Renovate Всем привет! Сейчас никого не надо убеждать в том, что обновление зависимостей – задача крайне важная, которую нельзя оставлять на потом. «Руками» это делать не всегда удобно и хочется использовать средства автоматизации. Одним из таких средств может быть Renovate или его аналоги. Они обновляют зависимости и вроде бы всё хорошо. Но, бывают и такие случаи – обновление на «мёртвые» зависимости, использование deprecated и иные «неприятности», которые трудно заметить, например, из CI. Чтобы решить эту проблему Автор статьи предлагает такой подход: анализ PR’ов, открываемых Renovate с использованием Claude Code. Сам процесс весьма прост: Renovate предлагает изменения, Claude Code их анализирует и предоставляет свой вердикт – можно ли его принимать или есть потенциальные риски. Для этого Автор сделал собственный Claude Skill, в котором всё подробно описал. Кстати, этот Skill доступен в статье и с ним можно подробно ознакомиться. Что в итоге получилось – всё это можно найти в статье. А также информацию о том, как всё это настроить и какие результаты будут предоставлены пользователю.

Kubernetes 101: тестирования на проникновение Всем привет! Если вы только начинаете знакомство с тестированием на проникновение при работе с Kubernetes, то эта статья может быть вам полезна. В ней Автор сделал общий обзор того, на что стоит обращать внимание в первую очередь и какие ИБ-дефекты искать. Статья содержит информацию о: 🍭 Поверхность атаки – основные компоненты Kubernetes и их назначение 🍭 Основные ресурсы, с которыми предстоит «работать» 🍭 Получение учетных данных и повышение привилегий 🍭 Небольшой обзор полезных утилит для проведения тестирования на проникновение Статья очень базовая и хорошо подойдёт для начала. Из плюсов – всё описано очень понятно и лаконично, есть ссылки на полезные материалы по теме. В завершение представлена ссылка на проект Kubernetes Goat, который можно использовать в качестве «стартовой площадки» для оттачивания навыков.

Radar: визуализация кластера Kubernetes Всем привет! Radar – open-source проект, основной задачей которого является визуализация ресурсов, созданных в кластере Kubernetes и их взаимосвязей. С его помощью можно: 🍭 Получать информацию о ресурсах: статус, события, журналы и т.д. 🍭 Редактировать ресурсы и «проваливаться» в их терминал из UI Radar’a 🍭 Увидеть взаимосвязь ресурсов в кластере: pods, services, ingresses и т.д. 🍭 Получать ретроспективную информацию (timeline) о событиях кластера и потреблении ресурсов 🍭 Анализировать трафик. Данные берутся из Hubble (Cilium), Caretta и/или Istio Дополнительно Radar предоставляет ряд возможностей и для ИБ: аудит кластера на соответствие лучшим практикам и анализ прав доступа. Подробности о решении можно узнать в GitHub-репозитории или в официальной документации.

Radar: визуализация кластера Kubernetes Всем привет! Radar – open-source проект, основной задачей которого является визуализация ресурсов, созданных в кластере Kubernetes и их взаимосвязей. С его помощью можно: 🍭 Получать информацию о ресурсах: статус, события, журналы и т.д. 🍭 Редактировать ресурсы и «проваливаться» в их терминал из UI Radar’a 🍭 Увидеть взаимосвязь ресурсов в кластере: pods, services, ingresses и т.д. 🍭 Получать ретроспективную информацию (timeline) о событиях кластера и потреблении ресурсов 🍭 Анализировать трафик. Данные берутся из Hubble (Cilium), Caretta и/или Istio Дополнительно Radar предоставляет ряд возможностей и для ИБ: аудит кластера на соответствие лучшим практикам и анализ прав доступа. Подробности о решении можно узнать в GitHub-репозитории или в официальной документации.

Prempti: Falco для AI Coding Agents Всем привет! Falco – крайне известный инструмент в мире защиты сред контейнеризации. Он позволяет анализировать поведение контейнеров. Теперь с его помощью можно узнать больше о том, какие действия на самом деле реализуют AI Coding Agents. Именно это и делает Prempti, использующая Falco «под капотом». Она позволяет: 🍭 Перехватывать запросы к инструментам в режиме реального времени (shell-команды, работа с файлами, анализ вызова MCP) 🍭 Принимать решения о том, что делать – разрешить, запретить, уточнить 🍭 Получать полный audit trail о том, что происходило при работе агента 🍭 Добавлять собственные правила для анализа (аналогичные правилам Falco) Работает она просто: в случае, когда coding agent пытается использовать tool, Prempti перехватывает вызов перед его выполнением, анализирует и выдаёт вердикт. Кстати, она может работать как в enforce, так и в monitor режимах. Подробнее об утилите можно прочесть в GitHub-репозитории. Важно(!): проект находится в стадии активной разработки, поэтому что-то может (не) работать, а что-то может сильно меняться от релиза к релизу.

Kubernetes RBAC Generator Всем привет! Аудит прав доступа – вечная головная боль. В каких-то системах он происходит менее «сложно», в каких-то – более. Отчасти это связано с гибкой ролевой моделью и её возможностями. Kubernetes в этом плане очень непрост, ведь роль можно создать на любой ресурс, любое действие, да ещё и контролировать границы. Чтобы упростить задачу их создания, была придумана Audicia. Если просто, то она генерирует роли с минимальными привилегиями на основе анализа журналов событий. При помощи неё можно: 🍭 Генерировать роли с минимальными правами, необходимыми ресурсу 🍭 Делать это постоянно, т.к. она работает в качестве operator’a, который присутствует в кластере 🍭 Использовать GitOps-подходы за счет использования сгенерированных CRD 🍭 Выявлять drift в настройках RBAC и не только Сама по себе Audicia ничего не меняет в кластере, а только генерирует манифесты для ролей. Не требует доступа к секретам и иной чувствительной информации. Если вам интересно узнать, как именно она работает, то можно обратиться к GitHub-репозиторию проекта или официальной документации.

MCP Hardening Guide Всем привет! Сегодня хотим предложить вам чтение на выходной! Статью, в которой собраны рекомендации о настройках безопасности при использовании MCP (~ 16 минут). Авторы рассматривают 6 основных разделов: 🍭 Network Isolation 🍭 Dependency and Supply Chain Security 🍭 Secrets Management at Runtime 🍭 TLS Configuration Hardening 🍭 Runtime Behavioral Monitoring 🍭 Pre-deployment Security Gate Для каждого раздела приводится краткое описание, небольшие примеры и перечень требований, по которым можно сделать самопроверку (verification checklist).

Kubernetes: CPU Req/Lim на практике! Всем привет! Управление ресурсами в Kubernetes – одна из основополагающих функций, которая была в нём чуть ли не с самого начала. Однако, спустя годы, всё равно появляются вопросы и разногласия о том, как это делать и что лучше (не) использовать. Ещё одно мнение по этому поводу можно найти в статье. Она хороша для погружения в тему: лаконичные пояснения, примеры, немного математики и кода. В ней Автор описывает: 🍭 Как работает распределение ресурсов CPU (дада, те самые cgroups, про которые мы писали недавно) 🍭 Как работает CPU Sharing в Kubernetes 🍭 Что «скрывают» за собой CPU Requests и Limits 🍭 Как, когда и почему появляется CPU Throttling И в завершении Автор ещё раз рассуждает на тему – нужны ли (и, если да, то когда) CPU Limits или же без них лучше? Тема достаточно неоднозначная и стоит всегда учитывать контекст. Например, как быть с нагрузками, чувствительным к задержкам или управляющим слоем SDS, который может сильно деградировать при нехватке процессорного времени? А что вы думаете по этому поводу?

Git-pkgs proxy: защита от атак на цепочку поставок Всем привет! Одной из причин почему атаки на цепочку поставки ПО актуальны, является неконтролируемое обновление пакетов на «новые версии». И уже в этих «новых версиях» может быть много чего интересного. Да, пакетные индексы работают над тем, чтобы удалять такие вредоносные пакеты… Но это случается не сразу и может занимать дни, а то и недели. В текущих реалиях, когда time-to-exploit радикально сокращается благодаря ИИ, это может быть очень критичным. Для того, чтобы хоть как-то систематизировать и контролировать процесс обновлений, можно обратить своё внимание на проект git-pkgs proxy. Суть крайне простая: он представляет из себя proxy, который не даёт обновиться на новую версию пакета в течение X дней. Например, если lodash обновилась до версии 4.18.0, то в вашей сборке всё ещё будет использоваться версия 4.17.21 в течение 3-х дней. Временной интервал можно настраивать, о чём (и не только) подробно расписано в GitHub-репозитории проекта. Утилита работает более чем с 20-ю индексами, среди которых npm, PyPi, Conda, Maven, Debian, Helm и не только. Да, не все они «полностью» готовы, но Автор собирается развивать проект. А как вы работаете с проблемой отсутствия контроля обновления зависимостей?

🛍 Территория мерча БеКон 2026 ОТКРЫТА! 🔥 Забирай фирменный мерч БеКона — собирай пак уже сейчас! 👕 Что в коллекции: Уже знакомые и полюбившиеся позиции + новые лимитированные дропы! 📏 Размеры: от S до 5XL — найдётся на каждого! 📦 Как это работает: Выбираешь товары на сайте и оформляешь заказ. Оплачиваешь онлайн — всё просто и безопасно. Забираешь мерч лично на конференции 2 июня 2026. 📍 Пункт выдачи: г. Москва, ул. Большая Почтовая, д. 40, стр. 7 (локация БеКон 2026) 🎫 Как получить: подойди к стойке выдачи, назови номер заказа — и забирай свой пак! 🤝 Не можешь лично? Передай номер заказа другу или коллеге — доверенность не нужна. ⚠️ Важно знать: • Отмена заказа: бесплатно — строго до 12:00 1 июня 2026 (письмо на bekon@luntry.ru). • Возврат: после получения на конференции возврат не предусмотрен — проверяй размер и комплектацию при выдаче • Брак: если обнаружил дефект — пиши на bekon@luntry.ru до 5 июня включительно, организуем замену 🗓 2 июня 2026 | Москва, Лофт ГОЭЛРО 👉 Собрать свой пак

Cgroups: что это такое и зачем они нужны? Всем привет! Если упростить, то cgroups - механизм ядра Linux, который позволяет управлять вычислительными ресурсами. Казалось бы, всё просто! Но это не совсем так. Если вам хочется более подробно ознакомиться с тем, что это такое и как это устроено, то рекомендуем ознакомиться со статьей (она достаточно объёмная). В ней Автор рассказывает о: 🍭 Том, что такое cgroups и как они устроены 🍭 Том, как происходит управление cgoup’ами, что такое controllers 🍭 Наследовании cgroups и их иерархической структуре 🍭 Недостатках первой версии (cgroups) и причинах появлении второй (cgroupsv2) 🍭 Сравнительном анализе разных версий cgroups и не только Помимо теории в статье есть практические примеры: создание собственной cgroup’ы, блокирование frok-bomb и т.д.. А ещё – немного истории о том, как этот механизм развивался со временем! Рекомендуем!

БеКон 2026: вкуснейшие ингредиенты и лучшие рецепты! Всем привет! Кто-то ждёт лето, кто-то тёплую погоду, кто-то – долгожданный отпуск, а кто-то… Конечно же единственную конференцию по безопасности контейнеров и контейнерных сред – БеКон! В этом году команда Luntry уже в 4-ый раз собирает всех неравнодушных к тематике защиты контейнеров в Москве, 2-ого июня 2026 года! На этот раз нас ждут сразу несколько направлений – Ингредиенты (про технологии) и Рецепты (про людей и процессы). Спикеры из Axiom JDK, ГК АСТРА, Т-Банка, Альфа-Банка, Luntry, Инфосистемы Джет и не только будут делиться своим опытом. Помимо этого, посетителям будет доступна выставочная зона, в которой производители ИБ и ИТ-решений будут рады пообщаться: Штурвал, Deckhouse, Orion Soft, Hexway, Axel PRO и многие другие! И, конечно же, будет ещё один «Секретный доклад». Кто помнит, что было представлено в том году и насколько оно вам понравилось – пишите в комментариях! Детальную информацию о мероприятии, включая описание программы, можно найти на официальном сайте. До встречи на БеКоне! ❤️❤️❤️

Kubernetes: что меняется от Dev до Production? Всем привет! Есть известная фраза, что «Kubernetes – это просто 5 бинарей». С этим сложно спорить. Но это может породить некоторую иллюзию простоты. Поначалу не задумываешься о то, насколько сильно один и тот же Kubernetes-кластер может преобразиться от Development-инсталляции до Production. Именно этому и посвящена статья. В ней Автор описывает про что нужно знать/помнить, чтобы было не очень «больно» в процессе перехода между этими состояниями. Он выделил 7 ключевых возможностей/потребностей: 🍭 Make Infrastructure Repeatable 🍭 Integrate The Product End-To-End 🍭 Move Delivery To GitOps 🍭 Restructure The Repository For Environments 🍭 Add Validation And Policy Guardrails и не только Именно это, по мнению Автора, позволит быть уверенным, что всё либо будет работать, либо можно будет привести в работающее состояние. И, получается, что у нас не просто «5 бинарей», а набор инструментов, процессов и специалистов, которые это всё поддерживают. В самой же статье очень много пояснений и комментариев, а представлена она в формате истории о «переезде», в котором и были учтены пункты, описанные выше. Читается легко и непринуждённо, рекомендуем!

Управление (утекшими) секретами при работе с VCS Всем привет! Рано или поздно, так или иначе, но секреты окажутся в кодовой базе. Но что делать и как быть? Начало ответа на этот вопрос можно найти в статье. Автор рассматривает полный жизненный цикл того, что (не) надо делать при работе с git-репозиториями и чувствительной информацией. Например: 🍭 Stop Hardcoding Credentials in Your Code (кто бы мог подумать). Про переменные окружения и работу с .*-ignore-файлами 🍭 Managing Secrets in Collaborative Environments. Использование Vault и его аналогов 🍭 Detecting Secrets Already in Your Git History. Сканирование репозиториев для выявления секретов 🍭 Review Findings and Remove False Positives. Оценка того, насколько сработки, полученные на предыдущем этапе, актуальны 🍭 Rewrite History with git-filter-repo. Инвалидация секретов, устранение секретов из кодовой базы По каждому разделу даётся небольшой набор рекомендаций и советов о том, что можно делать и каким средством автоматизации можно воспользоваться. В итоге получилась очень хорошая обзорная статья. Особенно для тех, кто только начинает погружаться в тему.

Kunobi: централизованное управление Kubernetes Всем привет! Управление кластерами Kubernetes, их ресурсами и GitOps-практиками через единый удобный, быстрый и красивый web-интерфейс. Примерно так можно описать Kunobi. Из ключевых особенностей можно отметить: 🍭 Локальная установка. Никаких облаков, никаких «внешних соединений» 🍭 Работа с Flux и ArgoCD через привычный интерфейс 🍭 Возможность анализа Helm Releases для идентификации изменений Создание кластеров через UI 🍭 Поддержка нужного ПО «из коробки» (Cert Manager, Prometheus, External Secrets и т.д.) и не только Посмотреть на то, как это выглядит можно по ссылке. Представлены ролики по таким областям, как: Explore/Debug, GitOps, Flux, Workspaces/Presets. Подробности про функциональные возможности можно узнать из документации на Kunobi. И остался вопрос – «Сколько стоит?». Пока что ответ такой: «Free for everyone today. When we launch paid plans, you keep your free tier — no surprises, no credit card required». Напишите своё мнение, если вам уже удалось воспользоваться инструментом: насколько он удобен и полезен?

SmokedMeat: CI/CD Red Team Framework Всем привет! SmokedMeat – open-source проект, который представляет из себя CI/CD Red Team Framework. Сами Авторы описывают его так: «Like Metasploit, but for CI/CD pipelines». Основная задача SmokedMeat – поиск уязвимостей (и их подтверждение) в конфигурациях конвейеров сборки. Можно сказать, что он поддерживает «полный цикл»: 🍭 Analyze. Поиск уязвимостей в настройках конвейера сборки 🍭 Exploit. Эксплуатация найденных на предыдущем этапе уязвимостей 🍭 Post-exploit. Эксфильтрация данных 🍭 Pivot. Попытки расширения области своего присутствия В текущей редакции поддерживается 6 CI/CD решений: GitHub Actions, GitLab CI, Azure DevOps, CircleCI, Jenkins, Bitbucket. Для эксплуатации SmokedMeat может использовать следующие техники: PR, issue, comment, LOTP, workflow dispatch. Больше информации о его возможностях, архитектуре, способах запуска можно найти в GitHub-репозитории проекта. Важно(!): это не «пассивный» инструмент. Если вдруг захотите его использовать – лучше делать это с умом и всё перепроверить 😊

Practical Package Security: The Unofficial Guide Всем привет! По ссылке доступен материал от Wiz, в котором ребята рассматривают вопросы обеспечения ИБ при работе с пакетами и пакетными менеджерами. Статья структурирована по разделам: 🍭 Easy(ier) Wins for Package Security. Не обновляться сразу, использовать lockfiles, анализировать пакеты в момент загрузки и т.д. 🍭 Protecting the Execution Environment. Использование эфемерной ИТ-инфраструктуры, соблюдение принципов Zero Trust 🍭 Controlling What Gets Installed. Использование proxy для загрузки пакетов, периодический анализ того, что хранится локально Материал является «общим» и найти конкретных шагов по «безопасной настройке npm» не получится. Однако! В статье собраны основные идеи, из которых можно сделать собственные наборы требований, адаптированные под конкретных технологии.

HPA, VPA или KEDA: что выбрать? Всем привет! Среднестатистический кластер Kubernetes утилизирует 13% CPU и 20% RAM (согласно данным отчёта CNCF 2024 Kubernetes Benchmark Report). 87% остаются «простаивать». Чтобы устранить этот «недостаток» есть 3 autoscaler'a: HPA, VPA и KEDA. Каждый из них решает свою задачу или делает это чуть иначе, чем «сосед». И тут встаёт вопрос: а какой из них выбрать? Как сделать потребление ресурсов максимально эффективным? Чтобы найти свой ответ на этот вопрос можно обратиться к статье. В ней Автор рассматривает: 🍭 Общие принципы работы каждого из представленных autoscaler’ов 🍭 Проводит небольшой сравнительный анализ 🍭 Приводит рекомендации о том, когда можно/нельзя их комбинировать 🍭 Предлагает алгоритм того, как выбрать то, что в большей степени подойдет вам В статье много интересной статистики, примеров и пояснений того, что происходит «внутри». Да, не супер-технически-детально. Но! Для базового погружения – в самый раз!