Аудит безопасности Kubernetes: как проверить конфигурацию, права и управление кластером

Представим условную ситуацию. Вымышленная B2B-платформа готовится подключить крупного корпоративного клиента. Продукт работает в нескольких кластерах Kubernetes: каждому клиенту выделено своё пространство имён, деплой идёт через GitOps, часть дополнений поставляет провайдер управляемого сервиса. В анкете безопасности клиент спрашивает, как его данные изолированы от других арендаторов и кто в компании может изменить конфигурацию его окружения. Технический директор уверен: «у каждого клиента свой namespace, значит, всё изолировано». Руководитель платформы не так уверен, но не может быстро показать, кто и через какие роли имеет доступ к секретам, какие поды запускаются с повышенными привилегиями и действительно ли сетевые политики что-то блокируют.

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

Что проверяет аудит конфигурации и управления Kubernetes

Аудит безопасности Kubernetes в этом понимании — авторизованная структурированная оценка того, как кластерная среда настроена, кем управляется и какие ограничения в ней действительно действуют. Тест одного приложения затрагивает один уровень. Кластер состоит из нескольких уровней, и каждый отказывает по-своему: доступ к API, идентичности и привязки ролей, конфигурация нагрузок, сеть, секреты, журналы аудита и цепочка поставки образов.

Чем этот аудит отличается от технической оценки кластера

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

Инвентаризация как первый результат

Аудит начинается с вопроса «что вообще есть». Сюда входят кластеры и их версии, пространства имён и их назначение, узлы и пулы узлов, установленные операторы, контроллеры и вебхуки допуска, сетевой плагин, способ хранения секретов, источники образов и подключённые внешние системы идентификации. Без такой инвентаризации невозможно честно сказать, что входило в охват. Её стоит фиксировать с версиями и датой среза: кластеры перенастраиваются часто, и снимок без даты быстро теряет доказательную ценность. Нередко уже на этом шаге обнаруживаются забытые тестовые пространства имён, операторы без владельца или кластер, который никто не считал продуктивным.

Четыре границы, которые нельзя смешивать

Самая частая ошибка в разговоре о безопасности Kubernetes — считать «изоляцию» одним свойством. На деле аудитор проверяет как минимум четыре разные границы, и каждая держится на своих механизмах.

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

Почему пространство имён — не жёсткая изоляция

Пространство имён в Kubernetes — механизм группировки и разграничения объектов API внутри одного кластера. Оно задаёт область видимости имён и удобную точку привязки ролей, квот и политик. Само по себе оно не создаёт ни сетевой, ни ядерной изоляции. Документация Kubernetes о мультиарендности прямо говорит, что модель изоляции через пространства имён требует настройки ряда других ресурсов и сетевых плагинов, а также следования практикам безопасности. По умолчанию поды в кластере могут обмениваться трафиком друг с другом, а контейнеры остаются процессами на общем ядре узла.

Поэтому формулировка «каждому клиенту — свой namespace» описывает организационную границу, а не доказанную изоляцию. Чтобы она стала границей безопасности, нужны ограничительные RBAC-гранты, запрет доступа к кластерным ресурсам, сетевые политики с плагином, который их применяет, ограничения нагрузок на уровне допуска и, для недоверенных арендаторов, разделение узлов или песочницы.

RBAC: читать гранты, а не названия ролей

Идентичность и доступ проверяют в первую очередь, потому что API кластера управляет всем остальным. Для каждого субъекта аудитору нужны ответы на три вопроса: какие идентичности могут пройти аутентификацию, каким механизмом и что каждой из них разрешено после входа. Названия вроде «readonly» или «developer» ничего не гарантируют: значение имеют только правила внутри объектов Role и ClusterRole и то, к кому они привязаны.

Опасные глаголы и косвенные пути эскалации

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

Гранты на глаголы escalate, bind и impersonate требуют особого внимания: в зависимости от области действия и объекта они могут позволить эскалацию привилегий — например, создать или привязать роль шире собственной либо действовать от имени другого субъекта. Но это не автоматический вывод: право bind, ограниченное одной узкой ролью в одном пространстве имён, или impersonate только для конкретной служебной идентичности нужно оценивать по тому, что именно становится доступно.

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

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

Сервисные аккаунты и идентичность нагрузок

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

Контроли нагрузок и допуска

