Переменные окружения в командах сканеров

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

Краткая справка

Наиболее часто используемые переменные в командах профилей:

Пример использования в команде сканера:

semgrep scan --json --output "${RESULTS_FILE}" "${SRC_DIR}"

Переменные, зависящие от цели сканирования

Скан репозитория

Скан артефакта (Docker-образа)

Предопределённые пути

Фиксированные директории внутри контейнера сканера:

Переменные результатов

Сканер должен записать результаты в ${RESULTS_FILE} — платформа автоматически заберёт этот файл после завершения команды.

Приватный registry образа сканера

Новое в 2026.10.1

Если образ сканера лежит в приватном registry, для его скачивания нужны учётные данные. В Docker Compose orchestration скачивает образ, если его ещё нет на хосте; уже скачанный образ повторно не скачивается. В Kubernetes образ скачивает кластер по imagePullSecrets pod сканера. Учётные данные не передаются в команду сканера внутри контейнера.

Источник учётных данных (достаточно одного, пара логин и пароль обязательна):

• в профиле оркестрации - переменные SCANNER_REGISTRY_USERNAME и SCANNER_REGISTRY_PASSWORD в блоке Переменные окружения сканера (в API - поле extraEnvVars сканера в профиле). Пароль хранится в зашифрованном виде и в API возвращается замаскированным;
• глобально для установки - в Docker Compose см. подраздел ниже, в Kubernetes - secretsKeyRefs в values chart.

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

В Kubernetes переменные из профиля и secretsKeyRefs действуют только в динамическом режиме, см. подраздел "Учётные данные из профиля" ниже. Без него используются только статические imagePullSecrets.

Отдельных полей для registry в форме профиля нет: используются только эти переменные окружения.

Переменная HW_REGISTRY в таблице выше относится к другому сценарию: скачивание баз и артефактов изнутри команды сканера (например, баз Trivy), а не pull образа сканера orchestration.

Docker Compose

Общие учётные данные для pull образов сканеров можно задать в /opt/hw-vmp/config/user.ini (секция [main]):

Полный список ключей: user-template.ini в той же директории.

Пример в user.ini:

[main]
v.orchestration.scanner.registry.username = registry-user
v.orchestration.scanner.registry.password = <token-or-password>

Примените конфигурацию:

/opt/hw-vmp/bin/reconfig

Параметры попадают в контейнер v_orchestration как ORCHESTRATION_SCANNER_REGISTRY_USERNAME и ORCHESTRATION_SCANNER_REGISTRY_PASSWORD и используются для pull, если в профиле свои SCANNER_REGISTRY_* не заданы.

Kubernetes

По умолчанию pod сканера использует только статические imagePullSecrets, заданные в values chart. Отдельно можно включить режим, когда учётные данные берутся из профиля (SCANNER_REGISTRY_USERNAME / SCANNER_REGISTRY_PASSWORD) или из secretsKeyRefs: orchestration создаёт Secret типа kubernetes.io/dockerconfigjson и подключает его к pod сканера. Для этого образ должен быть указан с хостом registry, например registry.example.com/scanner:tag; для образов без хоста Secret не создаётся. Secret не удаляется после сканирования, а переиспользуется следующими запусками с теми же учётными данными. После смены учётных данных создаётся новый Secret, старый остаётся в namespace.

Общие шаги установки чарта: Установка чарта.

Статический pull Secret

Подходит, если один и тот же registry и учётная запись для всех сканов, и политика не запрещает заранее созданные pull Secret.

1. Создайте Secret registry (подставьте namespace релиза):

kubectl create secret docker-registry scanner-registry-static \
  --namespace="${RELEASE_NAMESPACE}" \
  --docker-server=registry.example.com \
  --docker-username='<registry-username>' \
  --docker-password='<registry-password>'

1. Добавьте Secret в values (фрагмент override.yaml):

vOrchestration:
  scannerRegistry:
    imagePullSecrets:
      - scanner-registry-static

Включать режим dynamicSecrets для этого не нужно.

Учётные данные из профиля

Явно включаемая опция. Chart может создать ServiceAccount и Role с правами на pod сканера и на Secret в namespace релиза (create, get, list, patch, delete).

Учётные данные для pull образа orchestration берёт из профиля (переменные SCANNER_REGISTRY_USERNAME / SCANNER_REGISTRY_PASSWORD, как в разделе выше) или из Secret в кластере через secretsKeyRefs в values (переменные окружения pod orchestration, без хранения пароля в ConfigMap).

1. Если в override заданы secretsKeyRefs, создайте opaque Secret с ключами username и password (имя и ключи должны совпасть с values):

kubectl create secret generic scanner-registry-credentials \
  --namespace="${RELEASE_NAMESPACE}" \
  --from-literal=username='<registry-username>' \
  --from-literal=password='<registry-password>'

1. Включите dynamic mode в values:

vOrchestration:
  scannerRegistry:
    dynamicSecrets:
      enabled: true
      createSA: true
    secretsKeyRefs:
      username:
        name: scanner-registry-credentials
        key: username
      password:
        name: scanner-registry-credentials
        key: password

createSA: false используйте только если ServiceAccount <release>-v-orchestration-registry-sa и Role/RoleBinding уже созданы вручную с нужными правами на Secret в namespace.

1. Установите или обновите релиз с этим override (helm upgrade --install).

Не включайте dynamic mode, если политика безопасности разрешает только статические pull Secret, созданные оператором заранее.