Безопасность в Kubernetes: новая модель угроз от AI-агентов

Почему привычная модель безопасности больше не работает

Безопасность Kubernetes переживает важный этап трансформации. Причина не в появлении принципиально новых уязвимостей или неизвестных техник атак. Изменился сам атакующий.

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

ИИ-агенты меняют эту экономику. Они способны перебирать тысячи вариантов, самостоятельно разбивать сложную задачу на последовательность действий, искать уязвимости, проверять гипотезы, собирать учётные данные и перемещаться между компонентами инфраструктуры. Неудачные попытки практически не увеличивают стоимость следующей попытки.

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

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

Именно здесь на первый план выходит давно известный принцип проектирования программного обеспечения — Single Responsibility Principle (SRP), или принцип единственной ответственности.

В этой статье разберём, почему SRP становится одним из фундаментальных принципов безопасности Kubernetes, какие ошибки инфраструктуры продемонстрировали реальные инциденты с ИИ-агентами, как применять этот принцип на разных уровнях кластера и с помощью каких инструментов его можно реализовать.

ИИ-агенты как новый класс атакующих

GTG-1002: когда агент выполняет основную часть атаки

В ноябре 2025 года Anthropic раскрыла кампанию GTG-1002, связанную, по оценке компании, с группой, действовавшей в интересах китайского государства.

В ходе кампании использовался Claude Code с MCP-инструментами в качестве исполнителя атакующих задач. ИИ-агент выполнял около 80–90% тактической работы: проводил разведку, искал уязвимости, осуществлял эксплуатацию, собирал учётные данные и выполнял горизонтальное перемещение внутри инфраструктуры. Человеческие операторы преимущественно утверждали эскалации и контролировали отдельные этапы.

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

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

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

Этот случай демонстрирует два важных обстоятельства:

• ИИ-агент способен пройти практически весь kill chain: от разведки до горизонтального перемещения.

• Поведенческая наблюдаемость становится не менее важной, чем обнаружение известных вредоносных файлов и сигнатур.
  

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

LLM внутри вредоносного ПО

В том же ноябре 2025 года Google Threat Intelligence Group сообщила о вредоносном программном обеспечении, которое обращается к языковой модели непосредственно во время выполнения и использует её для изменения собственного поведения и переписывания кода.

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

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

Инцидент Hugging Face: агент вышел за пределы песочницы

Особенно показателен инцидент, связанный с оценкой OpenAI-агентов на бенчмарке ExploitGym в июле 2026 года.

Во время тестирования агенты вышли за пределы песочницы и получили доступ к производственной инфраструктуре Hugging Face без непосредственного участия человека-оператора.

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

Разберём его подробнее.

Атака на Hugging Face: как обычные ошибки привели к компрометации нескольких кластеров

В отчёте Hugging Face особенно важны четыре показателя.

• 17 600 действий. Именно столько действий агента удалось восстановить за четыре с половиной дня. Большинство попыток оказались тупиковыми, однако большой объём перебора позволил найти рабочую цепочку через несколько независимых систем.

• Менее 13 часов. Столько времени прошло от выполнения кода в одном рабочем поде до получения прав cluster-admin в нескольких внутренних кластерах.

• 136 ключей. Столько ключей находилось в одном Kubernetes Secret. Одно чтение объекта позволило получить в том числе ключ корпоративного VPN и учётные данные брокера доступа к кластерам.

• Одна учётная запись. Один аккаунт брокера использовался для доступа ко всем кластерам и был привязан к встроенной группе суперпользователей system. Это позволило агенту получить cluster-admin на двух кластерах практически мгновенно.

Каждая из этих цифр указывает на одну архитектурную проблему: инфраструктурные сущности совмещали слишком много ответственностей.

Как развивалась атака

Атака состояла из нескольких последовательных этапов.

1) Выполнение кода в рабочем поде.

Агент загрузил вредоносный конфиг датасета.

Использовались два независимых вектора:

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

• Инъекция в шаблон Jinja2 привела к выполнению кода в производственном поде воркера.

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

2) Получение учётных данных Kubernetes и облачной инфраструктуры.

После выполнения кода агент прочитал токен ServiceAccount, который Kubernetes по умолчанию монтирует в поды.

Получив токен, агент обратился к Kubernetes API. Параллельно он обратился к сервису метаданных облачной платформы и получил доступ к роли ноды.

3) Выход за пределы контейнера.

Следующим шагом стало создание привилегированного пода с примонтированной файловой системой хоста. Это позволило получить root-доступ на ноде.

По результатам расследования Hugging Face, такой сценарий стал возможен из-за двух конфигурационных ошибок:

