Интеграция с CI/CD

Kaspersky Security для контейнеров позволяет проводить сканирование образов контейнеров и IaC, размещенных в системах управления репозиториями кода в рамках

На этапе сборки проекта в системе управления репозиториями можно запустить сканер Kaspersky Security для контейнеров для проверки содержащихся в репозитории объектов на соответствие требованиям включенных политик безопасности. Сканер запускается из реестра с помощью агента, например, GitLab Runner в GitLab. Данные о задании для сканирования и направлении результатов сканирования передаются посредством программного интерфейса приложения (API).

При запуске проверки объектов на этапе сборки проекта необходимо убедиться, что в настройках применимой политики безопасности образов не выбрано Блокировать этап CI/CD. Если эта настройка активирована, решение уведомит вас об ошибке при сканировании.

Результаты сканирования отображаются в таблице в разделе Ресурсы → CI/CD → Сканирование в CI/CD.

Для каждого из представленных в таблице объектов Kaspersky Security для контейнеров отображает следующее:

• Дату и время последнего сканирования.
• Название.
• Оценку уровня риска.
• Обобщенные результаты сканирования с указанием выявленных объектов, относящимся к уязвимостям, вредоносному ПО, конфиденциальным данным и ошибкам конфигурации.
• Тип артефакта.
• Номер и пайплайн сборки, в которой проводилось сканирование образа.

В разделе Ресурсы → CI/CD → Сканирование в CI/CD вы также можете сформировать отчет по образам, которые сканируются в рамках процесса CI/CD.

Отчеты формируются только для объектов с типом артефакта Образ. Для других типов артефактов формирование отчета недоступно.

Проверка артефактов в процессах CI/CD

С помощью решения вы можете сканировать образы, которые используются в процессах CI/CD. Для проверки образов из CI/CD вам требуется настроить интеграцию решения с процессами CI/CD.

Между средой CI/CD и решением должна быть обеспечена безопасность передачи данных от прослушивания и перехвата сетевого трафика.

Чтобы выполнять проверку образов или репозиториев (для сканирования конфигурационных файлов), используемых в процессе CI/CD, вам нужно добавить в пайплайн CI/CD отдельный этап, на котором запускается сканер Kaspersky Security для контейнеров.

Для проведения сканирования образов из CI/CD в конфигурационном файле интеграции с репозиторием сканеру требуется указать переменные окружения API_BASE_URL (веб-адрес хост-сервера API Kaspersky Security для контейнеров) и API_TOKEN (токен для доступа к API Kaspersky Security для контейнеров). Также необходимо указать API_CA_CERT (сертификат для проверки хост-сервера API решения) или SKIP_API_SERVER_VALIDATION=true для пропуска такой проверки.

Результаты сканирования передаются на сервер и отображаются в консоли управления в разделе Ресурсы → CI/CD. В представленной таблице перечислены образы, для которых проводилась проверка, указываются результаты оценки риска и выявленные уязвимости.

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

Kaspersky Security для контейнеров также отображает тип артефакта для каждого объекта. Используются два основных артефакта:

• Файловая система – это репозиторий с содержащимися в нем конфигурационными файлами.
• Образ контейнера – это шаблон, на основе которого реализуется контейнер в среде выполнения.

Для каждого объекта проверки можно указывать номер сборки (BUILD_NUMBER) и

Для образов из CI/CD недоступно повторное сканирование.

В Kaspersky Security для контейнеров осуществляются следующие виды сканирования в CI/CD:

• Сканирование образов из реестра образов. Решение осуществляет проверку после успешной сборки и сохранения образа в реестр образов.
• Сканирование образов, помещенных в архивы в формате TAR. Созданный TAR-архив сохраняется как артефакт сборки, который сканер решения проверяет в следующем пайплайне сборки.
• Сканирование Git-репозитория, которое может проводиться одним из следующих способов:
  • по ветке (отдельному направлению разработки) проекта в Git-репозитории;
  • по коммиту (снимку состояния или контрольной точке на временной шкале проекта).

Чтобы провести сканирование образа из реестра образов,

выполните команду запуска сканирования в следующем формате:

/scanner [TARGET] --stdout

где:

• <TARGET> – полный адрес образа в реестре;
• <--stdout> – вывод данных в журнал событий безопасности.

Для доступа к реестру необходимо установить в переменных окружения логин COMPANY_EXT_REGISTRY_USERNAME и пароль (токен) COMPANY_EXT_REGISTRY_PASSWORD.
Для использования сертификата для безопасного подключения к реестру необходимо указать данные сертификата в переменной окружения COMPANY_EXT_REGISTRY_TLS_CERT в виде следующей строки в формате .PEM: -----BEGIN CERTIFICATE-----\n... <данные сертификата> ...\n-----END CERTIFICATE-----.

Примеры сканирования образов в GitLab CI/CD и Jenkins CI/CD.

Чтобы провести сканирование образа из TAR-архива:

1. Соберите образ и сохраните его в виде TAR-архива с помощью любого приложения для создания контейнеризированных образов.
2. Выполните команду запуска сканирования в следующем формате:

   /scanner [TARGET] --file --stdout

   где:

   • <TARGET> – путь к файлу образа для сканирования;
   • <--file> – флаг, указывающий на сканирование файла TARGET;
   • <--stdout> – вывод данных в журнал событий безопасности.

   Пример конфигурационного файла со значениями параметров для сканирования TAR-архива

   stages:

   - build_tar

   - scan_tar

   - push_image

   build_tar:

   stage: build_tar

   tags:

   - k8s

   - docker

   image:

   name: gcr.io/kaniko-project/executor:v1.9.0-debug

   entrypoint: [""]

   dependencies:

   - scan_source_branch

   - scan_source_commit

   script:

   - mkdir -p /kaniko/.docker

   - echo "${DOCKER_AUTH_CONFIG}" > /kaniko/.docker/config.json

   - /kaniko/executor

   --context "${CI_PROJECT_DIR}"

   --dockerfile "${CI_PROJECT_DIR}/Dockerfile"

   --destination "${CI_REGISTRY_IMAGE}:${CI_COMMIT_REF_NAME}"

   --compressed-caching=false

   --build-arg GITLAB_USER=gitlab-ci-token

   --build-arg GITLAB_TOKEN=${CI_JOB_TOKEN}

   --no-push

   --tarPath=image.tar

   artifacts:

   paths:

   - image.tar

   expire_in: 2 hours

   scan_tar:

   stage: scan_tar

   tags:

   - k8s

   - docker

   dependencies:

   - build_tar

   image:

   name: "company.gitlab.cloud.net:5050/companydev/example/scanner:master-with-db"

   pull_policy: always

   entrypoint: [""]

   variables:

   API_BASE_URL: ${API_BASE_URL}

   API_TOKEN: ${API_TOKEN}

   API_CA_CERT: ${KCS_CA_CERT}

   script:

   - /scanner image.tar --file --stdout

   artifacts:

   paths:

   - image.tar

   expire_in: 2 hours

   push_image:

   stage: push_image

   tags:

   - k8s

   image:

   name: gcr.io/go-containerregistry/crane:debug

   entrypoint: [""]

   dependencies:

   - scan_tar

   script:

   - mkdir -p $HOME/.docker

   - echo "${DOCKER_AUTH_CONFIG}" > $HOME/.docker/config.json

   - /ko-app/crane push image.tar "${CI_REGISTRY_IMAGE}:${CI_COMMIT_REF_NAME}"

Чтобы провести сканирование Git-репозитория:

1. В конфигурационном файле Git-репозитория в переменных окружения укажите токен для доступа к репозиторию (GITHUB_TOKEN или GITLAB_TOKEN).
2. Выполните команду запуска сканирования в следующем формате:

   /scanner [TARGET] --repo [--branch BRANCH] [--commit COMMIT] --stdout

   где:

   • <TARGET> – веб-адрес (URL) Git-репозитория;
   • <--repo> – флаг, указывающий на сканирование файла TARGET;
   • <--branch BRANCH> – ветка репозитория для сканирования;
   • <--commit COMMIT> – хеш коммита для сканирования;
   • <--stdout> – вывод данных в журнал событий безопасности.

   Пример конфигурационного файла с переменными окружения для сканирования образа из Git-репозитория

   stages:

   - scan_source_branch

   - scan_source_commit

   scan_source_branch:

   stage: scan_source_branch

   image:

   name: "company.gitlab.cloud.net:5050/companydev/example/scanner:master-with-db"

   pull_policy: always

   entrypoint: [""]

   tags:

   - k8s

   - docker

   variables:

   API_BASE_URL: ${API_BASE_URL}

   API_TOKEN: ${API_TOKEN}

   API_CA_CERT: ${KCS_CA_CERT}

   script:

   - GITLAB_TOKEN=${CI_JOB_TOKEN} /scanner --repo ${CI_REPOSITORY_URL} --branch ${CI_COMMIT_BRANCH} --stdout

   scan_source_commit:

   stage: scan_source_commit

   image:

   name: "company.gitlab.cloud.net:5050/companydev/example/scanner:master-with-db"

   pull_policy: always

   entrypoint: [""]

   tags:

   - k8s

   - docker

   variables:

   API_BASE_URL: ${API_BASE_URL}

   API_TOKEN: ${API_TOKEN}

   API_CA_CERT: ${KCS_CA_CERT}

   script:

   - GITLAB_TOKEN=${CI_JOB_TOKEN} /scanner --repo ${CI_REPOSITORY_URL} --commit ${CI_COMMIT_SHA} --stdout

Для сканирования файловой системы

Чтобы провести сканирование файловой системы,

выполните команду запуска сканирования в следующем формате:

/scanner [TARGET] --sources --stdout

где:

• <TARGET>– путь к папке с файлами для сканирования;
• <--sources> – флаг, указывающий на необходимость проверки файлов, расположенных в файловой системе;
• <--stdout> – вывод данных в журнал событий безопасности.

Пример конфигурационного файла с переменными окружения для сканирования файлов в файловой системе

Результаты сканирования можно посмотреть в разделе Ресурсы → CI/CD, а также получить в форматах .SPDX, .JSON и .HTML.

Настройка интеграции с GitLab CI/CD

В этом примере используется специальный образ сканера со встроенными базами данных уязвимостей, размещенный в реестре образов производителя решения.

Для использования возможности сканирования образов в процессе GitLab CI/CD вам нужно включить использование GitLab Container Registry.

Настройка интеграции состоит из следующих этапов:

1. Авторизация GitLab CI/CD в реестре образов производителя Kaspersky Security для контейнеров.
   1. На рабочей станции оператора кластера подготовьте хеш по алгоритму Base64 от авторизационных данных, выполнив команду:

      printf "login:password" | openssl base64 -A

      где login и password – имя и пароль учетной записи в реестре образов производителя Kaspersky Security для контейнеров.

   2. В переменных окружения GitLab CI/CD создайте переменную DOCKER_AUTH_CONFIG (в GitLab репозитории выберите Settings -> CI/CD, нажмите на кнопку Expand, чтобы развернуть блок Variables, затем нажмите на кнопку Add variable).
   3. Укажите содержимое переменной в следующем виде:

      {

      "auths": {

      "repo.cloud.example.com": {

      "auth": "base64hash"

      }

      }

      }

      где base64hash – строка, полученная на этапе 1a.

2. Авторизация запросов из GitLab CI/CD при отправке данных в Kaspersky Security для контейнеров.
   1. Скопируйте токен API на странице Мой профиль.
   2. Укажите скопированное значение токена API в переменной API_TOKEN в конфигурационном файле .gitlab-ci.yml.
3. Добавление этапа сканирования образов в процесс CI/CD.

   Чтобы добавить этап сканирования в пайплайн CI/CD, необходимо добавить в файл .gitlab-ci.yml следующие строки:

   1. Добавьте информацию по образу сканера, содержащего базы уязвимостей и других вредоносных объектов, после этапа сборки кода в следующем виде:

      scan_image:

      stage: scanner

      image:

      name: repo.cloud.example.com/repository/company/scanner:v2.0-with-db

      entrypoint: [""]

      pull_policy: always

      Мы рекомендуем указывать always для параметра pull_policy, чтобы получать свежие сборки с обновленными базами уязвимостей и других вредоносных объектов при каждом сканировании.

   2. Укажите тег, идентификатор сборки, идентификатор пайплайна и токен API для авторизации запросов от CI/CD сканера в Kaspersky Security для контейнеров в следующем виде:

      SCAN_TARGET: ${CI_REGISTRY_IMAGE}:master

      BUILD_NUMBER: ${CI_JOB_ID}

      BUILD_PIPELINE: ${CI_PIPELINE_ID}

      API_TOKEN: <значение токена API>

      В приведенном примере указан тег master, вы можете указать другой тег.

   3. Если вы настраиваете сканирование для приватного репозитория, для доступа сканера к образу укажите авторизационные данные. Их можно задать в виде переменных.

      COMPANY_EXT_REGISTRY_USERNAME: ${COMPANY_EXT_REGISTRY_USERNAME}

      COMPANY_EXT_REGISTRY_PASSWORD: ${COMPANY_EXT_REGISTRY_PASSWORD}

   4. Для использования сертификата для безопасного подключения к реестру укажите данные сертификата в переменной окружения COMPANY_EXT_REGISTRY_TLS_CERT в виде строки в формате .PEM:

      -----BEGIN CERTIFICATE-----\n... <данные сертификата> ...\n-----END CERTIFICATE-----.

   5. Укажите следующие параметры, обеспечивающие взаимодействие через прокси-сервер:

      HTTP_PROXY: <прокси-сервер для запросов по протоколу HTTP>

      HTTPS_PROXY: <прокси-сервер для запросов по протоколу HTTPS>

      NO_PROXY: <домены или соответствующие им маски для исключения из проксирования>

   6. При необходимости укажите переменную для проверки сервера приема данных в CI/CD с помощью СА-сертификата Ingress-контроллера:

      API_CA_CERT: ${KCS_CA_CERT}

      СА-сертификат Ingress-контроллера указывается в текстовом поле в виде строки в формате .PEM:

      -----BEGIN CERTIFICATE-----\n... <данные сертификата> ...\n-----END CERTIFICATE-----

      Если переменная API_CA_CERT не задана, проверка будет запускаться, но не будет пройдена.

      Использование СА-сертификата Ingress-контроллера позволяет запускаемому в CI/CD сканеру убедиться в подлинности сервера приема данных.

      Если вы используете самоподписанный сертификат или специально хотите пропустить проверку сервера приема данных с помощью СА-сертификата Ingress-контроллера, укажите значение переменной для пропуска проверки следующим образом:

      SKIP_API_SERVER_VALIDATION: 'true'

   7. Укажите веб-адрес хост-сервера API Kaspersky Security для контейнеров:

      API_BASE_URL: <веб-адрес>

      variables:

      API_BASE_URL: ${API_BASE_URL}

      script:

      - /bin/sh /entrypoint.sh $SCAN_TARGET --stdout > artifact-result.json

      artifacts:

      paths:

      - artifact-result.json

После настройки интеграции с внешним реестром вы можете проводить сканирование образов в процессе CI/CD, в том числе осуществлять сканирование в режиме SBOM. Результаты сканирования можно посмотреть в разделе Ресурсы → CI/CD, а также получить в форматах .SPDX, .JSON и .HTML.

Настройка интеграции с Jenkins CI/CD

Настройка интеграции с Jenkins CI/CD состоит из следующих этапов:

1. Авторизация Jenkins CI/CD в реестре образов производителя Kaspersky Security для контейнеров. Для этого на рабочей станции оператора кластера подготовьте хеш по алгоритму Base64 от авторизационных данных, выполнив команду:

   printf "login:password" | openssl base64 -A

   где login и password – имя и пароль учетной записи в реестре образов производителя Kaspersky Security для контейнеров.