Конфигурация пода определяет, насколько тесно контейнер связан с узлом. Аудитор смотрит на привилегированный режим, добавленные возможности ядра, монтирование путей хоста, использование сетевого, процессного или IPC-пространства хоста, запуск от root, разрешение эскалации привилегий, профили seccomp и AppArmor и неизменяемость корневой файловой системы.

Привилегированный под — находка, но не доказательство побега

Привилегированный под или монтирование корня хоста — серьёзная находка: такая конфигурация снимает большую часть барьеров между контейнером и узлом. Но это ещё не доказательство эксплуатируемого побега через уязвимость ядра. Конфигурационная находка говорит, что граница ослаблена или отсутствует; утверждение о побеге требует отдельного авторизованного теста, условий, при которых он воспроизводится, и свидетельств. В отчёте эти уровни нужно разводить: «изоляция узла не обеспечена для нагрузки X» и «продемонстрирован выход на узел» — разные выводы с разными последствиями. Если нужно подтвердить именно возможность выхода, это отдельный тип работ, описанный в статье о тестировании на проникновение для выхода из контейнера.

Политики допуска как точка принуждения

Правильная конфигурация отдельных подов мало что значит, если ничто не мешает завтра задеплоить неправильную. Поэтому аудит проверяет контроль допуска: встроенный Pod Security Admission с уровнями privileged, baseline и restricted или внешний движок политик. Ключевые вопросы — в каком режиме работает политика (enforce, audit или warn), на какие пространства имён она распространяется, какие исключения выданы, кем и на какой срок, и что происходит при недоступности вебхука. Режим warn — обнаруживающая мера контроля: он показывает нарушения, но не блокирует развёртывание и поэтому не является превентивной мерой. В отчёте его не стоит выдавать за принуждение. Сами вебхуки допуска и операторы — это код с широкими правами, и их собственные привязки тоже входят в охват.

Сеть, секреты и исходящий трафик

NetworkPolicy работает только при поддержке плагина

Объект NetworkPolicy — это декларация намерения. Документация Kubernetes указывает, что сетевые политики реализует сетевой плагин, а создание NetworkPolicy без контроллера, который её применяет, не имеет эффекта. Поэтому аудитор проверяет сразу три вещи: поддерживает ли установленный плагин политики, есть ли в пространствах имён политика запрета по умолчанию и совпадают ли селекторы с реальными метками подов. Без запрета по умолчанию под, не выбранный ни одной политикой, остаётся открытым для входящих соединений. Проверка не ограничивается чтением YAML: короткий согласованный тест соединения между двумя подами показывает, действует ли правило на самом деле.

Секреты: кто может их прочитать фактически

По умолчанию секреты Kubernetes хранятся в etcd без шифрования, и прочитать их может любой, у кого есть доступ к API с нужными правами или доступ к etcd. Поэтому аудит секретов сводится к вопросу о фактическом доступе: включено ли шифрование на уровне хранилища, кто может читать секреты напрямую, кто может создавать поды и тем самым монтировать их, не попадают ли значения в журналы, образы или репозитории, как секреты доставляются в нагрузку — через тома или переменные окружения — и оправдан ли выбранный способ с учётом модели угроз и возможной экспозиции, используется ли внешнее хранилище и как нагрузка в нём аутентифицируется. Найденные значения секретов документируются ссылкой на объект, а не копией, и передаются владельцу по согласованному каналу.

Egress как отдельная граница охвата

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

Методика: от разрешения до проверки на стенде

Процессную дисциплину по-прежнему хорошо задаёт NIST SP 800-115. Формальный процесс оценки в нём описан через планирование, выполнение и действия после выполнения. Для аудита кластера удобна редакционная адаптация этой схемы: планирование, проведение проверок и тестов, анализ результатов, устранение с перепроверкой. Это практическая последовательность, а не официальная модель NIST. Руководство старше массового распространения оркестрации контейнеров, поэтому из него берут именно дисциплину процесса, а конкретные параметры кластера — из актуальной документации платформы и руководств по укреплению, которые команда аудита получает и проверяет сама.

Письменное разрешение и условия остановки

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

Сначала чтение, потом точечные тесты

