Защитите рабочую нагрузку Kubernetes до её выпуска

CVE-2026-19274 была зарегистрирована с оценкой CVSS 9.6 после того, как разрешение на запись на уровне namespace могло привести к влиянию на RBAC всего кластера из-за схемы именования оператора. Security Arsenal сообщает об отсутствии подтверждённой эксплуатации по состоянию на 4 сентября 2026 года. Сбой произошёл из-за полномочий, связанных с рабочей нагрузкой. Проблема была не в коде приложения.

ZeroPath сообщает, что CVE-2026-10840 была связана с оператором OpenShift Pipelines, который предоставлял каждому аутентифицированному пользователю кластера доступ на запись к пользовательским ресурсам Kueue и cert-manager. В отчёте говорится, что такой доступ мог позволить нарушить работу рабочих нагрузок и перезаписывать сертификаты.

Но ни для одного из этих инцидентов не требовался уязвимый образ приложения, чтобы создать проблемы. Опасным объектом были полномочия: кто мог записывать какой ресурс и как оператор преобразовывал объект, ограниченный namespace, в разрешения для всего кластера.

Но люди продолжают воспринимать безопасность Kubernetes как сканирование образов с несколькими проверками YAML в придачу. Такая трактовка упускает место, где происходят самые серьёзные сбои: идентификацию, admission и операторов, которым доверено связать их воедино. Эти основы безопасности Kubernetes начинаются с границ вокруг образа.

Поэтому мы проследим за одной рабочей нагрузкой на всём пути её выпуска. Мы напишем манифест, запросим доступ, проведём образы и Secrets через CI, пройдём admission, ограничим сетевую доступность, а затем обнаружим изменения и злоупотребления. Вам не нужно контролировать каждое звено. Но нужно знать, кто это делает.

В этой статье

• Ваш Deployment проходит пять операционных этапов
• Вашей рабочей нагрузке редко нужен RBAC для всего кластера
• Restricted PSA должен быть проверкой, которую проходит ваш pod
• У payments-api пароль базы данных имеет путь хранения
• Закройте сетевые пути, которые вы не собирались открывать
• Заставьте CI остановить неправильный артефакт до развёртывания
• Используйте CIS Benchmark для распределения ответственности
• Audit logs показывают, кто изменил границу
• Задайте эти шесть вопросов до выпуска

Ваш Deployment проходит пять операционных этапов

Рассмотрим вымышленный Deployment payments-api в namespace payments. Он использует один ServiceAccount, читает учётные данные базы данных из Secret, подключается к внутренней базе данных и запускает образ, собранный CI.

Его путь состоит из пяти операционных этапов. Идентификация и проверка манифеста пересекают первую границу:

1. Запись и запрос доступа: ваш код и идентификатор развёртывания отправляют ресурсы в Kubernetes; RBAC определяет, что они могут изменять.
2. Сборка и хранение артефакта: CI собирает, сканирует, подписывает и отправляет образ в registry.
3. Admission pod: Pod Security Admission и дополнительные политики решают, может ли pod быть запущен.
4. Подключение рабочей нагрузки: network policy ограничивает доступные сервисы, а конфигурация Secret контролирует доступ к учётным данным.
5. Обнаружение изменений: audit logs и сигналы среды выполнения показывают, кто изменил границу и что произошло после этого.

Вы можете контролировать образ, Deployment, ServiceAccount, labels namespace и разрешения CI. Команда платформы может контролировать API server, etcd и kubelet. Она также может контролировать конфигурацию admission, сетевую реализацию и pipeline аудита. По вопросам идентификации начните с руководства Blackhawk по управлению идентификацией и доступом.

Управляемые сервисы обычно берут на себя значительную часть control plane, но точная граница и доступные доказательства зависят от провайдера. Спросите, какие части управляются. Узнайте, что вы можете настроить и какие подтверждения можете получить. Управляемый control plane не делает автоматически безопасными RBAC приложения, политику pod, происхождение образа или доступ к Secret.

Для payments-api CI устанавливает факты об артефакте. RBAC контролирует, кто может отправлять или изменять ресурсы. Admission проверяет опасные настройки pod, а network policy ограничивает доступные рабочие нагрузки. Разрешения Secret защищают учётные данные базы данных. Команда платформы должна предоставлять подтверждения конфигурации для контролируемых ею границ.