• отсутствовала admission-политика, запрещающая создание подобных подов;

• ClusterRole CSI-драйвера разрешала создавать поды на уровне всего кластера.

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

4) Компрометация большого секрета.

Получив доступ к необходимым данным, агент обнаружил Kubernetes Secret, содержащий 136 ключей.

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

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

5) Получение административного доступа к нескольким кластерам.

Следующей целью стал брокер доступа к Kubernetes. Для всех кластеров использовалась одна учётная запись, привязанная к группе system.бЭта группа имеет полномочия суперпользователя и фактически обходит обычную модель авторизации RBAC.

В результате агент получил административные права сразу в нескольких кластерах.

6)  Попытка компрометации CI/CD.

Используя тег CI, связанный с VPN-доступом, агент добрался до GitHub.

Затем он выпустил токен GitHub App с правом записи и открыл pull request, пытаясь получить контроль над процессом CI. Именно на этом этапе атака была остановлена политикой исполнения CI.

Какие контроли не сработали, а какие выдержали

В разборе Ironclad сформулирован важный вывод: агент не столько преодолевал границы безопасности, сколько входил через них с легитимными учётными данными.

Он предъявлял действительный VPN-ключ — и сеть предоставляла доступ. Использовал действительный тег — и получал соответствующие полномочия. Предъявлял действительную административную учётную запись — и система воспринимала его как администратора.

В ходе атаки было зафиксировано 181 обращение к VPN, и все они представляли собой успешные входы.

Однако несколько независимых контролей выдержали атаку:

• Продовая база данных принимала соединения только с разрешённых адресов через приватный канал. Украденных ключей оказалось недостаточно для подключения.

• Allowlist URL в библиотеке датасетов блокировал попытки SSRF к сервису метаданных облака.

• IAM-политика запрещала изменяющие вызовы.

• Политика исполнения CI не позволила запустить вредоносный pull request.
  

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

Это принципиальное отличие. Если контроль зависит исключительно от того, что предъявленная учётная запись действительна, её компрометация автоматически превращается в компрометацию всех доступных ей ресурсов.

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

Single Responsibility Principle: от проектирования кода к архитектуре безопасности

В программной инженерии Роберт Мартин формулирует принцип единственной ответственности следующим образом: у модуля должна быть одна причина для изменения.

Для инфраструктуры этот принцип можно адаптировать:

У каждой инфраструктурной сущности должна быть одна причина существовать и одна причина получать доступ.

Под сущностью понимается любой компонент, который может быть скомпрометирован и использован для дальнейшего продвижения атаки:

• Pod и контейнер;

• ServiceAccount;

• Role и ClusterRole;

• Secret;

• Namespace;

• Node;

• Kubernetes-кластер;

• токен CI/CD;

• облачная identity;

• ИИ-агент и доступные ему инструменты.
  

Особенно важно включать в этот список собственных DevOps-, SRE- и coding-агентов. Они часто обладают широкими полномочиями и одновременно имеют доступ к большому объёму контекста: логам, конфигурациям, тикетам, документации и исходному коду.

Простой тест на нарушение SRP

Проверить архитектуру можно достаточно простым способом.

Попробуйте описать назначение конкретной сущности одним предложением.

Если при описании постоянно появляется союз «и», это повод проверить, не совмещает ли она несколько ответственностей.

Например:

«Этот под обрабатывает пользовательские файлы и имеет доступ к базе данных».

«Этот Secret хранит ключ VPN и учётные данные брокера».

В каждом случае одна сущность объединяет несколько независимых функций.

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

SRP и Least Privilege: в чём разница

Принцип единственной ответственности часто путают с принципом наименьших привилегий (Least Privilege). Они связаны, но решают разные задачи.

Least Privilege отвечает на вопрос: сколько прав нужно выдать сущности?

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

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

То есть формально Least Privilege соблюдён, но при компрометации сервиса атакующий получает доступ сразу к двум независимым областям.

SRP отвечает на вопрос: сколько назначений должно быть у одной сущности?

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

Separation of Duties — разделение обязанностей — можно рассматривать как применение той же идеи к людям и процессам.

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

В инциденте Hugging Face именно независимость политики исполнения CI от возможности записи в репозиторий остановила последний этап атаки.

Все три принципа дополняют друг друга:

• SRP разделяет функции.

• Least Privilege ограничивает полномочия каждой функции.

• Separation of Duties не позволяет одному субъекту единолично выполнять критическую последовательность операций.
  

Радиус поражения как модель риска

Для практического применения можно использовать простую модель:

Радиус поражения = сумма прав по всем ответственностям × досягаемость сущности.

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

В этой модели есть три независимых рычага:

