Kubernetes Events

Всем привет!

События (events) в Kubernetes не всегда кажутся чем-то значимым, но это не так.

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

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

Начинается она с небольшой «исторической справки»: когда в Kubernetes появились события и для чего они были нужны.

Далее Автор описывает:
🍭 Что такое события в Kubernetes
🍭 Разновидности событий
🍭 Для чего события можно использовать
🍭 Как реагировать на события и не только

Всё это Автор рассматривает с точки зрения создания собственного controller’a, чтобы более наглядно показать, как и для чего можно использовать события.

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

Secure Software Factory

Всем привет!

Software Factory всё больше и больше становятся «автономными»: есть prompt/задача/спецификация, которая превращается в работоспособную функциональность силами ИИ и их агентов.

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

Часто бывает так, что жертвой такой «продуктивности» становится информационная безопасность.

Ведь о ней думают в меньшей степени, когда есть возможность «сделать feature в разы быстрее».

Естественно, что ни к чему хорошему это не приводит. Иногда, агент может удалить базу данных с production-данными.

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

Как быть? Мнение на этот счёт можно найти в прилагаемом файле. В нём Авторы описывают концепт Secure Software Factory.

Он «строится» на 4-х основах: Sandboxing, Network, Supply Chain и Identity & Access.

Это только первая часть, которая контролирует ограниченную среду выполнения агентов.

Вторая часть – Execution & Observability. Контроль запуска агентов, сбор информации об их действиях (в том числе и для улучшения самой Software Factory).

Дополнительно рассматривается несколько уровней автономности подобных «систем»: от Human-Orchestrated до Agent-Orchestrated и много чего ещё интересного.

Кстати! Дополнительную информацию по Secure Software Factory, включая описание различных контролей, можно найти на сайте.

Hortator: контроль запуска AI-агентов

Всем привет!

Hortator – open-source утилита, которая представляет из себя Kubernetes-оператор, позволяющий агентам запускать других AI-агентов.

Каждый агент, запускаемый Hortator, работает в собственном pod, со своим контекстом, бюджетом и ИБ-ограничениями.

Можно настроить следующее:
🍭 Безопасность. Сетевые политики, управление полномочиями («дочерний» агент не может иметь больше полномочий, чем «родительский»), RBAC
🍭 Бюджет. Ограничение по токенам, отслеживание потраченных ресурсов в LLM
🍭 Чувствительные данные. Входные и выходные данные проверяются на наличие секретов
🍭 Мониторинг «здоровья». Получение сведений о том, что задача «все ещё выполняется»
🍭 Мониторинг. Задачи (общее количество, выполненные, время выполнение задачи и т.д.)

Часть функциональности (например, контроль чувствительных данных и работа с бюджетом) доступна только в enterprise-версии.

О том, как устроен Hortator, как он работает, как его запускать и настраивать можно прочесть в GitHub-репозитории проекта.

Лабораторные работы по Kubernetes

Всем привет!

Как можно неплохо провести выходные? Конечно, решая лабораторные работы по Kubernetes.

Например, SnowOps Labs! Выбираете сценарий, запускаете и пытаетесь разобраться что произошло.

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

Доступны разнообразные лабораторные работы:
🍭 Observability & SRE
🍭 GitOps & CI/CD
🍭 Security & Compliance
🍭 Chaos Engineering
🍭 Autoscaling Under Load и т.д.

Для удобства есть графический web-интерфейс, где можно выбрать то, что наиболее интересно.

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

Например, для Security & Compliance надо будет скорректировать конфигурации для соответствия «требованиям» Kyverno, перевести несколько политик в другой режим работы, добавить исключения и т.д.

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

Управление ИБ-дефектами: опыт SalesForce

Всем привет!

В статье описан опыт команды SalesForce по обработке большого количества ИБ-дефектов.

С появлением AI/LLM старая «проблема» для команды стала ещё более осязаемой.

Количество ИБ-дефектов, которые находят сканеры и модели, существенно возросло. При этом возросла и скорость, с которой они находятся.

А скорость, с которой можно исправлять находки – нет.

Получается, что поиск ИБ-дефектов осуществляется со «скоростью машины», а устранение – «со скоростью человека».

Чтобы решить эту задачу, ребята из SalesForce определили для себя два основных направления: стратегическое и тактическое.

Если кратко, то:
🍭 Стратегическое. Поиск ИБ-дефектов, которые характерны для многих разработок Компании. Их группировка и последующее устранение.
🍭 Тактическое. Подтверждение актуальности конкретных ИБ-дефектов, подготовка PoC. Для тех случаев, которые не являются «общими» и не попадают в стратегическое направление

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

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

Завершает статью перечень верхнеуровневых рекомендаций/lessons learned, которые сформировала для себя команда после использования такого подхода «внутри».

cve.now: ещё один feed по уязвимостям

Всем привет!

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

Он агрегирует информацию из разных источников: перечня CVE, различных баз данных (OSV, GitHub Security Advisory, NVD и других).

Для каждой CVE доступна «классическая» информация:
🍭 Описание
🍭Подверженные версии
🍭Версии с исправлениями
🍭CVSS-оценки
🍭Ссылки на дополнительные ресурсы

Отличает cve.now то, что раздел с описанием уязвимости содержит «понятное» содержание, сгенерированное с использованием LLM.

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

Или использовать ресурс в качестве MCP-сервера. Инструкции по подключению доступы на сайте для Claude, Cursor, Codex и не только

KAI-Scheduler: планировщик GPU для Kubernetes

Всем привет!

kube-scheduler в единицу времени размещает один pod на одном узле, используя собственную логику работу (подробнее об этом мы писали тут).

Такой подход хорошо оправдывает себя для stateless-контейнеров, но не подходит для работы с AI.

