Дополнительные утилиты для Kaspersky Container Security#

Три открытые утилиты вокруг KCS. Каждая закрывает то, чего в самом продукте нет: проверка кластера до установки, перенос настроек между инстансами и выгрузка находок во внешние системы. Все три писались под живые пилоты у заказчиков, поэтому ставятся без сборочного окружения на стороне заказчика.

KCS_Test — предпроверка кластера до helm install#

kcs_k8s_check.sh прогоняет кластер по требованиям KCS 2.5.1 и отвечает на один вопрос: пройдёт ли установка. Скрипт кластер только читает. Временные ресурсы — тестовый PVC, под-пробник реестра и по поду на каждый узел для проверки eBPF — удаляются при выходе.

Шестнадцать проверок, A–P: версия и дистрибутив Kubernetes, CPU, память, ephemeral storage, StorageClass с привязкой PVC, IngressClass или Gateway API, DNS, доступность repo.kcs.kaspersky.com изнутри кластера, ОС и ядро узлов, поддержка BTF для eBPF CO-RE, внешний PostgreSQL, HashiCorp Vault, container runtime, CNI, версия Helm и запас ресурсов под агенты. На выходе — Markdown-отчёт kcs-precheck-<timestamp>.md.

Две трактовки требований, которые отличают скрипт от наивного чтения документации:

• Ёмкость считается по каждому worker-узлу, а не суммой по кластеру. 13 ядер, 20 ГБ памяти и 28 ГБ ephemeral storage документация требует от узла. Три воркера по 8 ядер дают в сумме 24 и проходили проверку версии 2.4 — но 13 ядер не вытягивает ни один из них. Control plane из подсчёта исключается по метке node-role.kubernetes.io/control-plane.
• Версия выше минимума, но вне списка протестированных, даёт WARN, а не FAIL. Документация прямо пишет: отсутствие в списке не доказывает несовместимость. Ненулевой код возврата даёт только FAIL, поэтому «непротестированный, но рабочий» кластер пилот не блокирует.

Vanilla Kubernetes, OpenShift и RKE2 распознаются по kubectl version, и к каждому применяется своя шкала версий. K3s отвергается всегда — дистрибутив не поддерживается.

Параметры задаются и флагами, и переменными окружения (TARGET_NAMESPACE, PROBE_NAMESPACE, STORAGE_CLASS, DOMAIN, SKIP_DNS_CHECK, SKIP_REGISTRY_CHECK и другие), так что скрипт пригоден и для CI:

TARGET_NAMESPACE=kcs \
PROBE_NAMESPACE=kcs \
STORAGE_CLASS=longhorn \
SKIP_DNS_CHECK=1 \
SKIP_REGISTRY_CHECK=1 \
./kcs_k8s_check.sh

Проверки внешнего PostgreSQL и Vault включаются отдельно — --external-db и --vault; без них они просто пропускаются.

KCS Migrator — перенос настроек между инстансами#

Штатной кнопки «выгрузить конфигурацию в файл» в KCS нет. Migrator снимает настройки работающего инстанса KCS 2.4 через REST API, складывает их в каталог-бандл и затем воспроизводит на чистом инстансе. Важен порядок: политика сошлётся на реестр образов, которого на новом инстансе ещё нет, поэтому импорт идёт по графу зависимостей, а не по алфавиту файлов.

Что попадает в бандл:

• интеграции — реестры образов, LDAP, SSO, LLM, группы агентов; каналы оповещений и валидаторы подписей выгружаются справочно;
• политики — сканирования, assurance, профили runtime, runtime, реагирования, сетевой репутации;
• компоненты — приоритет сканеров;
• конфигурация — хранилище отчётов;
• пользователи — справочно, через kubectl exec: пароли и токены REST API не отдаёт.

Две подкоманды:

# снять конфигурацию
kcs-migrator export --url https://kcs-old.example.com --token "$KCS_TOKEN" --output ./bundles

# воспроизвести на новом инстансе
kcs-migrator import ./bundles/kcs-export-2026-10-03_12-00-00 \
  --url https://kcs-new.example.com --token "$KCS_NEW_TOKEN"

Вместо флагов читаются KCS_URL и KCS_TOKEN. Самоподписанный сертификат на стенде — --no-verify-tls. Выгрузку пользователей можно отключить (--skip-users), а каталог бандла получает имя вида kcs-export-YYYY-MM-DD_HH-MM-SS/ с JSON-файлами по категориям и манифестом.

KCS2ASH — передача находок в вебхуки и ASOC#

Вебхук KCS сообщает только о факте сканирования: имя образа, реестр, политику реагирования. Находок в нём нет, и приёмнику — SIEM, дашборду, ASOC-платформе — предъявить нечего. ASH достраивает остальное: это stateless-демон без собственного состояния и базы.

Цепочка:

1. KCS заканчивает сканирование и постит на /webhook тело с image_name, registry_name, response_policy_name;
2. ASH находит по образу его scan ID через REST API KCS (список реестров и вложенный список образов);
3. параллельно забирает все четыре типа находок: уязвимости, вредоносное ПО, мисконфигурации, секреты;
4. нормализует их в один отчёт (event_id, scan_id, summary, findings[]) и постит на KCS_OUTPUT_URL.

Формат выхода переключается KCS_OUTPUT_FORMAT:

• default — нормализованный JSON для произвольного приёмника. Включает все четыре типа находок;
• appsechub — multipart/form-data с файлом hub.json по схеме AppSecHub v1.0.1, авторизация заголовком X-Authorization. Схема определяет только тип sca_s для CVE в образах, поэтому в этом режиме уходят только уязвимости; вредоносное ПО, мисконфигурации и секреты в отчёт не попадают. На старте демон пишет об этом в лог.

Доставка с повторами: на 5xx, 408, 429 и сетевую ошибку — две попытки с паузами 1 и 2 секунды, затем отказ. Остальные 4xx считаются постоянной ошибкой и повторов не вызывают.

Образ собран на debian:bookworm-slim — базовый слой нужен лишь ради корневых сертификатов. Разворачивается через deploy/ и kustomize, манифесты рассчитаны на vanilla Kubernetes, OpenShift и Deckhouse. Компилировать заказчику нечего: ставится образ.