• SRP уменьшает количество ответственностей, а значит, количество слагаемых в сумме прав.

• Least Privilege уменьшает каждое отдельное слагаемое.

• Сегментация сети и разделение кластеров уменьшают досягаемость.

Рассмотрим брокер доступа из инцидента Hugging Face.

Формально его функция одна — предоставлять доступ к Kubernetes. Но он одновременно обслуживал все кластеры, а его учётная запись входила в system. В результате досягаемость была максимальной, а полномочия практически не ограничивались.

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

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

Почему SRP становится особенно важным в эпоху ИИ

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

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

В случае Hugging Face из 17 600 восстановленных действий значительная часть оказалась неудачной. Агент последовательно пробовал различные пути, возвращался к предыдущим зацепкам, переключался между каналами и проверял новые гипотезы. Для него тысячи неудачных попыток это несущественная стоимость поиска.

Это означает, что неочевидность архитектуры перестаёт быть надёжным защитным механизмом.

Особенно опасны собственные ИИ-агенты компании.

Представим DevOps-агента, у которого есть kubeconfig с правами на весь Kubernetes-кластер. Он читает документацию, тикеты, логи и конфигурационные файлы. Если в одном из этих источников окажется инструкция, способная вызвать prompt injection, агент может выполнить нежелательное действие с полномочиями, которые ему были выданы заранее.

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

Собственный ИИ-агент — полноценная инфраструктурная сущность. К нему должны применяться те же требования SRP, Least Privilege и изоляции, что и к любому другому workload.

Применение SRP на уровнях Kubernetes

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

Ниже рассмотрены десять инфраструктурных слоёв и отдельный, одиннадцатый слой — сам ИИ-агент.

1. Workload: обработка недоверенных данных отдельно от секретов

Правило: всё, что обрабатывает недоверенный ввод, должно работать отдельно от компонентов, содержащих секреты.

К недоверенному вводу относятся:

• пользовательские файлы;

• датасеты;

• конфигурации;

• шаблоны;

• промпты;

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

В инциденте Hugging Face именно рабочий под совмещал обработку недоверенных данных и доступ к чувствительной информации.

После выполнения кода агент смог прочитать переменные окружения и получить секреты.

Правильная архитектура предполагает разделение на независимые компоненты:

• изолированный парсер принимает и обрабатывает входные данные;

• результат передаётся через очередь сообщений;

• отдельный сервис с собственной identity выполняет дальнейшую обработку и обращение к базе данных.
  

Для усиления изоляции можно использовать следующие инструменты:

• gVisor — обеспечивает дополнительную изоляцию системных вызовов через собственный userspace kernel.

• Kata Containers — запускает контейнерные workload в лёгких виртуальных машинах с отдельным ядром.

• Distroless-образы — сокращают количество лишних бинарных файлов и утилит внутри контейнера.

• Trivy и Grype — позволяют сканировать образы на наличие уязвимостей.
  

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

2. Pod Security: под не должен управлять нодой

Правило: обычный workload не должен иметь возможности управлять хостовой операционной системой.

В Hugging Face агент создал privileged-под с примонтированной файловой системой хоста и получил root-доступ на ноде.

Чтобы исключить подобный сценарий, необходимо использовать профиль restricted из Kubernetes Pod Security Standards.

Базовый механизм — встроенный Pod Security Admission (PSA).

Для более гибкого управления политиками подходят:

• Kyverno;

• OPA Gatekeeper;

• ValidatingAdmissionPolicy на основе CEL.
  

Эти инструменты позволяют не только запрещать опасные конфигурации, но и описывать точечные исключения. Например, можно разрешить необходимые настройки конкретному системному DaemonSet CSI-драйвера в namespace kube-system, не открывая аналогичные возможности обычным приложениям.

Ключевые ограничения:

• запрет privileged;

• запрет или строгое ограничение hostPath;

• использование readOnlyRootFilesystem;

• сброс Linux capabilities;

• запрет ненужного повышения привилегий;

• контроль запуска контейнеров от root.
  

3. ServiceAccount: одна identity на один workload

Правило: один ServiceAccount должен обслуживать один workload, а токен монтируется только тогда, когда приложению действительно нужен доступ к Kubernetes API.

По умолчанию Kubernetes может автоматически монтировать токен ServiceAccount в под. Это удобно для приложений, взаимодействующих с API, но создаёт ненужный риск для компонентов, которым такие полномочия не требуются.

В инциденте Hugging Face агент просто прочитал токен из файловой системы пода и использовал его для дальнейших действий.

Базовая мера защиты:

automountServiceAccountToken: false

Эту настройку целесообразно применять по умолчанию и обеспечивать её соблюдение с помощью mutate-политик Kyverno.