2. Авторизация API Kaspersky Security для контейнеров. Для авторизации требуется выполнить следующие действия:
   1. Скопируйте токен API на странице Мой профиль.
   2. Укажите скопированное значение токена API в переменной API_TOKEN в конфигурационном файле Jenkinsfile.
3. Проверка подлинности сервера приема данных в CI/CD с помощью СА-сертификата Ingress-контроллера. Для проведения проверки в конфигурационном файле Jenkinsfile укажите одну из следующих переменных:
   1. -e API_CA_CERT=${KCS_CA_CERT} – проверка будет проведена, и запускаемый в CI/CD сканер сможет убедиться в подлинности сервера приема данных.
   2. -e SKIP_API_SERVER_VALIDATION=true – проверка сервера приема данных с помощью СА-сертификата Ingress-контроллера проводиться не будет.
4. Создание переменных окружения Jenkins.

   Чтобы создать переменные окружения, необходимо добавить в файл Jenkinsfile следующие строки:

   1. Добавьте информацию по реестру контейнеров, где находится сканер в следующем виде:

      LOGIN – имя учетной записи в реестре сканера

      PASS – пароль для реестра сканера

   2. Если вы настраиваете сканирование для приватного репозитория, для доступа сканера к образу укажите следующие авторизационные данные:

      COMPANY_EXT_REGISTRY_USERNAME – имя учетной записи в реестре сканируемого образа

      COMPANY_EXT_REGISTRY_PASSWORD – пароль для реестра сканируемого образа

   3. Для использования сертификата для безопасного подключения к реестру укажите данные сертификата в переменной окружения COMPANY_EXT_REGISTRY_TLS_CERT в виде строки в формате .PEM:

      -----BEGIN CERTIFICATE-----\n... <данные сертификата> ...\n-----END CERTIFICATE-----.

   4. Укажите значения следующих переменных, обеспечивающих взаимодействие через прокси-сервер:

      HTTP_PROXY: <прокси-сервер для запросов по протоколу HTTP>

      HTTPS_PROXY: <прокси-сервер для запросов по протоколу HTTPS>

      NO_PROXY: <домены или соответствующие им маски для исключения из проксирования>

5. Добавление информации для запуска сканера. Информация для запуска сканера, содержащего базы уязвимостей и других вредоносных объектов, добавляется в конфигурационный файл Jenkinsfile в виде декларативного или скриптового пайплайна.

   Пример информации для запуска сканера в виде декларативного пайплайна

   pipeline {

   agent any

   stages {

   stage('run scanner') {

   steps {

   sh 'docker login -u ${LOGIN} -p ${PASS} company.example.com'

   sh 'docker run -e API_BASE_URL=https://kcs.cust02.int.example.com/ -e SKIP_API_SERVER_VALIDATION=true -e API_TOKEN=${API_TOKEN} -e COMPANY_EXT_REGISTRY_USERNAME=${COMPANY_EXT_REGISTRY_USERNAME} -e COMPANY_EXT_REGISTRY_PASSWORD=${COMPANY_EXT_REGISTRY_PASSWORD} company.example.com:5050/company/kcs/scanner:v2.0.0-with-db jfrog.company.com/demo-kcs/bad:bad-project-test --html --stdout > result.html'

   }

   }

   }

   }

   Пример информации для запуска сканера в виде скриптового пайплайна

   node {

   stage ('run scanner') {

   sh 'docker login -u ${LOGIN} -p ${PASS} company.example.com'

   sh 'docker run -e API_BASE_URL=https://kcs.cust02.int.company.com/ -e API_CA_CERT=${KCS_CA_CERT} -e API_TOKEN=${API_TOKEN} -e COMPANY_EXT_REGISTRY_USERNAME=${COMPANY_EXT_REGISTRY_USERNAME} -e COMPANY_EXT_REGISTRY_PASSWORD=${COMPANY_EXT_REGISTRY_PASSWORD} company.example.com:5050/company/kcs/scanner:v2.0.0-with-db jfrog.company.com/demo-kcs/bad:bad-project-test --html --stdout > result.html'

   }

   }

6. Формирование артефакта для скачивания.

   Для получения результатов сканирования вы можете сформировать артефакт для скачивания в формате .HTML или .JSON. Формат артефакта вы можете указать в строке --stdout, например:

   pipeline {

   agent any

   stages {

   stage('run scanner') {

   steps {

   sh 'docker login -u ${LOGIN} -p ${PASS} company.example.com'

   sh 'docker run -e API_BASE_URL=https://kcs.int.company.com -e SKIP_API_SERVER_VALIDATION=true -e API_TOKEN=${API_TOKEN} -e COMPANY_EXT_REGISTRY_USERNAME=${COMPANY_EXT_REGISTRY_USERNAME} -e COMPANY_EXT_REGISTRY_PASSWORD=${COMPANY_EXT_REGISTRY_PASSWORD} company.example.com:5050/company/kcs/scanner:v2.0.1-lite jfrog.company.com/demo-kcs/bad:bad-project-test --html --stdout > result.html'

   }

   }

   stage('archive') {

   steps {

   archiveArtifacts artifacts: 'result.html'

   }

   }

   }

   }

   Если необходимо сформировать артефакт в формате .JSON, строку --html --stdout > result.html'из приведенного выше примера требуется указать следующим образом:

   --stdout > result.json',

   и в строке archiveArtifacts artifacts: необходимо указать название файла в заданном вами формате: 'result.json'.

   Результаты сканирования можно получить в указанном вами формате, а также посмотреть в разделе Ресурсы → CI/CD.