Чтобы решить эту проблему Nvidia сделала собственный планировщик – KAI-Scheduler (является CNCF Sandbox Project), с которым можно ознакомиться тут.

Именно принципам его работы и посвящена сегодняшняя массивная статья (~ 35 минут на прочтение).

В ней Автор сделал основательный обзор KAI-Scheduler:
🍭 Обзор архитектуры и ключевых компонентов
🍭 Процесс создания ресурсов: от kubectl apply до запущенных контейнеров
🍭 Описание алгоритма планирования, который использует KAI-Scheduler
🍭 Работа с очередями, принципы планирования, PodGroups и SubGroups (да, в отличие от kube-scheduler он работает сразу с группами pod)
🍭 Как устроен GPU Sharing и не только

В завершение статьи Автор показывает, как можно установить, настроить KAI-Scheduler и поискать ошибки, если таковые возникнут.

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

Если вам хочется чего-то «зубодробительного», то статья однозначно вам понравится!

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

Кстати! KAI-scheduler может работать в качестве второго планировщика. Т.е. можно использовать его совместно с `kube-scheduler` и выбирать оптимальный вариант в зависимости от ситуации (просто указав `schedulerName: kai-scheduler`).

Доверие к зависимостям в контейнерах

Всем привет!

Использование зависимостей может как ускорить разработку, так и расширить поверхность атаки.

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

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

Однако, Автора статьи заинтересовал другой вопрос. «А можно ли что-то сделать силами обычного контейнера?».

Без использования Sidecar, без использования CNI или ServiceMesh и иных способов защиты.

Ответом стал nono – «песочница», которая может контролировать (не) допустимые действия внутри контейнера.

Для проверки Автор реализовал сценарий:
🍭 Создал небольшое JS-приложение
🍭 Добавил туда «вредоносную» зависимость, которая эмулировала эксфильтрацию секретов
🍭 Подготовил nono-profile, в котором определил допустимые сетевые взаимодействия
🍭 Проверил то, что получилось с «обычным» образом и с «nono-образом»

Получилось так, что разрешённое поведение отработало «как надо», а попытка доступа к недоверенному ресурсу была заблокирована.

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

Нюансом подхода может быть масштабирование – создание разных профилей, их распространение и применение.

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

KuBeer Talks #4: все московское (и не только) сообщество кубера будет там

5 ноября в 19:00 K8s-комьюнити проведет юбилейный KuBeer Talks. Место встречи — бар Spaten Haus в Москве.

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

В программе:

🍭 Екатерина Низовцева — «Опыт работы с VTEP-схемой в Cilium»
🍭 Артём Горячев — «Закон Гудхарта для бекапов K8s»
🍭 Алексей Свиридкин — «Ревью кода в эпоху нейрослопа»
🍭 Открытый микрофон — для всех, кому есть чем поделиться

Количество мест ограничено. Вход по предварительной регистрации.

DockLog: просмотр логов контейнеров и не только

Всем привет!

DockLog – простая утилита, которая позволяет удобно выполнять повседневные операции с контейнерами. Работает как с Docker, так и с Kubernetes.

Притом что можно выбирать – Docker, Kubernetes или сразу оба варианта.

Всё взаимодействие реализовано через графический web-интерфейс.

При помощи DockLog можно:
🍭 Получать сводную информацию о запущенных контейнерах
🍭 Смотреть логи контейнеров
🍭 Управлять контейнерами (запускать, останавливать, удалять и т.д.)
🍭 Получать информацию по используемым вычислительным мощностям
🍭 Отправлять уведомления

Дополнительно реализовано управление доступом с использованием ролевой модели.

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

От ноутбука DevOps до прода: как атакуют инфраструктуру разработки

Всем привет!

За последние пару дней произошло сразу два интересных инцидента, связанных с безопасностью инфраструктуры разработки:
🚨 Binance сообщила об атаке, которая, предположительно, началась с компрометации ноутбука DevOps-инженера. Злоумышленники получили доступ к сервисному контейнеру и инициировали несанкционированные транзакции. Предварительная оценка масштаба инцидента - $6,3 млрд (не подтверждённая сумма потерь).
🚨 Claude Code - в маркетплейсе расширений Cursor обнаружили вредоносную версию 2.1.313, которая пыталась установить SSH-бэкдор, добавить ключ злоумышленника и обеспечить постоянный доступ к рабочей станции разработчика.

Казалось бы, разные истории. Но обе заставляют задуматься насколько защищена инфраструктура, через которую создаётся и поставляется ПО.
GitLab, Jenkins, CI/CD-раннеры, Registry, Kubernetes - всё это связано между собой через токены, сервисные учётные записи и доверенные интеграции.
А значит, компрометация одного компонента потенциально может стать отправной точкой для атаки на всю цепочку поставки. И даже идеально настроенные SAST, DAST и SCA здесь не помогут.

10 ноября проведём вебинар «От ноутбука DevOps до прода: как атакуют инфраструктуру разработки».
На нём вместе с экспертами «Инфосистемы Джет» разберём:
🔍 Как злоумышленник может пройти путь от рабочего места разработчика до production
🔍 Какие ошибки в настройках VCS, CI/CD и Registry позволяют развивать атаку
🔍 Почему безопасность кода ≠ безопасность инфраструктуры разработки
🔍 Как искать, проверять и устранять потенциальные цепочки атак

Будет технический разбор сценариев, практические подходы к аудиту и рекомендации по защите. Без абстрактных страшилок и общих рассуждений!

📅 Когда: 10 ноября 2026 года
⏱️ Продолжительность: 60 минут
💻 Формат: онлайн
👉 Регистрация на вебинар

Присоединяйтесь! Будет интересно