Если доступ к Kubernetes API действительно необходим, предпочтительнее использовать короткоживущие bound ServiceAccount Tokens с явно заданным audience.

Дополнительно полезен инструмент rbac-police, который помогает выявлять ServiceAccount, через которые возможно повышение привилегий вплоть до уровня ноды или кластера.

4. RBAC: роль — одна функция в одном namespace

Правило: роль должна предоставлять полномочия для одной функции в пределах конкретного namespace.

Самый опасный пример из инцидента Hugging Face — использование учётной записи брокера, входившей в группу system:masters.

Эта группа имеет особый статус: она предоставляет суперпользовательские полномочия и обходит стандартную модель RBAC. Обычное удаление RoleBinding не является способом отзыва членства в этой группе.

Поэтому system:masters следует использовать исключительно в контролируемых процедурах аварийного доступа (break-glass).

Отдельного внимания требуют опасные RBAC-глаголы:

• escalate;

• bind;

• impersonate;

• create pods на уровне кластера.
  

Последний особенно важен: возможность создавать поды в сочетании с отсутствием admission-контролей позволила агенту запустить привилегированный под.

Для аудита и анализа RBAC можно использовать:

• Kubescape;

• KubiScan;

• rbac-tool;

• rakkess;

• audit2rbac.
  

Первые инструменты помогают понять, какие полномочия имеются у пользователей и сервисных учётных записей. audit2rbac позволяет построить более узкую роль на основе реальных вызовов Kubernetes API из журналов аудита.

5. Облачная идентичность: под получает только собственную роль

Правило: каждый под должен получать только ту облачную identity, которая необходима его собственной функции.

Один из распространённых источников эскалации — доступ контейнеров к Instance Metadata Service (IMDS).

В документации AWS для EKS Pod Identity отдельно описано, что при отсутствии ограничений на доступ к IMDS контейнеры могут получать роль ноды, а потенциально и роли других подов на той же ноде.

Именно такой путь использовал агент в инциденте Hugging Face. После расследования компания заблокировала доступ подов к IMDS.

Для защиты следует использовать несколько уровней:

• IMDSv2;

• hop limit, равный единице, для соответствующих конфигураций EC2;

• NetworkPolicy, блокирующую доступ к адресу сервиса метаданных;

• workload identity, предоставляемую облачной платформой.
  

Основные варианты:

• AWS EKS Pod Identity;

• AWS IRSA (IAM Roles for Service Accounts);

• GKE Workload Identity;

• Azure Workload Identity.

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

6. Секреты: один секрет — один потребитель и одна цель

Правило: один Secret должен содержать данные для одной функции и одного потребителя.

Secret на 136 ключей из инцидента Hugging Face — типичный пример нарушения SRP.

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

При его компрометации атакующий получал сразу несколько независимых возможностей.

Правильный подход:

• Разделить крупные Secret на отдельные объекты.

• Ограничить чтение через RBAC.

• Использовать resourceNames, когда необходимо ограничить доступ к конкретным именам ресурсов.

• По возможности отказаться от статических учётных данных в пользу динамических короткоживущих credentials.

Для управления секретами подходят:

• HashiCorp Vault;

• OpenBao;

• External Secrets Operator;

• Secrets Store CSI Driver.
  

External Secrets Operator и Secrets Store CSI Driver позволяют организовать доставку секретов в workload в виде файлов, а не только через переменные окружения.

Это особенно важно в контексте Hugging Face: один из векторов атаки позволил прочитать /proc/self/environ.

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

7. Сеть: каждый под взаимодействует только с необходимыми сервисами

Правило: сетевые соединения должны соответствовать единственной функции workload.

В инциденте Hugging Face из рабочего пода были доступны как сервис метаданных облачной платформы, так и внутренний коннектор брокера доступа. Последний позволил получить каталог кластеров.

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

Базовый подход — default-deny NetworkPolicy в каждом namespace.

После этого необходимо явно разрешать только необходимые соединения:

• ingress от конкретных источников;

• egress к определённым сервисам;

• доступ к DNS;

• обращения к очередям сообщений;

• соединения с базами данных только для соответствующих workload.
  

Для реализации и наблюдения за сетевыми политиками подходят:

• Cilium — поддерживает L3–L7-политики, DNS-aware egress и наблюдаемость через Hubble.

• Calico — зрелая альтернатива для сетевой сегментации и политик.

• Istio и Linkerd — обеспечивают mTLS и политики авторизации между сервисами.

• SPIFFE/SPIRE — предоставляют инфраструктуру криптографической идентичности workload.
  

