PT CRIS Kubernetes vs. CIS Kubernetes Benchmark: что на самом деле нового#

Positive Technologies представили PT CRIS Kubernetes как первый российский стандарт практических проверок безопасности Kubernetes и подали это как самостоятельную разработку. Разбор мной самой матрицы и текста CIS Kubernetes Benchmark даёт более скромную для практика картину: технических открытий в CRIS нет, в ней имеется организационная часть — матрица трассируемости.

Что есть в CIS Kubernetes Benchmark#

CIS Kubernetes Benchmark — открытый международный стандарт CIS (Center for Internet Security). Содержит пять разделов: компоненты control plane (файлы конфигурации, флаги API-сервера, controller manager, scheduler), etcd, конфигурация control plane, worker-узлы (kubelet) и раздел Policies — RBAC, Pod Security, сетевые политики, секреты, admission control, namespaces и seccomp. У каждой рекомендации — статус Automated или Manual и профиль применимости Level 1 / Level 2 для master- и worker-узла. Никакой шкалы критичности и никакой привязки к нормативке у CIS нет — только «применимо на уровне 1» или «на уровне 2».

Что есть в CRIS#

CRIS — не список других проверок, но лишь таблица сопоставления. Каждая строка связывает одну проверку CRIS (свой ID вида CS_IAC_K8S_API_AC_ALWAYS_ADMIT) с одним пунктом одного из четырёх стандартов: CIS Kubernetes Benchmark v2.0.0, NIST SP 800-190, PCI DSS v4.0 и приказ ФСТЭК России №118. У каждой проверки CRIS — критичность по четырём уровням (Низкая / Средняя / Высокая / Критическая), а у каждой связи — тип: Прямое, Частичное или Нет.

По подсчёту строк матрицы картина такая:

Ни одна проверка CRIS не сопоставлена с приказом №118 как «Прямое» соответствие. Максимум — «Частичное», и таких меньше половины. Сами авторы матрицы честно признают, что написано в её же вводной части: ФСТЭК №118 формулирует общие требования, а не конкретные технические параметры, поэтому связать конкретную настройку API-сервера с конкретным пунктом приказа один в один не получается ни у кого. CRIS этот факт не устраняет, а просто документирует.

Технические проверки — это CIS, только переименованный#

Открываем любую проверку CRIS — и узнаём CIS. CS_IAC_K8S_API_AC_ALWAYS_ADMIT («включён плагин контроллера допуска AlwaysAdmit») привязан к пункту CIS 1.2.10/1.2.11 — том самом, что запрещает admission-плагин AlwaysAdmit. CS_IAC_K8S_API_AUDIT_LOG_PATH привязан к CIS 1.2.16 — --audit-log-path. Проверки из блока Pod Security (CS_IAC_K8S_PSS_*) идут под номерами 5.2.x — это ровно то же место, где в CIS v2.0.0 после отказа от PodSecurityPolicy появились проверки Pod Security Standards. Нумерация CRIS почти везде дословно копирует секции CIS: 1.2.x — API-сервер, 1.3.x — controller manager, 1.4.x — scheduler, 2.x — etcd, 5.1.x — RBAC и кластерные роли, 5.2.x — Pod Security, 5.6.x — namespaces.

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

Где CRIS реально меньше, чем CIS#

PT сама публикует список пунктов CIS Kubernetes Benchmark v2.0.0, для которых у CRIS нет проверки вообще — с явным CRIS ID = «Нет». Список большой, идёт отдельным блоком в конце документа и покрывает:

• весь раздел 1.1 — права доступа и владелец файлов конфигурации API-сервера, etcd, PKI-директории;
• весь раздел 4.1–4.3 — права на файлы и флаги kubelet, включая --anonymous-auth, --read-only-port, ротацию сертификатов;
• часть 5.1 (RBAC), 5.2 (Pod Security), 5.3 (сетевые политики), 5.4 (управление секретами), 5.5 (admission webhook) и 5.6 (namespaces).

Раздел про права на файлы и владельца объясним: это проверки, требующие доступа к файловой системе control-plane узла, а не к Kubernetes API — логично, что агентless-инструмент вроде PT Container Security их не покрывает без агента на хосте. Но пропуски в 5.1–5.6 — это уже пробелы по содержанию, а не по архитектуре: сетевые политики, доступ к secrets, ограничение wildcard-ролей — всё это проверяется через API так же, как остальные CRIS-проверки. Итог по строкам таблицы: 65 пунктов CIS не покрыты CRIS против 62 покрытых — то есть CRIS закрывает примерно половину CIS Kubernetes Benchmark v2.0.0, а не расширяет его.

Что в CRIS нового#

1. Готовая трассируемость к четырём стандартам сразу. Публичного документа, который сводит конкретные технические проверки Kubernetes с приказом ФСТЭК №118, до CRIS не было: в CIS, NIST и PCI DSS такой привязки не делают в принципе, потому что они международные и к российской нормативке не апеллируют.
2. Явная шкала критичности на уровне отдельной проверки. У CIS есть только Level 1/2 (применимость профиля), у CRIS — четыре градации риска, что ближе к тому, как ИБ-команда обычно расставляет приоритеты по факту компрометации, а не по «профилю развёртывания».
3. Честно задокументированные пробелы. Список несопоставленных пунктов CIS публикуется прямо в матрице, а не прячется — редкость для вендорского материала.
4. Продуктовая обвязка. PT Container Security 1.2 сверяет конфигурацию кластера с этой матрицей автоматически, то есть CRIS работающий движок сравнения, что для конечного пользователя удобнее, чем сама таблица.

Вывод#

PT CRIS Kubernetes - не новый набор проверок безопасности Kubernetes, но юридически и организационно оформленная надстройка над CIS Kubernetes Benchmark: перевод, перенумерация, добавка степеней критичности и попытка привязать всё это к российским требованиям. Ценность не в технической новизне материала, а в том, что раньше этой привязки не было ни у кого, и ещё в том, что PT показали, где сопоставление не работает (весь блок ФСТЭК №118 и половина CIS v2.0.0). Для команд, которым нужно объяснить регулятору или заказчику, как техническая настройка кластера соотносится с приказом №118, CRIS — первый готовый артефакт такого рода, пусть и с оговоркой «частичное», а не «прямое» соответствие почти везде.