Вопросы и ответы про Security Deck
- Вопросы про модуль KSPM
- 1. Что делать, если уже используется собственная инсталляция Kyverno?
- 2. Какие типы политик доступны в пользовательских правилах KSPM?
- 3. Можно ли использовать не все компоненты KSPM одновременно?
- 4. Как работает тарификация в случае с прерываемыми рабочими узлами в Kubernetes?
- 5. Можно ли исключить из проверки KSPM определенные ресурсы или кластеры?
- 6. Требует ли KSPM больше ресурсов для установки, чем другие модули Security Deck?
- 7. Какая нагрузка на ресурсы кластера и какие агенты устанавливает KSPM?
Вопросы про модуль KSPM
1. Что делать, если уже используется собственная инсталляция Kyverno?
Одним из компонентов модуля KSPM является Kyverno
-
При создании или изменении окружения в настройках не включайте правила Kubernetes Pod Security Standards (Restricted) и Kubernetes Pod Security Standards (Baseline) и продолжайте использовать собственный Kyverno.
-
Перейдите с собственного Kyverno на KSPM.
Чтобы выполнить переход:
-
Создайте резервную копию ваших политик.
-
Удалите Kyverno.
-
Активируйте модуль KSPM.
-
Добавьте политики в KSPM одним из способов или комбинируйте их:
-
Создайте пользовательские правила типа Admission на основе ваших политик и управляйте ими через KSPM. В пользовательских правилах доступны только политики валидации.
Примечание
В интерфейсе Security Deck не поддерживается автоматический импорт политик Kyverno. Необходимо вручную переформулировать их логику в пользовательские правила KSPM перед добавлением.
-
Разверните собственные политики через Kubernetes API. Поддерживаются любые типы политик. Подробнее — в документации Kyverno
.
-
-
2. Какие типы политик доступны в пользовательских правилах KSPM?
В пользовательских правилах KSPM доступны только политики валидации. Другие типы, например политики мутации, генерации или проверки образов не поддерживаются.
Подробнее о механизмах валидации и мутации — в официальной документации Kubernetes
3. Можно ли использовать не все компоненты KSPM одновременно?
Да. Например, чтобы использовать только Runtime Sensor, включите проверки по набору правил Microsoft Threat Matrix для Kubernetes в настройках окружения.
4. Как работает тарификация в случае с прерываемыми рабочими узлами в Kubernetes?
Тарификация рассчитывается суммарно по модели «рабочий узел в месяц» (или «рабочий узел в час»). Один рабочий узел в месяц может представлять собой:
- один рабочий узел, который работает весь месяц;
- два рабочих узла, каждый из которых работает по половине месяца.
Привязки к конкретным рабочим узлам нет. Остановленные рабочие узлы не тарифицируются.
Подробнее о правилах тарификации в разделе Правила тарификации Yandex Security Deck.
5. Можно ли исключить из проверки KSPM определенные ресурсы или кластеры?
Да. В KSPM есть механизм исключений, который позволяет исключить из проверки выбранные ресурсы Kubernetes или целые кластеры.
6. Требует ли KSPM больше ресурсов для установки, чем другие модули Security Deck?
Да. Из всех модулей Security Deck только KSPM требует ресурсы внутри рабочих нагрузок. Остальные модули ограничиваются дополнительными правами для коннектора.
Подробнее в разделе Системные и технические требования.
7. Какая нагрузка на ресурсы кластера и какие агенты устанавливает KSPM?
Системные и технические требования к кластерам, рекомендации по ресурсам, а также информация об устанавливаемых агентах и условиях их установки приведены в разделе Системные и технические требования.
Политика валидации — правило проверки ресурсов Kubernetes на соответствие требованиям безопасности. Относится к типу Admission и работает в двух режимах:
Аудит— фиксирует нарушения, но не блокирует операцию (режим по умолчанию);Блокировка— отклоняет запрос при несоответствии требованиям.
Подробнее в разделе Управление режимами работы правил контроля безопасности модуля KSPM
Политика мутации — правило, которое корректирует объекты в кластере при их создании или обновлении для соответствия стандартам безопасности.
Политика генерации — правило, которое автоматически создает дополнительные ресурсы в кластере в ответ на появление целевого объекта, например нового пространства имен.
Политика проверки образов — правило, которое контролирует образы контейнеров на соответствие требованиям: наличие подписи, допустимость реестра, отсутствие критических уязвимостей.