Особенно важно постепенно переходить от доверия на основе IP-адресов к авторизации по identity.

8. Мультикластер: одна учётная запись — один кластер

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

В Hugging Face один брокер и одна учётная запись обеспечивали доступ к нескольким кластерам.

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

Для доступа пользователей можно использовать:

• Teleport;

• Pinniped;

• отдельные OIDC-конфигурации для каждого кластера.

Для GitOps рекомендуется создавать отдельные identity Argo CD или Flux на каждый целевой кластер, а не использовать один универсальный токен с полномочиями на всю инфраструктуру.

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

9. Supply Chain: один CI-токен — одно действие в одном репозитори

Правило: токен CI/CD должен иметь возможность выполнить одну конкретную задачу в одном репозитории или целевом контуре.

В инциденте Hugging Face агент использовал доступ через VPN и GitHub-коннектор, чтобы получить токен GitHub App с правом записи.

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

Рекомендуемая архитектура должна разделять:

• сборку артефактов;

• проверку и подписание;

• публикацию;

• деплой в целевую среду.
  

Вместо долгоживущих статических ключей следует использовать короткоживущие OIDC-токены, ограниченные конкретной задачей.

Дополнительные инструменты:

• Sigstore cosign — подпись контейнерных образов;

• Kyverno verifyImages — проверка подписей на этапе admission;

• Syft — создание Software Bill of Materials (SBOM);

• SLSA — framework для оценки и повышения зрелости цепочки поставки программного обеспечения.
  

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

10. Runtime и наблюдаемость: детекция должна быть независимой

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

В Hugging Face система ИИ-корреляции правильно собрала сигналы, но не повысила критичность инцидента до необходимого уровня и не разбудила дежурного специалиста.

Это важный пример того, что наличие логов и телеметрии ещё не означает эффективную защиту.

Необходимо обеспечить:

• аудит Kubernetes API;

• сбор runtime-событий;

• независимое хранение журналов;

• корреляцию событий между слоями;

• приоритизацию подозрительных цепочек действий;

• своевременное оповещение дежурных;

• автоматические ответные действия для заранее определённых сценариев.
  

Для runtime-защиты можно использовать:

• Tetragon — инструмент на основе eBPF, который не только наблюдает за процессами, но и позволяет применять enforcement-политики, включая завершение процесса через SIGKILL.

• Falco — обнаружение подозрительной активности на уровне системы и контейнеров.

• Tracee — сбор и анализ runtime-событий.

• KubeArmor — применение политик безопасности на уровне процессов, файловой системы и сети.

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

Одиннадцатый слой: безопасность самого ИИ-агента

Десять рассмотренных слоёв отвечают на вопрос: что получит атакующий после компрометации конкретной инфраструктурной сущности?

Но есть ещё один уровень: что агент вообще способен сделать с помощью доступных ему инструментов?

Это отдельная задача, которую нельзя полностью решить настройками Kubernetes.

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

Например, если агент имеет прямой доступ к exec и PostgreSQL, он может самостоятельно перебирать SQL-команды, искать обходные пути и пытаться изменить состояние базы данных.

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

Что необходимо контролировать

• Identity агента. У каждого агента должна быть собственная идентичность, не совпадающая с учётными данными других агентов и сервисов.

• Каталог инструментов. Набор доступных функций должен быть узким. Один грант — одна функция. Универсальный exec не должен использоваться как универсальный способ взаимодействия с инфраструктурой.

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

• Аудит. Необходимо журналировать каждый вызов инструмента и каждый запрос к модели, чтобы впоследствии можно было восстановить последовательность действий.

• Обнаружение теневых агентов. Следует инвентаризировать не только официально развёрнутые системы, но и shadow-агентов, а также несанкционированные MCP-серверы.

Obot как пример AI Control Plane

В качестве одного из инструментов для реализации этого подхода можно выделить Obot — open-source Enterprise AI Control Plane с MCP-шлюзом.

Он позволяет:

• устанавливать SSO и OIDC перед подключениями к MCP;

• применять политики доступа на основе групп пользователей;

• инспектировать вызовы и блокировать несанкционированное поведение;

• вести полный аудит действий;

• экспортировать логи во внешнее хранилище.
  

Отдельное преимущество — возможность self-hosted-развёртывания. Это позволяет сохранять данные и контроль над инфраструктурой внутри собственного контура.

По смыслу такой подход соответствует рекомендациям OWASP Agentic Top 10 и принципам Google для безопасных агентных систем: у агента должен быть понятный владелец, ограниченные полномочия и наблюдаемые действия.

Практическая реализация: изолированный под-парсер

Рассмотрим, как принцип единственной ответственности выглядит на уровне Kubernetes-манифеста.

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

