Почему даже SVID с коротким сроком действия в SPIFFE/SPIRE зависят от целостности узла, что показал лабораторный тест с подменой cgroup и какие меры Kubernetes могут ограничить последствия.
SPIFFE предоставляет сервисам криптографические удостоверения идентичности с коротким сроком действия — SVID. Рабочие нагрузки могут использовать их для установления соединений TLS, а также для подписания и проверки JWT. Эта модель описана в официальном обзоре SPIFFE.
Где принимается решение об идентификации
Перед выдачей SVID SPIRE выполняет аттестацию узлов и рабочих нагрузок. При аттестации рабочей нагрузки агент SPIRE определяет свойства процесса по данным из локальных источников, например ядра операционной системы или kubelet на том же узле. Затем он сопоставляет эти свойства с условиями селекторов в регистрационной записи. При успешном совпадении определяется, какой SPIFFE ID получит процесс. Этот механизм описан в документации по основным понятиям SPIRE.
Что показало лабораторное исследование и каковы его границы
В этой модели криптографическая действительность SVID и его выдача именно тому процессу, которому он предназначался, — два отдельных вопроса. Лабораторное исследование Unit 42 показало, что злоумышленник, уже имеющий root-доступ к узлу Kubernetes, мог подменить информацию о cgroup в Linux, обмануть агент SPIRE и получить действительный SVID другой рабочей нагрузки на том же узле. Техническая последовательность действий описана в исследовании Unit 42.
Unit 42 прямо указывает, что не наблюдала применения этой техники в реальных атаках. Поэтому результат исследования не служит свидетельством активной эксплуатации: он описывает риск, возникающий после того, как злоумышленник получил root-доступ и тем самым нарушил доверие к узлу.
Модель защиты от рисков на уровне узла
При планировании защиты компрометацию узла следует рассматривать как компрометацию всех цифровых идентичностей рабочих нагрузок, связанных с этим узлом. Рекомендации Unit 42 включают ограничение использования привилегированных контейнеров и прямого доступа к хосту, а также снижение зависимости от слабых селекторов или селекторов, данные для которых легко подделать. Эти риски относятся к скомпрометированному узлу, а не автоматически ко всему кластеру.
Ограничивайте привилегии подов и узлов
Профиль Restricted в стандартах Kubernetes Pod Security Standards предусматривает запрет привилегированных подов, блокирование повышения привилегий и запуск контейнеров от имени пользователей без прав root. В официальном контрольном списке по безопасности также отмечается, что seccomp может сократить набор системных вызовов ядра Linux, доступных внутри контейнеров. Подробности приведены в стандартах безопасности подов (Pod Security Standards) и контрольном списке по безопасности Kubernetes.
Рассматривайте селекторы как часть границы доверия
Селекторы — не просто параметры сопоставления: они определяют, какие локальные свойства учитываются при принятии решения об аттестации. Поэтому при проверке следует выяснить, какие данные операционной системы или kubelet используются для каждого условия и насколько легко их подделать при наличии root-доступа. Цель — опираться на селекторы, которые позволяют точно различать рабочие нагрузки, а не на широкие или слабые условия.
Разделяйте нагрузки по чувствительности и исключайте лишние учётные данные
Kubernetes также рекомендует размещать рабочие нагрузки с разными уровнями чувствительности на отдельных узлах и не монтировать токены сервисных аккаунтов в поды, которым они не нужны. Обе меры описаны в официальном контрольном списке по безопасности.
Размещение на отдельных узлах призвано затруднить прямой переход к более чувствительным приложениям после выхода за пределы изоляции контейнера. Отказ от монтирования ненужного токена сервисного аккаунта также исключает присутствие внутри пода дополнительных учётных данных, не связанных с SVID.
Практическая последовательность проверки
С учётом этой границы доверия можно составить короткую последовательность проверки, которая охватывает и конфигурацию, и размещение рабочих нагрузок:
Область действия идентичностей: Какие SPIFFE ID связаны с каждым узлом и нагрузки каких уровней чувствительности размещены на нём вместе?
Исходные данные для аттестации: Какие данные операционной системы или kubelet используются селекторами и можно ли подделать их при наличии root-доступа?
Привилегии на узле: Какие поды являются привилегированными, имеют доступ к хосту, допускают повышение привилегий или работают от имени root?
Дополнительные учётные данные: Какие поды получают токены сервисных аккаунтов, хотя не нуждаются в них?
Это не означает, что SVID бесполезны. Их криптографические гарантии идентичности необходимо оценивать вместе с целостностью узла, на котором выполняется аттестация. Устойчивая модель сочетает удостоверения рабочих нагрузок с коротким сроком действия, усиление защиты подов, точные условия селекторов, разделение узлов по уровню чувствительности и удаление ненужных учётных данных.