Вашей рабочей нагрузке редко нужен RBAC для всего кластера

Начните с ServiceAccount. Затем проверьте каждое разрешение, связанное с ним.

По умолчанию используйте Role и RoleBinding, ограниченные namespace. ClusterRole или ClusterRoleBinding должны появляться в архитектуре только тогда, когда рабочей нагрузке действительно нужен доступ ко всему кластеру. Привязка к cluster-admin — не быстрый путь; это признание того, что никто не спроектировал разрешение, которое рабочей нагрузке действительно необходимо.

Для payments-api спросите:

• Какой ServiceAccount использует pod?
• К каким ресурсам может обращаться эта идентичность?
• Какие verbs разрешены?
• Нужны ли ей list и watch или только get?
• Нужно ли CI создавать ресурсы во всём кластере или только в payments?
• Какие bindings устанавливают операторы и Helm charts?

Если приложение только использует подключённый Secret или ConfigMap, ему может вообще не понадобиться разрешение Kubernetes API. Это предполагает, что kubelet или конфигурация развёртывания внедряет значение; процесс, который обращается к Kubernetes API для его получения, нуждается в явном разрешении.

Например, payments-api не должен иметь доступа к API, если его учётные данные базы данных поступают через подключённый Secret, а процесс никогда не запрашивает Kubernetes. Его идентификатор развёртывания всё ещё может нуждаться в разрешении обновлять Deployment и Service в payments, но это отдельная идентичность с отдельной задачей.

Принцип наименьших привилегий создаёт сложности при отладке. Вопрос «Почему CI не может выполнить deploy?» часто является первым полезным сбоем, потому что он выявляет разрешение, которое кто-то не спроектировал.

В исследовании IJERT по неправильной настройке RBAC и ServiceAccount описаны такие риски, как эскалация привилегий, несанкционированный доступ к ресурсам, раскрытие Secret, злоупотребление API и возможная компрометация кластера.

Два случая с операторами в 2026 году делают установленный RBAC частью вашей проверки. Security Arsenal сообщает, что в случае Instana объекты с областью действия кластера, идентифицируемые по неполному имени пользовательского ресурса, могли конфликтовать, если в разных namespace существовали ресурсы с одинаковыми именами. Согласно отчёту, доступа на запись на уровне namespace было достаточно для достижения влияния на весь кластер.

Ваше изменение — это узко ограниченный ServiceAccount и binding в namespace. Подтверждением со стороны команды платформы должны быть проверка bindings для всего кластера, RBAC, генерируемого операторами, и идентичностей, которым разрешено их изменять.

Restricted PSA должен быть проверкой, которую проходит ваш pod

PodSecurityPolicy была удалена в Kubernetes 1.25. Pod Security Standards и встроенный контроллер Pod Security Admission заменили её, а PSA является стабильной начиная с Kubernetes v1.25. Профили: Privileged, Baseline и Restricted.

Privileged практически не накладывает ограничений. Baseline блокирует известные повышения привилегий, поддерживая распространённые рабочие нагрузки. Restricted — полезная цель для приложений, которые могут ему соответствовать.

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

Для payments-api pod, совместимый с Restricted, должен установить allowPrivilegeEscalation: false, использовать разрешённый профиль seccomp, например RuntimeDefault, не использовать hostPath, не использовать привилегированные containers и init containers, а также удалить capabilities, ограниченные профилем. Ему следует избегать привилегированных портов. Точные требования зависят от версии Kubernetes и версии профиля, настроенной командой платформы.

Элемент проверки Restricted	Что проверять
Повышение привилегий	Установить allowPrivilegeEscalation: false.
Seccomp	Объявить разрешённый профиль, обычно RuntimeDefault.
Доступ к файловой системе хоста	Удалить volumes hostPath.
Привилегированное выполнение	Оставить containers и init containers непривилегированными.
Capabilities	Удалить capabilities, которые приложению не нужны.
Порты	Избегать портов, рассматриваемых активным профилем как привилегированные.

Namespaces выбирают режим PSA с помощью labels:

