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 минут
💻 Формат: онлайн
👉 Регистрация на вебинар

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

Infra-Bench: оценка ИИ-агентов

Всем привет!

Infra-Bench – open-source проект, который представляет из себя набор тестов для оценки того, насколько ИИ-агенты пригодны для решения задач, связанных с ИТ-инфраструктурой.

На текущий момент есть тесты для Kubernetes.

22 «легких» задачи, 27 «средних» и 22 «сложных».

Примеры задач:
🍭 Легкая. Восстановить «потерянный» ConfigMap
🍭 Легкая. Изменить конфигурацию роли, добавив в неё необходимые глаголы
🍭 Средняя. Восстановить возможность отображения логов в Grafana
🍭 Средняя. Создать ресурс на узле, который соответствует определённым требованиям
🍭 Сложная. Сделать drain узла, сохранив работоспособность всех ресурсов
🍭 Сложная. Восстановить работоспособность приложения

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

С результатами выполнения задач (GPT-5.5, Opus-4.6, Sonnet-4.6, Gemini-3, Kimi-k2-5 и т.д.) можно ознакомиться по ссылке.

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

Как реализовать управление секретами ничего не сломав?

Всем привет!

Когда вопрос вступает о правильном управлении секретами, то кажется, что всё очень просто. Рано или поздно появляется Vault (или его аналоги) и кажется, что проблема решена.

Но всё может быть не так однозначно. Ведь «нельзя просто взять и поставить Vault».

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

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

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

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

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

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

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

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

Статьи достаточно объёмные и хорошо раскрывают как проблематику, так и возможное решение.

Рекомендуем к изучению!

Секреты в образах контейнеров

Всем привет!

Допустим, мы случайно разместили секрет в git-репозитории. Поняли, что сделали и удалили его.

Вроде бы всё в порядке… Но секрет всё равно останется в git-истории и его можно будет найти.

А что, если подобное произойдет при работе с образом контейнера? Например, мы добавляем секрет в один из слоёв, а потом удаляем.

Можно ли будет его найти? Если коротко, то «Да». Если хочется подробностей, то они есть в этой небольшой статье.

В ней Автор делает следующее:
🍭 Добавляет секрет в файл, который находится в образе контейнера
🍭 Удаляет секрет
🍭 Анализирует секрет с помощью docker inspect
🍭 Уточняет данные путём анализа слоев образа

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

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

Freelens Pod File Browser

Всем привет!

Если вы используете Freelens в повседневной работе и иногда нужно как-то взаимодействовать с файлами, расположенными в контейнерах, то Freelens Pod File Browser может упростить задачу.

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

С его помощью можно:
🍭 Осуществлять навигацию по файловой системе контейнера
🍭 Открывать и редактировать файлы
🍭 Загружать/Скачивать файлы
🍭 «Переключаться» между контейнерами в pod и не только

Устанавливается очень просто. Подробности (включая скриншоты того, как это выглядит) можно найти в GitHub-репозитории или на сайте плагина.

Пакетные менеджеры и контроль целостности

Всем привет!

Кажется, что контроль целостности начал или начинает доминировать над контролем конфиденциальности и доступности.

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

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

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

Он проанализировал такие возможности как: использование hash-значений, применение электронной подписи (на стороне репозитория, на стороне разработчика) и иные возможности.

Что получилось, возможности пакетных менеджеров по контролю целостности – всё это можно найти в статье.

И ещё ряд весьма интересных случаев. Например, когда hash-значение присутствует, но не используется для контроля целостности.

Да, менеджер скачает пакет, уточнит, что hash-значение не совпадает, и… установит пакет! И это документированное поведение по умолчанию.

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