Yandex Cloud
Поиск
Связаться с экспертомПопробовать бесплатно
  • Кейсы
  • Документация
  • Блог
  • Все сервисы
    • Cloud Interconnect
    • Cloud Backup
    • Cloud Registry
    • Compute Cloud
    • Object Storage
    • Managed Service for Kubernetes®
    • Managed Service for PostgreSQL
    • Managed Service for ClickHouse®
    • Monium
    • Cloud CDN
    • Network Load Balancer
    • Virtual Private Cloud
    • Cloud DNS
    • Application Load Balancer
    • Yandex Cloud Router
    • Managed Service for MySQL®
    • Managed Service for Valkey™
    • Managed Service for Apache Spark™
    • Managed Service for OpenSearch
    • Managed Service for Apache Kafka®
    • Data Transfer
    • Yandex MPP Analytics Engine for PostgreSQL
    • Managed Service for YDB
    • SpeechKit
    • Yandex Identity Hub
    • Key Management Service
    • Certificate Manager
    • Yandex Lockbox
    • Audit Trails
    • Container Registry
    • Managed Service for Prometheus®
    • Message Queue
    • Identity and Access Management
    • Yandex Cloud Console
    • Resource Manager
    • Yandex Cloud Billing
    • Cloud Apps
    • Yandex AI Studio
    • Yandex BareMetal
    • Smart Web Security
    • Security Deck
    • Yandex Cloud Video
    • Stackland
    • Yandex Managed Service for Apache Airflow®
    • Data Processing
    • Yandex MetaData Hub
    • Yandex WebSQL
    • DataLens
    • Yandex Search API
    • SpeechSense
    • DataSphere
    • Vision OCR
    • Translate
    • SmartCaptcha
    • Yandex SIEM
    • SourceCraft Code Assistant
    • Managed Service for GitLab
    • Cloud Functions
    • API Gateway
    • Yandex Cloud Postbox
    • IoT Core
    • Serverless Containers
    • Cloud Notification Service
  • Статус работы сервисов
  • Marketplace
    • Доступны в регионе
    • Инфраструктура и сеть
    • Платформа данных
    • Искусственный интеллект
    • Безопасность
    • Инструменты DevOps
    • Бессерверные вычисления
    • Управление ресурсами
  • Все решения
    • По отраслям
    • По типу задач
    • Экономика платформы
    • Безопасность
    • Техническая поддержка
    • Каталог партнёров
    • Обучение и сертификация
    • Облако для стартапов
    • Облако для крупного бизнеса
    • Центр технологий для общества
    • Партнёрская программа
    • Облако для фрилансеров
    • Обучение и сертификация
    • Блог
    • Документация
    • Мероприятия и вебинары
    • Контакты, чаты и сообщества
    • Идеи
    • Калькулятор цен
    • Тарифы
  • Кейсы
  • Документация
  • Блог
Проект Яндекса
© 2026 ТОО «Облачные Сервисы Казахстан»
Yandex Security Deck
RU
  • Правила тарификации
  • Аудитные логи Audit Trails
    • Все вопросы на одной странице
  • История изменений

В этой статье:

  • Вопросы про модуль KSPM
  • 1. Что делать, если уже используется собственная инсталляция Kyverno?
  • 2. Какие типы политик доступны в пользовательских правилах KSPM?
  • 3. Можно ли использовать не все компоненты KSPM одновременно?
  • 4. Как работает тарификация в случае с прерываемыми рабочими узлами в Kubernetes?
  • 5. Можно ли исключить из проверки KSPM определенные ресурсы или кластеры?
  • 6. Требует ли KSPM больше ресурсов для установки, чем другие модули Security Deck?
  • 7. Какая нагрузка на ресурсы кластера и какие агенты устанавливает KSPM?
  1. Вопросы и ответы
  2. Все вопросы на одной странице

Вопросы и ответы про Security Deck

Статья создана
Yandex Cloud
Обновлена 2 ноября 2026 г.
Открыть в Markdown
  • Вопросы про модуль KSPM
    • 1. Что делать, если уже используется собственная инсталляция Kyverno?
    • 2. Какие типы политик доступны в пользовательских правилах KSPM?
    • 3. Можно ли использовать не все компоненты KSPM одновременно?
    • 4. Как работает тарификация в случае с прерываемыми рабочими узлами в Kubernetes?
    • 5. Можно ли исключить из проверки KSPM определенные ресурсы или кластеры?
    • 6. Требует ли KSPM больше ресурсов для установки, чем другие модули Security Deck?
    • 7. Какая нагрузка на ресурсы кластера и какие агенты устанавливает KSPM?