Настройка интеграции с TeamCity CI/CD

Чтобы настроить интеграцию с TeamCity CI/CD:

1. Скопируйте токен API на странице Мой профиль для авторизации API Kaspersky Security для контейнеров в TeamCity.
2. В меню настройки параметров в веб-интерфейсе TeamCity выберите Build Configuration Home → Parameters.
3. С помощью кнопки Add new parameters добавьте значения следующих переменных окружения:
   • API_TOKEN – укажите скопированное значение токена API Kaspersky Security для контейнеров.
   • API_BASE_URL – укажите URL Kaspersky Security для контейнеров.
   • RUST_BACKTRACE – при необходимости укажите значение full для использования обратной трассировки.
   • SKIP_API_SERVER_VALIDATION – укажите значение true, если используется самоподписанный сертификат или необходимо пропустить проверку сервера приема данных с помощью СА-сертификата Ingress-контроллера.
   • COMPANY_EXT_REGISTRY_USERNAME – укажите имя учетной записи в реестре сканируемого образа.
   • COMPANY_EXT_REGISTRY_PASSWORD – укажите пароль для реестра сканируемого образа.
   • COMPANY_EXT_REGISTRY_TLS_CERT – укажите данные сертификата для безопасного подключения к реестру.

     Данные сертификата указываются в виде строки в формате .PEM:
     -----BEGIN CERTIFICATE-----\n... <данные сертификата> ...\n-----END CERTIFICATE-----.

   • HTTP_PROXY – указывается прокси-сервер для запросов по протоколу HTTP.
   • HTTPS_PROXY – указывается прокси-сервер для запросов по протоколу HTTPS.
   • NO_PROXY – указываются домены или соответствующие им маски для исключения из проксирования.
4. Перейдите в раздел Build Configuration Home → Build Step: Command Line и с помощью кнопки Add build step добавьте этап сборки.
5. В открывшемся окне укажите следующие параметры этапа сборки:
   • В раскрывающемся списке Runner type выберите Command Line.
   • В раскрывающемся списке Run выберите Custom script.
   • В поле Custom script укажите путь к контейнеру для сканирования (например, /bin/sh /entrypoint.sh nginx:latest).
6. В блоке Docker Settings укажите следующие параметры:
   • В поле Run step within Docker container укажите адрес сканера в реестре Docker. Например, company.gitlab.cloud.net:5050/companydev/example/scanner:v2.0.0-with-db.
   • В поле Additional docker run arguments повысьте значение привилегий до --privileged.
7. Нажмите на кнопку Save, чтобы сохранить параметры.
8. Нажмите на кнопку Run в верхнем правом углу страницы, чтобы запустить сборку.
9. При необходимости скачайте артефакт с результатами сканирования, который доступен на вкладке Artifacts на странице с результатами проверки сборки в веб-интерфейсе TeamCity.

Определение пути до образов контейнеров

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

• За названием реестра, репозитория и имени образа указывается тег образа. Тег представляет собой изменяемое легкочитаемое описание образа.

  Путь в этом случае выглядит следующим образом: <реестр>/<репозиторий>/<имя образа>:<тег>. Например, http://docker.io/library/nginx:1.20.1.

• За названием реестра, репозитория и имени образа указывается контрольная сумма образа. Контрольная сумма является неизменным внутренним свойством образа, а именно хешем его содержимого (используется хеш-алгоритм SHA256).

  При использовании контрольной суммы путь представляет собой следующее: <реестр>/<репозиторий>/<имя образа><контрольная сумма>. Например, http://docker.io/library/nginx@sha256:af9c...69ce.

Тег может соответствовать различным контрольным суммам, а контрольные суммы уникальны для каждого образа.

В зависимости от способа указания пути до образа перед началом сканирования Kaspersky Security для контейнеров осуществляет одно из следующих действий:

• Преобразовывает тег в доверенную контрольную сумму.
• Проверяет, является ли указанная в пути до образа контрольная сумма доверенной. Контрольная сумма считается доверенной, если обеспечена необходимая степень уверенности в поддержании требуемого режима безопасности в отношении кодируемого с помощью хеш-алгоритма объекта.

В среду выполнения контейнера передаются только доверенные контрольные суммы.

Перед запуском контейнера содержимое образа сравнивается с полученной контрольной суммой. Для признания контрольной суммы доверенной, а образа неискаженным Kaspersky Security для контейнеров проверяет целостность и подлинность подписи образа.

Контроль целостности и происхождения образов

При сканировании образов в процессе CI/CD Kaspersky Security для контейнеров обеспечивает защиту от подмены образов на уровне реестров. Целостность и происхождение образов контейнеров, развертываемых в кластере оркестратора, контролируется при помощи проверки подписей образов, начиная с уровня сборки в CI.

Контроль целостности образов осуществляется в два этапа:

• Подписание образов контейнеров после создания. Этот процесс реализуется при помощи внешних приложений для подписи.
• Проверка подписей образов перед развертыванием.

  Решение сохраняет ключ подписи, который создается на основе хеш-функции SHA-256 и используется в качестве кода проверки подлинности подписи. При развертывании в оркестраторе Kaspersky Security для контейнеров запрашивает у сервера подписей подтверждение подлинности подписи.

Kaspersky Security для контейнеров осуществляет проверку подписей образа в рамках следующего процесса:

1. В разделе Администрирование → Интеграции → Модули проверки подписей образов настраиваются параметры интеграции решения с внешними модулями проверки подписей.
2. В разделе Политики → Среда выполнения → Политики создается политика среды выполнения для защиты содержания образа, которая отвечает за проверку подлинности подписей. Проверка цифровых подписей осуществляется на основе настроенных модулей проверки подписей.
3. Оркестратор запускает развертывание образа и при помощи
   динамического контроллера доступа

   Настраиваемый контроллер для доступа в Kubernetes, который помогает применять политики и поддерживает систему управления и контроля.

   делает запрос на развертывание агенту (kube-agent).

   Для направления запроса агенту Kaspersky Security для контейнеров требуется настроить динамический контроллер доступа в конфигурационном файле values.yaml.

4. На основании применимой политики среды выполнения агент проверяет параметры проверки подписи, настроенные в разделе Администрирование → Интеграции → Модули проверки подписей образов.
5. Если проверка подтверждает подлинность и действительность подписи, решение разрешает развертывание образа. В ином случае развертывание запрещается.

Запуск сканера в режиме SBOM

Kaspersky Security для контейнеров поддерживает возможность запуска сканера для проверки образов на наличие уязвимостей в режиме

Преимущества использования SBOM включают в себя:

• Меньший объем ресурсов, необходимых для сканирования образов на уязвимости.
• Экономия времени на сканирование за счет автоматической проверки корректности использования и функционирования компонентов решения.
• Возможность сканирования всех имеющихся в образе уязвимостей без исключения.
• Большая надежность получаемых результатов сканирования.

В рамках работы в CI/CD процесс сканирования состоит из двух этапов: получение SBOM-файла и последующее сканирование образа с использованием полученной спецификации программного обеспечения. Процесс сканирования образов реализуется следующим образом:

• Сканер в CI/CD формирует перечень компонентов образа и направляет сгенерированный артефакт в Kaspersky Security для контейнеров.
• При помощи приложения для обработки заданий на сканирование решение передает принятый SBOM-файл в сканер для сканирования.

  Для сканирования в режиме SBOM Kaspersky Security для контейнеров запускает сканер с предустановленными базами уязвимостей и других вредоносных объектов (scanner:v2.0-with-db, scanner:v2.0-with-db-java).

Для сканирования образов в CI/CD в файле требуется указать значения следующих переменных окружения:

• API_TOKEN – указывается значение токена API Kaspersky Security для контейнеров.
• API_BASE_URL – указывается URL Kaspersky Security для контейнеров.
• API_CA_CERT – указывается СА-сертификат Ingress-контроллера, что позволяет запускаемому в CI/CD сканеру убедиться в подлинности сервера приема данных. Если вы используете самоподписанный сертификат или специально хотите пропустить проверку сервера приема данных с помощью СА-сертификата Ingress-контроллера, значение переменной для пропуска проверки указывается следующим образом:

  SKIP_API_SERVER_VALIDATION: 'true'

• COMPANY_EXT_REGISTRY_USERNAME – указывается имя учетной записи в реестре сканируемого образа.
• COMPANY_EXT_REGISTRY_PASSWORD – указывается пароль для реестра сканируемого образа.
• COMPANY_EXT_REGISTRY_TLS_CERT – указываются данные сертификата для безопасного подключения к реестру.

  Данные сертификата указываются в виде строки в формате .PEM:
  -----BEGIN CERTIFICATE-----\n... <данные сертификата> ...\n-----END CERTIFICATE-----.

• HTTP_PROXY – указывается прокси-сервер для запросов по протоколу HTTP.
• HTTPS_PROXY – указывается прокси-сервер для запросов по протоколу HTTPS.
• NO_PROXY – указываются домены или соответствующие им маски для исключения из проксирования.

Для последующего сканирования Kaspersky Security для контейнеров генерирует файл отчета в формате .JSON. Также вы можете сформировать артефакт c SBOM для скачивания в рамках процесса CI/CD в формате

Чтобы сгенерировать SBOM-файл в формате .SPDX при работе сканера через создание SBOM,

в конфигурационном файле .gitlab-ci.yml укажите следующую команду:

- /bin/sh /entrypoint.sh $SCAN_TARGET --sbom --spdx --stdout > example.spdx

где:

<--sbom> – индикатор создания SBOM-файла;

<--spdx> – указание на сборку артефакта в формате .SPDX;

<--stdout > example.spdx> – индикатор вывода данных в файл в формате .SPDX.

Чтобы сгенерировать SBOM-файл в формате .СDX при работе сканера через создание SBOM,

в конфигурационном файле .gitlab-ci.yml укажите следующую команду:

- /bin/sh /entrypoint.sh $SCAN_TARGET --sbom --cdx --stdout > example.cdx.json

где:

<--sbom> – индикатор создания SBOM-файла;

<--cdx> – указание на сборку артефакта в формате .CDX

<--stdout > example.cdx.json> – индикатор вывода данных в файл в формате .JSON.

Полученный при этом файл (например, example.cdx.json) указывается как артефакт: artifacts: paths:

Сканирование при помощи создания SBOM-файла относится только к проверке образа на наличие уязвимостей. Если в процессе CI/CD требуется провести сканирование на другие риски и угрозы (например, на наличие ошибок конфигурации), требуется отдельно запускать соответствующее сканирование и добавлять полученные результаты в приложение для обработки заданий на сканирование в дополнение к SBOM-файлу.

Запуск сканера в режиме lite SBOM