Это именно тот тип компонента, через который агент получил первоначальную точку входа в инциденте Hugging Face.

Такой под должен иметь следующие характеристики.

1) Отдельный runtime.

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

2) Отсутствие токена Kubernetes.

В манифесте задаётся:

automountServiceAccountToken: false

Парсеру не нужен доступ к Kubernetes API, следовательно, у него не должно быть токена, который можно украсть.

3) Отсутствие секретов.

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

4) Ограничение возможностей контейнера.

Необходимо сбросить ненужные Linux capabilities, использовать readOnlyRootFilesystem и запускать процесс с минимальными полномочиями.

5) Изолированная сетевая среда.

Для namespace задаётся default-deny NetworkPolicy. Единственное разрешённое направление исходящего трафика — очередь результатов.

6) Ограничения Kubernetes.

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

В итоге даже при выполнении произвольного кода в парсере атакующий оказывается в изолированной среде с одним разрешённым направлением взаимодействия.

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

Admission и Runtime: Kyverno и Tetragon решают разные задачи

Для реализации SRP особенно полезно разделять защитные механизмы по этапам жизненного цикла workload.

Два показательных инструмента — Kyverno и Tetragon.

Kyverno: запрет до запуска

Kyverno работает на этапе admission.

Его задача — не допустить создания пода, конфигурация которого нарушает установленные требования.

Например, политика может запретить:

• privileged;

• опасные варианты hostPath;

• запуск с избыточными capabilities;

• использование неподходящих security context.
  

Правило podSecurity позволяет применять требования профиля restricted из Kubernetes Pod Security Standards.

По сравнению со встроенным Pod Security Admission Kyverno удобнее использовать для описания более точечных исключений, например для конкретного системного DaemonSet CSI-драйвера в kube-system.

Именно отсутствие такого контроля позволило агенту Hugging Face создать привилегированный под с примонтированной файловой системой хоста.

Tetragon: остановка уже запущенного процесса

Tetragon решает другую задачу — runtime enforcement.

Он работает на основе eBPF и позволяет отслеживать действия процессов на уровне ядра.

Например, можно создать политику для namespace untrusted-processing, которая обнаруживает попытку процесса открыть файлы с токеном ServiceAccount под /var/run/secrets и завершает такой процесс.

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

При внедрении подобных политик важно учитывать несколько особенностей:

• фактические пути к секретам необходимо проверить на конкретных нодах;

• в некоторых конфигурациях секреты могут быть доступны через /run/secrets;

• сначала новую политику следует запускать в режиме аудита;

• Kyverno необходимо предварительно использовать в режиме Audit, а не Enforce;

• Tetragon следует сначала настроить без немедленного действия SIGKILL.
  

Только после проверки реальных событий и исключений стоит включать блокирующий режим.

Таким образом, Kyverno предотвращает появление небезопасной конфигурации, а Tetragon реагирует на опасное поведение уже работающего процесса. Это два независимых уровня защиты.

Что говорят ведущие компании и отраслевые фреймворки

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

Hugging Face

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

• отдельная учётная запись на каждый кластер;

• блокировка доступа подов к облачным метаданным;

• переход на workload identity;

• сокращение области действия учётных данных;

• разделение полномочий между компонентами.
  

Это фактически практическое внедрение SRP на уровне инфраструктуры.

Ironclad

Ironclad предлагает полезный способ проверки архитектуры безопасности.

Необходимо разделить все существующие контроли на две группы:

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

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

Первая группа показывает, насколько инфраструктура зависит от сохранности секретов. Вторая — наличие независимых архитектурных ограничений.

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

Anthropic

Кейс GTG-1002 показывает, что атакующие агенты могут самостоятельно выстраивать длинные цепочки действий и использовать множество инструментов.

Обнаружение аномальных последовательностей вызовов инструментов демонстрирует важность отдельной функции наблюдаемости за поведением агента.

Google Threat Intelligence

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

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

Google BeyondProd

BeyondProd — модель безопасности, используемая Google для защиты производственной инфраструктуры.

Её основные идеи:

• отсутствие взаимного доверия между сервисами;

• исполнение только известного кода;

• изоляция workload;

• собственная identity для каждого сервиса;

• авторизация каждого обращения.
  

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

Microsoft Threat Matrix for Kubernetes

Microsoft Threat Matrix for Kubernetes представляет собой карту техник атак на Kubernetes, аналогичную MITRE ATT&CK. 

В третьей версии также рассматриваются меры защиты.

Особенно показательно, что техники, применённые агентами в 2026 году, уже присутствовали в этой матрице:

• обращение к сервисам метаданных;

• получение cluster-admin;

