Исследование · Рабочая среда AI

Kubernetes для AI-нагрузок: границы между моделью, RAG, секретами и агентами

Какие меры укрепления кластера помогают ограничить радиус поражения AI-нагрузки и где необходимы прикладные контроли.

Иллюстрация к материалу «Kubernetes для AI-нагрузок: границы между моделью, RAG, секретами и агентами»
Темы:инфраструктуразащита данныхDevSecOpsцепочка поставки

Kubernetes удобен для изоляции и эксплуатации AI-нагрузок, но не является самостоятельной защитой LLM, RAG или агента. Зрелый контур соединяет базовое укрепление кластера с прикладными правилами для контекста, инструментов и данных.

01

Сначала определите границы нагрузки

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

02

Запрещайте связи по умолчанию

Политика сети, если её поддерживает используемый сетевой компонент, помогает явно разрешить только нужные связи между шлюзом, обслуживанием модели, поиском контекста и разрешёнными внешними программными интерфейсами. Это сокращает достижимость соседних сервисов и административных интерфейсов. Но политика сети не определяет, имеет ли пользователь право увидеть документ в RAG: эту проверку нужно делать до поиска.

03

Поставка и секреты

Образы, веса модели, эмбеддинги, расширения и конфигурации требуют проверяемого происхождения. Используйте утверждённые реестры, фиксированные версии и политики допуска. Секрет не должен попасть в пользовательский запрос, журнал трассировки или ConfigMap; применяйте внешнее хранилище секретов, минимальные права и короткий срок жизни токенов там, где это возможно.

04

Телеметрия рабочей среды

Журнал Kubernetes, события доступа, изменения развёртываний и происхождение образов дополняйте журналами AI-шлюза, поиска контекста и вызовов инструментов. Такая связка позволяет увидеть не только изменение пода, но и то, к каким данным, модели и действиям оно дало путь.

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

Продолжите исследование

Связанные риски

Карточки связывают материал с конкретными угрозами, признаками и мерами защиты на интерактивной карте.

A20 · Высокий

Malicious model deserialization / pickle

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

Открыть карточку
A21 · Высокий

Typosquatted or fake model repository

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

Открыть карточку
A30 · Высокий

Denial of ML service

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

Открыть карточку
A31 · Критический

GPU local memory leakage / shared accelerator risk

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

Открыть карточку
A32 · Высокий

Unauthorized access to model endpoints

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

Открыть карточку
Открыть интерактивную карту угроз
Первоисточники

Международные источники и практики

Сначала мы объясняем практический смысл материала на русском. Ниже — первоисточники для проверки и детального изучения границ применимости.

CISAJoint Guidance on Deploying AI Systems SecurelyБезопасное внедрение AI-систем.CISA / NSACareful Adoption of Agentic AI ServicesКонтроли для agentic AI.GoogleSecure AI Framework (SAIF)Secure-by-default AI, privacy и управление риском.