Kaspersky Security для контейнеров предоставляет возможность запуска сканера для проверки образов на наличие уязвимостей в режиме lite SBOM. В данном случае решение осуществляет сканирование специально созданного SBOM-файла, а результаты этого сканирования становятся доступны на этапе CI/CD.

Между средой CI/CD и решением должна быть обеспечена безопасность передачи данных от прослушивания и перехвата сетевого трафика.

Для получения результатов вы можете сформировать артефакт для скачивания в формате .SPDX, .HTML, .JSON или .CDX.

Результаты сканирования можно получить в указанном вами формате, а также посмотреть в разделе Ресурсы → CI/CD.

Запуск сканера в GitLab

Чтобы запустить сканер в режиме lite SBOM в GitLab, при настройке сканирования образов в процессе CI/CD измените конфигурационный файл .gitlab-ci.yml следующим образом:

1. Добавьте информацию по образу сканера, запускаемого на этапе сканирования образов в процессе CI/CD в следующем виде:

   scan_image:

   stage: scanner

   image:

   name:repo.cloud.example.com/repository/company/scanner:v.2.0.0-lite

   entrypoint: [""]

   pull_policy: always

2. Укажите тег платформы оркестрации в следующем виде:

   k8s

   В приведенном примере указан тег k8s для обозначения Kubernetes, вы можете указать тег для другой поддерживаемой платформы оркестрации.

3. Укажите такие переменные как идентификатор сборки, данные реестра сканируемого образа и сертификата для безопасного подключения к этому реестру, идентификатор пайплайна и токен API для авторизации запросов от CI/CD сканера в Kaspersky Security для контейнеров в следующем виде:

   SCAN_TARGET: ${CI_REGISTRY_IMAGE}:master

   COMPANY_EXT_REGISTRY_USERNAME: ${COMPANY_EXT_REGISTRY_USERNAME}

   COMPANY_EXT_REGISTRY_PASSWORD: ${COMPANY_EXT_REGISTRY_PASSWORD}

   COMPANY_EXT_REGISTRY_TLS_CERT: ${COMPANY_EXT_REGISTRY_TLS_CERT}

   BUILD_NUMBER: ${CI_JOB_ID}

   BUILD_PIPELINE: ${CI_PIPELINE_ID}

   API_TOKEN: <значение токена API>

   HTTP_PROXY: <прокси-сервер для запросов по протоколу HTTP>

   HTTPS_PROXY: <прокси-сервер для запросов по протоколу HTTPS>

   NO_PROXY: <домены или соответствующие им маски для исключения из проксирования>

   Данные сертификата для безопасного подключения к реестру сканируемого образа в переменной COMPANY_EXT_REGISTRY_TLS_CERT указываются в виде строки в формате .PEM:
   -----BEGIN CERTIFICATE-----\n... <данные сертификата> ...\n-----END CERTIFICATE-----.

4. При необходимости укажите переменную для проверки сертификата API-интерфейса решения:

   API_CA_CERT: ${KCS_CA_CERT}

   Если переменная API_CA_CERT не задана, проверка будет запускаться, но не будет пройдена.

5. Укажите веб-адрес хост-сервера API Kaspersky Security для контейнеров:

   API_BASE_URL: <веб-адрес>

6. Укажите команду для создания файла артефакта при запуске сканера в одном из следующих поддерживаемых форматов:
   • Для создания артефакта в формате .JSON:

     script:

     - /bin/sh /entrypoint.sh $SCAN_TARGET --stdout > artifact-result.json

     artifacts:

     paths:

     - artifact-result.json

   • Для создания артефакта в формате .HTML:

     script:

     - /bin/sh /entrypoint.sh $SCAN_TARGET --html --stdout > artifact-result.html

     artifacts:

     paths:

     - artifact-result.html

   • Для создания артефакта SBOM в формате .SPDX:

     script:

     - /bin/sh /entrypoint.sh $SCAN_TARGET --spdx --stdout > artifact-result.spdx

     artifacts:

     paths:

     - artifact-result.spdx

   • Для создания артефакта SBOM в формате .CDX:

     script:

     - /bin/sh /entrypoint.sh $SCAN_TARGET --cdx --stdout > artifact-result.cdx.json

     artifacts:

     paths:

     - artifact-result.cdx.json

Пример настройки запуска сканера в режиме lite SBOM и создания артефакта в формате .HTML в GitLab

Запуск вне процесса CI/CD

В случае ограниченных ресурсов, вы можете запускать сканер Kaspersky Security для контейнеров отдельно от вычислительных узлов процесса CI/CD. Например, на Docker-узле с помощью команды docker run или в виде объекта Job в кластере Kubernetes.

Для максимальной экономии ресурсов мы рекомендуем использовать образ scanner:2.0.0-lite, так как он не содержит баз уязвимостей и отправляет сформированный по результатам проверки целевого образа SBOM-файл на анализ в решение с помощью API.

Для запуска сканера Kaspersky Security для контейнеров вне процесса CI/CD необходимо указать следующие обязательные параметры:

• API_TOKEN: <значение токена API> – токен пользователя Kaspersky Security для контейнеров для аутентификации в API-интерфейсе решения.
• API_BASE_URL: <веб-адрес> – ссылка для доступа к API-интерфейсу Kaspersky Security для контейнеров. Доступ может осуществляться по протоколам HTTP и HTTPS, в зависимости от настроек окружения развернутого решения.
• API_CA_CERT: <сертификат в формате PEM> – переменная для проверки сертификата API-интерфейса решения.
• SKIP_API_SERVER_VALIDATION=true – переменная, которую при необходимости можно указать для пропуска проверки сертификата API-интерфейса Kaspersky Security для контейнеров.