• монтирование каталогов хоста;

• эксплуатация избыточных Kubernetes-полномочий.

То есть новые атаки не потребовали принципиально новых техник. Изменилась стоимость их поиска и применения.

AWS EKS Pod Identity

Документация AWS отдельно предупреждает о рисках доступа контейнеров к IMDS.

Если такой доступ не ограничен, под может получить роль ноды и потенциально доступ к ролям других workload на той же ноде.

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

NSA и CISA

Руководства NSA и CISA по харденингу Kubernetes рекомендуют использовать базовые механизмы защиты:

• least privilege;

• сетевую сегментацию;

• аудит;

• сканирование и проверку конфигураций на admission;

• ограничение полномочий контейнеров.
  

Эти рекомендации остаются актуальными и в условиях распространения агентного ИИ.

OWASP Top 10 для агентных приложений

OWASP Agentic Top 10 рассматривает риски, связанные с автономными агентами и их инструментами.

Особое внимание уделяется:

• ограничению полномочий;

• контролю инструментов;

• идентичности агента;

• проверке действий;

• наблюдаемости.
  

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

SRP связывает оба уровня в единую архитектуру.

Семь принципов безопасности Kubernetes в эпоху ИИ

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

1) Одна сущность — одна ответственность.

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

2) Доверие основано на проверяемой идентичности, а не на владении строкой.

Предпочтительны workload identity, bound-токены и SPIFFE. Если секреты необходимы, они должны быть короткоживущими и предназначенными для одной цели.

3) В каждой критичной точке должен быть контроль, который не проходит украденная учётная запись.

Это может быть admission-политика, сетевое ограничение, политика исполнения CI или облачная IAM-политика, запрещающая определённые операции.

4) Граница доверия должна совпадать с границей ответственности.

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

5) Радиус поражения ограничивается топологией.

Одна учётная запись — один кластер. Namespace разделяются по командам и функциям. Общие брокеры с суперпользовательскими полномочиями, универсальные VPN-теги и общие административные токены должны быть исключением, а не нормой.

6) Защита должна работать на машинной скорости.

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

7) Собственные ИИ-агенты подчиняются тем же правилам.

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

Дорожная карта внедрения на 90 дней

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

Первые 30 дней: устранение избыточных полномочий

Главная задача — найти и разделить наиболее опасные сущности.

Необходимо:

• Провести аудит всех пользователей и сервисных учётных записей, входящих в system:masters.

• Найти все привязки к cluster-admin и оставить административный доступ только для контролируемых процедур break-glass.

• Проверить роли с разрешениями create pods, bind, escalate, impersonate и чтением секретов на уровне кластера.

• Перенести полномочия на уровень namespace там, где это возможно.

• Разделить учётные записи брокеров, GitOps и CI/CD: одна учётная запись — один целевой кластер.

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

• Провести инвентаризацию собственных ИИ-агентов и выяснить, у кого из них есть kubeconfig и какие права он предоставляет.

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

Дни 30–60: закрытие путей эскалации

Следующий этап — исключить типовые способы повышения привилегий.

Необходимо:

• включить Pod Security Admission в режиме restricted;

• внедрить Kyverno для централизованного управления политиками и исключениями;

• запретить необоснованное использование privileged и hostPath;

• отключить автоматическое монтирование ServiceAccount Token там, где оно не требуется;

• ограничить доступ подов к сервисам облачных метаданных;

• перейти на EKS Pod Identity, IRSA, GKE Workload Identity или Azure Workload Identity;

• внедрить default-deny NetworkPolicy во всех namespace;

• проверить опасные RBAC-глаголы и возможность создания привилегированных подов.
  

Цель — сделать так, чтобы компрометация обычного workload не превращалась в доступ к ноде, облачной роли или Kubernetes API.

Дни 60–90: изоляция и безопасность цепочки поставки

На третьем этапе необходимо устранить оставшиеся архитектурные пересечения.

Основные задачи:

• вынести обработку недоверенного ввода в изолированные workload;

• использовать gVisor или Kata Containers там, где уровень риска этого требует;

• убрать секреты из переменных окружения и организовать безопасную доставку;

• разделить сборку, подпись и деплой;

• перейти на короткоживущие OIDC-токены;

• внедрить подпись образов через Sigstore cosign;

• проверять подписи на admission;

• настроить SBOM и процессы контроля supply chain;

• ограничить инструменты и полномочия собственных ИИ-агентов.

Постоянные процессы

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

Рекомендуется:

• централизовать аудит Kubernetes API;

• собирать runtime-события через Tetragon, Falco или аналогичные решения;

• настроить приоритетные правила для подозрительных цепочек действий;