pod-security.kubernetes.io/audit: restricted
pod-security.kubernetes.io/warn: restricted
pod-security.kubernetes.io/enforce: restricted

audit записывает нарушения, warn сообщает о них пользователю, отправляющему запрос, а enforce отклоняет pod. В документации Kubernetes по Pod Security Admission говорится, что namespaces без конфигурации следует считать незащищёнными, и рекомендуется настроить все namespaces.

Практическое внедрение начинается с audit и warn, а затем переходит к enforce после исправления рабочих нагрузок. Проверьте payments-api с учётом версии Kubernetes в кластере и версии профиля Restricted, настроенной командой платформы. Используйте ответ admission или отчёт о проверке платформы, чтобы устранить точную причину сбоя, а не угадывать по общему списку.

PSA намеренно является грубым механизмом. Kyverno или OPA Gatekeeper могут добавить правила для требований конкретной организации, но каждый из них добавляет ещё одну систему политик admission, набор тестов, владельца и режим отказа. Используйте такую систему, только если кто-то будет ею управлять.

Ваше изменение — это pod, который проходит Restricted, либо документированное исключение. Подтверждением со стороны команды платформы являются labels namespace, режим enforcement и поведение проверки в целевом кластере.

У payments-api пароль базы данных имеет путь хранения

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

Нативный Kubernetes Secret хранит обычные данные в виде текста, закодированного в base64. Base64 только кодирует данные; он не шифрует их. Шифрование at rest зависит от конфигурации etcd кластера.

Ссылайтесь на Secret из рабочей нагрузки, а не встраивайте его значение в repository или обычный manifest. Для payments-api Secret должен содержать только нужные ему учётные данные базы данных, и только предназначенный ServiceAccount или путь развёртывания должны иметь возможность его читать.

Запросите у команды платформы конкретные подтверждения:

• Включено ли шифрование at rest для etcd?
• Как управляются и ротируются ключи шифрования?
• Какие идентичности могут читать Secrets в payments?
• Как записываются чтения Secret без помещения значений Secret в logs?
• Какое внешнее хранилище Secret, если оно используется, отвечает за ротацию и восстановление?

Для самостоятельно управляемых кластеров механизм API server --encryption-provider-config относится к конфигурации control plane. Разработчики не должны самостоятельно добавлять его в managed cluster. Запросите у оператора соответствующий снимок конфигурации и информацию о владельце.

Шифрование at rest защищает сохранённые данные. Оно не мешает ServiceAccount с избыточными привилегиями запрашивать данные в открытом виде.

Sealed Secrets, External Secrets Operator и Vault могут подойти организациям, которые уже используют внешнее хранилище Secret. Правильный выбор зависит от ответственности, ротации, восстановления и способа передачи учётных данных приложениям — ничего из этого не видно в манифесте Deployment.

Закройте сетевые пути, которые вы не собирались открывать

RBAC отвечает на вопрос, что может делать идентичность через Kubernetes API. Network policy отвечает на вопрос, к каким рабочим нагрузкам может обращаться pod.

Стремитесь к состоянию default-deny, а затем добавляйте явные ingress и egress для необходимого трафика. Для payments-api это означает разрешить его вызывающим приложениям, DNS, внутренней базе данных, health checks и telemetry. Это не означает разрешить неограниченный трафик внутри namespace.

Практический rollout — сначала применить policy в non-production namespace, а затем проверить каждую зависимость: успешный трафик, отклонённый трафик, разрешение DNS, telemetry и поведение при сбоях. Точное поведение зависит от сетевой реализации кластера.

Сетевым рекомендациям стоит уделить самое пристальное внимание: default-deny — обоснованная цель, но один манифест не докажет, что ваш CNI, путь DNS и стек observability действительно её обеспечивают. Проверьте эти утверждения в своём кластере.

Команда платформы должна определить поддерживаемые возможности network policy и предоставить подтверждение enforcement. Вы должны документировать необходимые соединения и проверять их. Network policy ограничивает доступность; RBAC ограничивает действия через API. Ни один из них не исправляет привилегированный контейнер или недоверенный образ.

Заставьте CI остановить неправильный артефакт до развёртывания

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

Используйте такую последовательность:

• Выберите поддерживаемый base image. Зафиксируйте его источник и ответственного за обновление.
• Сканируйте зависимости и финальный образ. Используйте одобренный scanner и exit rule организации для CI.
• Фиксируйте ссылки на образы там, где это разрешено политикой. Это не позволит развёртыванию незаметно выбрать более поздний изменяемый tag.
• Подписывайте и проверяйте артефакты там, где это поддерживается. Workflow на основе Sigstore может установить, кто создал образ и изменялся ли он. Платформа должна проверять подпись в значимой точке.
• Ограничьте production pulls. Используйте одобренные registries и записывайте результаты неудачного admission или проверки.

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

Ваша команда отвечает за Dockerfile, зависимости, gate CI и ссылку на образ. Узнайте у команды платформы, какие registries разрешены, проверяются ли подписи во время admission и где отображается неудачная проверка. Подпись, которую никто не проверяет, — это декоративная бюрократия.

Руководство Blackhawk по безопасности software supply chain охватывает более широкую границу сборки и зависимостей.

Используйте CIS Benchmark для распределения ответственности

Center for Internet Security поддерживает Kubernetes Benchmark как зависящий от версии checklist по hardening. Juliet описывает его как набор примерно из 120 контролей, количество которых зависит от версии Kubernetes. Они охватывают конфигурацию API server, RBAC и network policy. Они также охватывают безопасность pod, шифрование etcd, PKI и настройки kubelet.

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

Область	Что изменяете или проверяете вы	Что доказывает команда платформы
RBAC	Идентичность рабочей нагрузки и bindings имеют узкую область действия.	Bindings для всего кластера и разрешения операторов проверены.
Безопасность pod	Manifest проходит Restricted или имеет документированное исключение.	Labels namespace и режимы enforcement настроены.
Secrets	Ссылки на Secret и область доступа ограничены.	Шифрование etcd и управление ключами работают.
Сеть	Необходимые ingress и egress задокументированы и проверены.	CNI применяет заявленную policy.
Control plane	Предположения Deployment и CI зафиксированы.	Настройки API server, kubelet, PKI, etcd и audit проверены.

Полезная трактовка проста: если контроль изменяет ваш Deployment, ServiceAccount, labels namespace, ссылку на образ или объявленные сетевые зависимости, вы отвечаете за исправление. Если он изменяет flags API server, etcd, kubelet, PKI или хранение audit, запросите подтверждение у команды платформы.

Запрашивайте разные доказательства для каждой границы: проверку binding для RBAC, labels namespace для PSA, снимок конфигурации шифрования для etcd, результат admission для подписей и отчёт benchmark, соответствующий версии кластера.

Audit logs показывают, кто изменил границу

Runtime monitoring начинается после первых контролей. Detection не компенсирует cluster-admin, неограниченный доступ к Secret или неподписанный образ.

В анализе CVE-2026-19274 от Security Arsenal рекомендуется фиксировать операции create, update, patch и delete, связанные с clusterrolebindings и clusterroles. Также фиксируйте соответствующие custom resources, а затем отправляйте эти записи в SIEM.

Команда платформы отвечает за audit policy, срок хранения, доставку в SIEM и runtime tooling. Запросите query или alert, который выявляет новые bindings для всего кластера, изменения разрешений операторов и соответствующий доступ к Secret без записи содержимого Secret в logs. Также спросите, как расследуется инцидент, связанный с вашей рабочей нагрузкой.

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

Задайте эти шесть вопросов до выпуска

1. Использует ли pod ServiceAccount с узкой областью действия?
2. Прошёл ли namespace проверку Restricted PSA и задокументированы ли исключения?
3. Зашифрованы ли Secrets at rest и доступны ли они только идентичностям, которым они нужны?
4. Является ли сеть default-deny с явно разрешёнными необходимыми соединениями?
5. Был ли образ просканирован и может ли организация установить его provenance?
6. Какие controls API server и kubelet относятся к ответственности команды платформы? А что насчёт etcd, audit logs и RBAC для всего кластера? Когда каждый из них в последний раз подтверждался?

Выпускайте manifest с приложенными ответами на шесть вопросов; у каждого неподтверждённого контроля платформы должны быть ответственный и дата.