Вы также можете указать дополнительные параметры для работы сканера:

• COMPANY_EXT_REGISTRY_USERNAME: <имя пользователя реестра> – имя пользователя реестра, где хранится образ для проверки сканером.
• COMPANY_EXT_REGISTRY_PASSWORD: <пароль пользователя реестра> – пароль пользователя реестра, где хранится образ для проверки сканером.
• BUILD_NUMBER: <идентификатор номера сборки> – идентификатор, который используется для отслеживания номера сборки в интерфейсе решения. Kaspersky Security для контейнеров отображает номер в результатах проверки в процессе CI\CD.
• BUILD_PIPELINE: <идентификатор номера пайплайна> – идентификатор, который используется для отслеживания номера пайплайна в интерфейсе решения. Kaspersky Security для контейнеров отображает номер в результатах проверки в процессе CI\CD.
• HTTP_PROXY: <прокси-сервер для запросов по протоколу HTTP> – переменная, которая указывает на использование HTTP-прокси сервера, когда вам требуется доступ к внешним ресурсам.
• HTTPS_PROXY: <прокси-сервер для запросов по протоколу HTTPS> – переменная, которая указывает на использование HTTPS- прокси когда вам требуется доступ к внешним ресурсам.
• NO_PROXY: <домены или соответствующие им маски для исключения из проксирования> – переменная, которая указывает на доступные локально ресурсы, если используется прокси-сервер.

Запуск сканера в Docker

Запуск сканера как объекта Job в кластере Kubernetes

Получение результатов сканирования в форматах .JSON и .HTML

При использовании Kaspersky Security для контейнеров для сканирования образов в рамках процесса CI/CD вы можете сформировать и сохранить артефакт с результатами сканирования внутри платформы CI/CD. Это может быть сделано с помощью конфигурационного файла внешней системы репозиториев, с которой интегрировано решение. Например, конфигурационного файла .gitlab-ci.yml в GitLab.

Способы формирования артефакта с результатами сканирования:

• При работе сканера с полным сканированием в CI/CD. Файл с результатами сканирования может быть сформирован в форматах .HTML и .JSON.
• При работе сканера через создание SBOM. В этом случае файл с результатами сканирования можно сгенерировать в форматах .SPDX и .JSON.

Чтобы сформировать файл с результатами сканирования в формате .HTML,

в конфигурационном файле .gitlab-ci.yml укажите следующую команду:

- /bin/sh /entrypoint.sh $SCAN_TARGET --html --stdout > example.html

где:

<--html> – указание на сборку артефакта в формате .HTML;

<--stdout > example.html> – индикатор вывода данных в файл в формате .HTML.

Чтобы сформировать файл с результатами сканирования в формате .JSON при работе сканера с полным сканированием в CI/CD,

в конфигурационном файле .gitlab-ci.yml укажите следующую команду:

- /bin/sh /entrypoint.sh $SCAN_TARGET --stdout > example.json

где:

<--stdout > example.json> – индикатор вывода данных в файл в формате .JSON.

Полученный при этом файл (например, example.json) указывается как артефакт: artifacts: paths:

Указание секретов при запуске сканирования

При запуске задания на сканирование в процессе CI/CD реестр, в котором находится образ сканера (сканер lite или сканер with-db для соответствующей версии Kaspersky Security для контейнеров), может быть доступен только после авторизации. Вы можете пройти авторизацию, указав требуемые секреты в задании на сканирование.

Чтобы пройти авторизацию для доступа в реестр при запуске задания на сканирование:

1. Создайте секрет, выполнив следующую команду:

   kubectl create secret docker-registry ci-creds --docker-server=client.repo.example.com --docker-username=username --docker-password=password

2. В задании на сканирование укажите значение переменной imagePullSecrets следующим образом:

   imagePullSecrets:

   - name: ci-creds

3. Запустите задание на сканирование.

   Пример задания на сканирование с указанием секретов для авторизации

   kind: Job

   metadata:

   name: my-job

   spec:

   template:

   spec:

   containers:

   - name: my-container

   image: client.repo.example.com/scanner:master

   command: ["/bin/sh"]

   args: ["entrypoint.sh", "apline:latest"]

   env:

   - name: COMPANY_EXT_REGISTRY_USERNAME

   value: another_username

   - name: COMPANY_EXT_REGISTRY_PASSWORD

   value: another_password

   - name: API_BASE_URL

   value: https://some.kcs.env.example

   - name: API_TOKEN

   value: kcs_blablabla

   - name: SKIP_API_SERVER_VALIDATION

   value: 'true'

   imagePullPolicy: Always

   restartPolicy: Never

   imagePullSecrets:

   - name: ci-creds

   backoffLimit: 0

В приведенном примере задание на сканирование содержит следующие секреты:

• Секрет для скачивания образа сканера (указан в переменной imagePullSecrets).
• Пароль для скачивания образа для проверки с помощью сканера, если доступ к соответствующему реестру ограничен (указан в переменной COMPANY_EXT_REGISTRY_PASSWORD).

Вы можете не указывать эти пароли, если реестр, к которому обращается решение при выполнении задания на сканирование, доступен без авторизации.