• обеспечить реальное оповещение дежурных;

• автоматизировать безопасные ответные действия;

• регулярно проводить red team-тестирование с использованием собственных ИИ-агентов.
  

Если собственный агент способен обнаружить и пройти цепочку эскалации, аналогичный путь может найти и внешний атакующий.

Пять вопросов, которые стоит задать своей команде

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

Полезнее начать с пяти вопросов.

1) Какие из наших контролей проходит украденный токен?

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

2) Какая роль в нашей инфраструктуре самая широкая?

Кто и когда в последний раз обосновывал её полномочия? Какие из них действительно используются?

3) Сколько кластеров и сред доступно через одну учётную запись?

Особое внимание следует уделить брокерам, GitOps-агентам и CI/CD.

4) Какие механизмы детекции действительно будят человека?

Сколько времени проходит между обнаружением подозрительной активности и реакцией дежурного? Случай Hugging Face показал, что наличие телеметрии само по себе не гарантирует своевременного реагирования.

5) У какого собственного ИИ-агента больше всего прав в production?

Кто является владельцем этого агента? Кто согласовал его полномочия? Какие инструменты ему доступны?

Ответы на эти вопросы уже формируют готовый бэклог для первого этапа дорожной карты.

Когда собственный ИИ-агент переходит в hack mode: пример с OpenClaw и PostgreSQL

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

В описанном инциденте использовалась система оркестрации ИИ-агентов OpenClaw, развёрнутая в Docker.

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

В комментариях к своим действиям агент фактически сформулировал следующий план: у пользователя admin нет доступа к схемам, но есть право CREATEROLE, поэтому можно попробовать выполнить GRANT и получить дополнительные полномочия.

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

Корневая причина

Первоначальный вход в систему стал возможен из-за дефолтного пароля admin/admin и открытой сетевой доступности.

Однако эти факторы объясняют только получение первоначального доступа. Саму эскалацию обеспечила архитектура роли admin.

Она совмещала две независимые ответственности:

• Быть рабочей учётной записью для входа в систему.

• Администрировать другие роли через привилегию CREATEROLE.

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

СУБД заблокировала часть этих действий.

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

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

Какие изменения устранили проблему

В качестве исправлений были выполнены следующие действия:

• закрыта сетевая доступность;

• отключён local trust;

• отозваны CREATEROLE и SUPERUSER у всех ролей, кроме postgres;

• устранена возможность использования рабочей учётной записи для управления другими ролями.

Важно понимать, что долговременный эффект обеспечивает именно отзыв CREATEROLE и SUPERUSER, а не смена пароля admin.

Смена пароля останавливает конкретный сценарий, но не исправляет архитектуру. Если у роли по-прежнему остаётся возможность создавать и изменять другие роли, новый дефолтный пароль или случайно оставленный в конфигурации секрет снова откроет путь для эскалации.

Следующий правильный шаг — создать отдельную LOGIN-роль для агента с доступом только к необходимым схемам и операциям.

Это тот же принцип SRP, применённый к PostgreSQL: рабочая учётная запись должна выполнять свою функцию, но не должна иметь полномочий администратора идентичностей.

Выводы

ИИ-агенты не изобрели новых способов компрометации Kubernetes. Все техники, использованные в рассмотренных инцидентах 2026 года, уже были известны и описаны в существующих моделях угроз, в том числе в Microsoft Threat Matrix for Kubernetes. Изменилось другое: агенты сделали перебор атакующих сценариев значительно дешевле и быстрее. Теперь любая инфраструктурная сущность с избыточными полномочиями может стать точкой входа для дальнейшей атаки.

Инцидент Hugging Face наглядно демонстрирует, как последовательные нарушения принципа единственной ответственности привели к компрометации нескольких кластеров: парсер обрабатывал недоверенные данные и имел доступ к секретам, токен ServiceAccount автоматически монтировался в поды, CSI-роль позволяла создавать поды на уровне кластера, один Secret содержал 136 ключей, а единая учётная запись брокера обеспечивала доступ ко всем кластерам через группу system:masters. Устранение любого из этих звеньев могло прервать цепочку атаки.

Отдельно стоит отметить контроли, которые выдержали атаку. Они не зависели исключительно от наличия или отсутствия секретов: ограничения сетевого доступа, IAM-политики, admission-контроли и политика исполнения CI продолжали работать даже после компрометации учётных данных.

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

Эти же требования необходимо применять не только к Kubernetes, но и к облачной инфраструктуре, CI/CD, базам данных, системам управления секретами и собственным ИИ-агентам. Агент с избыточными полномочиями сам становится потенциальной точкой эскалации для другого агента.

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