Вопросы про модуль KSPMВопросы про модуль KSPM

1. Что делать, если уже используется собственная инсталляция Kyverno?1. Что делать, если уже используется собственная инсталляция Kyverno?

Одним из компонентов модуля KSPM является Kyverno. Если в кластере уже используется собственная инсталляция Kyverno, выберите один из вариантов:

  • При создании или изменении окружения в настройках не включайте правила Kubernetes Pod Security Standards (Restricted) и Kubernetes Pod Security Standards (Baseline) и продолжайте использовать собственный Kyverno.

  • Перейдите с собственного Kyverno на KSPM.

    Чтобы выполнить переход:

    1. Создайте резервную копию ваших политик.

    2. Удалите Kyverno.

    3. Активируйте модуль KSPM.

    4. Добавьте политики в KSPM одним из способов или комбинируйте их:

      • Создайте пользовательские правила типа Admission на основе ваших политик и управляйте ими через KSPM. В пользовательских правилах доступны только политики валидации.

        Примечание

        В интерфейсе Security Deck не поддерживается автоматический импорт политик Kyverno. Необходимо вручную переформулировать их логику в пользовательские правила KSPM перед добавлением.

      • Разверните собственные политики через Kubernetes API. Поддерживаются любые типы политик. Подробнее — в документации Kyverno.

2. Какие типы политик доступны в пользовательских правилах KSPM?2. Какие типы политик доступны в пользовательских правилах KSPM?

В пользовательских правилах KSPM доступны только политики валидации. Другие типы, например политики мутации, генерации или проверки образов не поддерживаются.

Подробнее о механизмах валидации и мутации — в официальной документации Kubernetes.

3. Можно ли использовать не все компоненты KSPM одновременно?3. Можно ли использовать не все компоненты KSPM одновременно?

Да. Например, чтобы использовать только Runtime Sensor, включите проверки по набору правил Microsoft Threat Matrix для Kubernetes в настройках окружения.

4. Как работает тарификация в случае с прерываемыми рабочими узлами в Kubernetes?4. Как работает тарификация в случае с прерываемыми рабочими узлами в Kubernetes?

Тарификация рассчитывается суммарно по модели «рабочий узел в месяц» (или «рабочий узел в час»). Один рабочий узел в месяц может представлять собой:

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

Привязки к конкретным рабочим узлам нет. Остановленные рабочие узлы не тарифицируются.

Подробнее о правилах тарификации в разделе Правила тарификации Yandex Security Deck.

5. Можно ли исключить из проверки KSPM определенные ресурсы или кластеры?5. Можно ли исключить из проверки KSPM определенные ресурсы или кластеры?

Да. В KSPM есть механизм исключений, который позволяет исключить из проверки выбранные ресурсы Kubernetes или целые кластеры.

6. Требует ли KSPM больше ресурсов для установки, чем другие модули Security Deck?6. Требует ли KSPM больше ресурсов для установки, чем другие модули Security Deck?

Да. Из всех модулей Security Deck только KSPM требует ресурсы внутри рабочих нагрузок. Остальные модули ограничиваются дополнительными правами для коннектора.

Подробнее в разделе Системные и технические требования.

7. Какая нагрузка на ресурсы кластера и какие агенты устанавливает KSPM?7. Какая нагрузка на ресурсы кластера и какие агенты устанавливает KSPM?

Системные и технические требования к кластерам, рекомендации по ресурсам, а также информация об устанавливаемых агентах и условиях их установки приведены в разделе Системные и технические требования.

Политика валидации — правило проверки ресурсов Kubernetes на соответствие требованиям безопасности. Относится к типу Admission и работает в двух режимах:

  • Аудит — фиксирует нарушения, но не блокирует операцию (режим по умолчанию);
  • Блокировка — отклоняет запрос при несоответствии требованиям.

Подробнее в разделе Управление режимами работы правил контроля безопасности модуля KSPM

Политика мутации — правило, которое корректирует объекты в кластере при их создании или обновлении для соответствия стандартам безопасности.

Политика генерации — правило, которое автоматически создает дополнительные ресурсы в кластере в ответ на появление целевого объекта, например нового пространства имен.

Политика проверки образов — правило, которое контролирует образы контейнеров на соответствие требованиям: наличие подписи, допустимость реестра, отсутствие критических уязвимостей.

Была ли статья полезна?

Предыдущая
Аудитные логи Audit Trails
Следующая
История изменений
Проект Яндекса
© 2026 ТОО «Облачные Сервисы Казахстан»