SP 800-115 отделяет проверки — анализ документации, конфигураций и журналов — от тестирования, которое активно воздействует на систему. Для кластеров это различие принципиально. Чтение манифестов, привязок ролей, политик допуска и журналов аудита в режиме только чтения почти не несёт операционного риска. Активные действия в продуктиве могут повлиять на доступность общей инфраструктуры. Обоснованная последовательность — сначала проверки, затем точечные тесты на промежуточной копии или в согласованных пределах, и только там, где тест отвечает на вопрос, на который чтение ответить не может.

1. РазрешениеВладелец письменно фиксирует кластеры, пространства имён, учётные записи, техники, окна и условия остановки.
2. ИнвентаризацияКоманда описывает кластеры, версии, операторы, вебхуки, сетевой плагин и хранение секретов с датой среза.
3. Чтение конфигурацииRBAC, сервисные аккаунты, контексты безопасности подов, политики допуска и сетевые политики разбираются в режиме только чтения.
4. Точечные тестыАктивные проверки выполняются только для вопросов, на которые чтение не отвечает, и в согласованных пределах.
5. Приёмка и перепроверкаКаждая находка получает владельца, критерий закрытия и повторную проверку исправления.

Работа с доказательствами

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

Владение и управление: у каждой находки должен быть хозяин

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

Находки как разрывы относительно целей, а не провалы чек-листа

Проверки в стиле бенчмарка дают ясный ответ «пройдено» или «не пройдено», но не каждая проваленная проверка одинаково важна для бизнеса. NIST CSF 2.0 позволяет выразить результаты как разрывы относительно целевых результатов организации: руководство видит, какие из них влияют на профиль рисков, а инженеры по-прежнему получают точные проверяемые пункты. Повторяющаяся ошибка конфигурации должна вести к изменению шаблонов, политик или конвейеров, а не к ручной правке одного манифеста. Если кластеры описаны кодом, правка в шаблоне и есть устранение первопричины; как проверять такие шаблоны, разобрано в статье об оценке безопасности инфраструктуры как кода.

Управляемые платформы и поставщики

Многие кластеры работают на управляемых платформах и используют сторонние дополнения, поэтому часть управления лежит на поставщиках. Принципы CISA Secure by Design исходят из того, что продукты должны быть защищены по умолчанию, а многофакторная аутентификация, журналирование и единый вход должны быть доступны без доплаты. Руководство Secure by Demand предлагает заказчикам задавать соответствующие вопросы при закупке, и команда аудита может применить ту же логику: что включено по умолчанию, доступны ли журналы аудита плоскости управления без дополнительного лицензирования, как поставщик работает с классами уязвимостей. Ответы попадают в материалы аудита с документальным подтверждением, а не со слов.

Приоритизация находок

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

Пути к правам важнее гигиены

Выше всего стоят находки, которые складываются в путь: право создавать поды плюс привилегированный контекст плюс отсутствие политики допуска; токен с широкими правами плюс открытый egress. Изолированная проблема гигиены вроде отсутствующей метки или неоптимального лимита ресурсов ранжируется ниже, даже если таких пунктов много. Для собственного кода платформы — контроллеров, операторов, вебхуков допуска — полезен взгляд через классы слабостей CWE Top 25: дефекты этого кода соотносятся с классами CWE, а MITRE отмечает, что слабости вроде внедрения команд привлекают внимание атакующих.

Где заканчивается аудит кластера

Приложения, работающие в кластере, входят в общую картину, но их проверка — отдельный слой. Если приложение опирается на сетевые политики, TLS на ingress или хранилище секретов, эти меры платформы попадают в проверку по OWASP ASVS; требования при этом стоит цитировать с тегом версии, например v5.0.0-1.2.5, потому что идентификаторы меняются между версиями. OWASP Top 10 подходит для разговора о рисках с командами разработки, но не заменяет стандарт верификации.

Приёмка: какие артефакты закрывают аудит

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

Перепроверка и превращение проверок в контроль

Исправление считается подтверждённым после повторной проверки тем же методом, которым была найдена проблема, с фиксацией версии и даты. Подробно о том, как доказать, что исправление действительно работает, рассказано в статье о проверке устранения уязвимостей после пентеста. Поскольку кластеры часто перенастраиваются, разовый снимок быстро устаревает: SP 800-115 говорит о проектировании, внедрении и поддержании процессов тестирования и проверок. Самые ценные проверки аудита стоит превратить в повторяемые правила — в политиках допуска, в конвейере или в регулярной сверке прав.

Чем аудит и пентест не являются

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

Решения для заказчика

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

Что подготовить до старта

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