Integración al proceso de CI/CD

Kaspersky Container Security le permite analizar imágenes en contenedores e IaC que residen en sistemas de gestión de repositorios de código en el

Durante la compilación de un proyecto en el sistema de gestión de repositorios, puede ejecutar el componente Kaspersky Container Security Scanner para verificar el cumplimiento de los objetos con las directivas de seguridad activas. Scanner se inicia desde un registro mediante un agente, como GitLab Runner in GitLab. Los datos sobre la tarea de análisis y los resultados del análisis se reenvían mediante una interfaz de programación de aplicaciones (API).

Al analizar un objeto durante la compilación de un proyecto, debe asegurarse de no elegir el paso Fail CI/CD en la configuración de la directiva de certeza aplicada. Si esta configuración está activa, la solución le enviará una notificación del error durante el análisis.

En la sección Inventory → CI/CD → Scanning in CI/CD, podrá ver los resultados del análisis en la lista de imágenes.

Kaspersky Container Security muestra la siguiente información para cada objeto en la tabla:

• Fecha y hora del último análisis.
• Nombre.
• Calificación de riesgo.
• Resumen de los resultados del análisis y objetos identificados con vulnerabilidades, malware, datos confidenciales y configuraciones incorrectas.
• Tipo de artefacto.
• Número y canalización de la compilación donde se analiza la imagen.

En la sección Resources → CI/CD → Scanning in CI/CD, también puede generar un informe de las imágenes que se analizan en un proceso de CI/CD.

Los informes se generan solo para los objetos que tienen el tipo de artefacto Image. En esta sección, no puede generar un informe para otros tipos de artefactos.

Análisis de artefactos en procesos de CI/CD

Kaspersky Container Security le permite analizar imágenes usadas en CI/CD. Para analizar imágenes de CI/CD, debe configurar la integración de Kaspersky Container Security a los procesos de CI/CD.

Los datos al escuchar e interceptar el tráfico de red deben transferirse de forma segura entre el entorno de CI/CD y la solución.

Para analizar los repositorios e imágenes (para realizar el análisis de los archivos de configuración) utilizados en el proceso de CI/CD, debe añadir una fase a la canalización de CI/CD que ejecute Kaspersky Container Security Scanner.

Para analizar imágenes de CI/CD, en el archivo de configuración usado para integrar al repositorio, especifique los valores de las variables de entorno API_BASE_URL (dirección web del servidor de la API de Kaspersky Container Security) y API_TOKEN (token de acceso a la API de Kaspersky Container Security) de Scanner. También debe especificar el valor de API_CA_CERT (certificado que verifica el servidor host de la solución API) o SKIP_API_SERVER_VALIDATION = true para omitir el análisis.

Los resultados del análisis se reenviarán al servidor y se mostrarán en la Consola de administración, en la sección Resources → CI/CD. En la tabla, verá una lista de las imágenes analizadas, los resultados de la calificación de riesgos y las vulnerabilidades detectadas.

Puede hacer clic en el enlace del nombre para abrir una página que contiene información detallada sobre los resultados de los análisis de las imágenes. Esta página es similar a la página que muestra los resultados de los análisis de las imágenes del registro.

Kaspersky Container Security también mostrará el tipo de artefacto de cada objeto. Se utilizan dos artefactos principales:

• El sistema de archivos es el repositorio que contiene los archivos de configuración.
• La imagen de contenedor es la plantilla utilizada para la implementación del contenedor en el entorno de ejecución.

Para cada objeto de análisis, debe especificar el número de compilación (BUILD_NUMBER) y la

En el caso de las imágenes de CI/CD, no es posible volver a hacer un análisis.

Kaspersky Container Security realiza los siguientes tipos de análisis en CI/CD:

• Análisis de imágenes del registro de imágenes. La solución ejecuta un análisis después de que la compilación sea correcta y guarda la imagen en el registro de imágenes.
• Análisis de imágenes de archivos comprimidos TAR. Un archivo comprimido TAR se almacena como el artefacto de compilación que la solución analizará en la siguiente canalización de compilación.
• Análisis de un repositorio de Git, que puede realizarse de las siguientes maneras:
  • para la rama de un proyecto (ruta de desarrollo individual) en el repositorio de Git
  • para un commit (punto de control o captura del estado en la escala de tiempo de un proyecto)

Para analizar una imagen de un registro de imágenes:

Ejecute un comando, con el siguiente formato, para iniciar el análisis:

/scanner [TARGET] --stdout

donde:

• <TARGET> es la dirección completa de la imagen en el registro
• <--stdout> es el servicio de notificaciones para el registro de eventos de seguridad

Para acceder al registro, debe configurar el nombre de usuario COMPANY_EXT_REGISTRY_USERNAME y la contraseña (token) COMPANY_EXT_REGISTRY_PASSWORD en las variables de entorno.
Para usar un certificado y establecer una conexión segura con el registro, debe especificar los datos del certificado en la variable de entorno COMPANY_EXT_REGISTRY_TLS_CERT como la siguiente cadena en el formato .PEM : -----BEGIN CERTIFICATE-----\n... <datos del certificado > ...\n-----END CERTIFICATE----- .

Ejemplos del análisis de imágenes en el CI/CD de GitLab y CI/CD de Jenkins.

Para analizar una imagen de un archivo comprimido TAR:

1. Compile una imagen y guárdela como archivo comprimido TAR con cualquier aplicación para crear imágenes en contenedores.
2. Ejecute un comando, con el siguiente formato, para iniciar el análisis:

   /scanner [TARGET] --file --stdout

   donde:

   • <TARGET> es la ruta al archivo que tiene la imagen que se analizará
   • <--file> es la marca que indica el análisis del archivo TARGET
   • <--stdout> es el servicio de notificaciones para el registro de eventos de seguridad

   Ejemplo de un archivo de configuración con parámetros para analizar un archivo comprimido 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}"

Para analizar el repositorio de Git:

1. En el archivo de configuración del repositorio de Git, en las variables de entorno debe especificar el token para acceder al repositorio (GITHUB_TOKEN o GITLAB_TOKEN).
2. Ejecute un comando, con el siguiente formato, para iniciar el análisis:

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

   donde:

   • <DESTINO> es la dirección web (URL) del repositorio de Git
   • <--repo> es la marca que indica el análisis del archivo TARGET
   • <--branch BRANCH> es la rama del repositorio que se analizará
   • <--commit COMMIT> es el hash del commit que se analizará
   • <--stdout> es el servicio de notificaciones para el registro de eventos de seguridad

   Ejemplo del archivo de configuración con variables de entorno para analizar una imagen de un repositorio 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

Para analizar el sistema de archivos

Pasos para analizar el sistema de archivos:

Ejecute un comando, con el siguiente formato, para iniciar el análisis:

/scanner [TARGET] --sources --stdout

donde:

• <DESTINO> es la ruta a la carpeta del archivo a analizar
• <--sources> es el indicador que señala la necesidad de analizar archivos en el sistema de archivos
• <--stdout> es el servicio de notificaciones para el registro de eventos de seguridad

Ejemplo de un archivo de configuración con variables utilizadas para analizar archivos en el sistema de archivos

Puede ver los resultados de los análisis en Resources → CI/CD o puede descargarlos en formatos .SPDX, .JSON o .HTML.

Configurar la integración al proceso de CI/CD de GitLab

En este ejemplo, se utiliza una imagen específica para el análisis con bases de datos de vulnerabilidades incorporadas ubicadas en el registro de imágenes del fabricante de Kaspersky Container Security.

Para usar la funcionalidad de análisis de imágenes en el proceso de CI/CD de GitLab, debe activar el uso de GitLab Container Registry.

Configurar la integración comprende los pasos siguientes:

1. Autorizar la CI/CD de GitLab en el registro de imágenes del fabricante de Kaspersky Container Security:
   1. En la estación de trabajo del operador del clúster, debe ejecutar el siguiente comando para preparar un hash Base64 de los datos de autorización:

      printf "login:password" | openssl base64 -A

      donde "login" y "password" equivalen al nombre de usuario y la contraseña de la cuenta en el registro de imágenes del fabricante de Kaspersky Container Security.

   2. En las variables de entorno de CI/CD de GitLab, debe crear la variable DOCKER_AUTH_CONFIG (en el repositorio de GitLab, elija Configuración [Settings] → CI/CD, haga clic en el botón Expandir [Expand] para expandir Variables y luego haga clic en el botón Añadir variable [Add variable]).
   3. Especifique la variable de la siguiente forma:

      {

      "auths": {

      "repo.cloud.example.com": {

      "auth": "base64hash"

      }

      }

      }

      donde base64hash es la cadena obtenida en el paso 1.1.

2. Autorizar las solicitudes de CI/CD de GitLab al enviar datos a Kaspersky Container Security:
   1. Copie el token de la API en la página My profile.
   2. Pegue el valor copiado del token de la API en la variable API_TOKEN en el archivo de configuración .gitlab-ci.yml.
3. Añadir la etapa de análisis de imágenes en el proceso de CI/CD

   Para añadir el análisis a la canalización CI/CD, debe añadir las siguientes líneas al archivo .gitlab-ci.yml:

   1. Añada información sobre la imagen de análisis que contiene las bases de datos de vulnerabilidades y otros objetos maliciosos después de la etapa de compilación del código, de la siguiente forma:

      scan_image:

      stage: scanner

      image:

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

      entrypoint: [""]

      pull_policy: always

      Recomendamos que siempre determine el parámetro pull_policy para recibir las compilaciones relevantes que contienen las bases de datos actualizadas de vulnerabilidades y otros objetos maliciosos para cada análisis.

   2. Debe especificar la etiqueta, el ID de compilación y el token de la API para autorizar las solicitudes de análisis de CI/CD a Kaspersky Container Security de la siguiente manera:

      SCAN_TARGET: ${CI_REGISTRY_IMAGE}:master

      BUILD_NUMBER: ${CI_JOB_ID}

      BUILD_PIPELINE: ${CI_PIPELINE_ID}

      API_TOKEN: <API token value>

      En este ejemplo, verá la etiqueta master; también puede especificar otra etiqueta.

   3. Si configura el análisis de un repositorio privado, debe especificar los datos de autorización para asegurarse de que Scanner pueda acceder a la imagen. Los datos para realizar la autorización pueden configurarse como variables.

      COMPANY_EXT_REGISTRY_USERNAME: ${COMPANY_EXT_REGISTRY_USERNAME}

      COMPANY_EXT_REGISTRY_PASSWORD: ${COMPANY_EXT_REGISTRY_PASSWORD}

   4. Para usar un certificado y establecer una conexión segura con el registro, debe especificar los datos del certificado en la variable de entorno COMPANY_EXT_REGISTRY_TLS_CERT como una cadena con el formato .PEM:

      -----BEGIN CERTIFICATE-----\n... <datos del certificado> ...\n-----END CERTIFICATE-----.

   5. Specify the following parameters of communication using a proxy server:

      HTTP_PROXY – <proxy server for HTTP requests>

      HTTPS_PROXY – <proxy server for HTTPS requests>

      NO_PROXY – <domains or appropriate domain masks to be excluded from proxying>

   6. De ser necesario, especifique la variable que usará para verificar el servidor de recepción de datos en CI/CD con un certificado de CA en el controlador de entrada:

      API_CA_CERT: ${KCS_CA_CERT}
       
      El certificado de CA del controlador de entrada se determina en el campo de texto como cadena con el formato .PEM:
       
      ----- BEGIN CERTIFICATE ----- \ n... <datos del certificado> ...\ n ----- END CERTIFICATE -----
       
      Si no se configura la variable API_CA_CERT, el análisis comenzará, pero no podrá completarse.
       
      Usar el certificado de CA del controlador de entrada permite al componente Scanner ejecutado en CI/CD verificar la autenticidad del servidor de recepción de datos.
       
      Si utiliza un certificado autofirmado o desea omitir la verificación del servidor de recepción de datos con el certificado de CA del controlador de entrada, debe especificar el valor de la variable para omitir la verificación:
       
         SKIP_API_SERVER_VALIDATION: 'true'

   7. Especifique la dirección web del servidor host de la API de Kaspersky Container Security:

      API_BASE_URL – <web address>

      variables:

      API_BASE_URL: ${API_BASE_URL}

      script:

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

      artifacts:

      paths:

      - artifact-result.json

Después de configurar la integración a un registro externo, podrá analizar las imágenes en el proceso de CI/CD, incluso un análisis en el modo SBOM. Puede ver los resultados de los análisis en Resources → CI/CD o puede descargarlos en formatos .SPDX, .JSON o .HTML.

Configurar la integración al proceso de CI/CD de Jenkins

Configurar la integración a CI/CD de Jenkins comprende los pasos siguientes:

1. Autorizar la CI/CD de Jenkins en el registro de imágenes del fabricante de Kaspersky Container Security. Para ello, en la estación de trabajo del operador del clúster, debe ejecutar el siguiente comando para preparar un hash Base64 de los datos de autorización:

   printf "usuario:contraseña" | openssl base64 -A

   donde "usuario" y "contraseña" equivalen al nombre de usuario y la contraseña de la cuenta en el registro de imágenes del fabricante de Kaspersky Container Security.

2. Autorizar la API de Kaspersky Container Security. Para ello, siga los siguientes pasos:
   1. Copie el token de la API en la página My profile.
   2. Pegue el valor copiado del token de la API en la variable API_TOKEN en el archivo de configuración Jenkinsfile.
3. Autenticar el servidor de recepción de datos en CI/CD con el certificado de CA del controlador de entrada. Para autenticarlo, en el archivo de configuración Jenkinsfile, especifique una de las siguientes variables:
   1. -e API_CA_CERT=${KCS_CA_CERT} implica la realización de la autenticación y que Scanner iniciado en CI/CD puede garantizar que el servidor de recepción es auténtico.
   2. -e SKIP_API_SERVER_VALIDATION=true implica la no realización de la autenticación del servidor de recepción con el certificado de CA del controlador de entrada.
4. Crear las variables de entorno de Jenkins:

   Para crear las variables de entorno, añada las siguientes líneas a Jenkinsfile:

   1. Añada información sobre el registro de contenedores donde se encuentra Scanner, de la siguiente manera:

      LOGIN: nombre de la cuenta en el registro de Scanner

      PASS: contraseña del registro de Scanner

   2. Si configura el análisis de un repositorio privado, debe especificar los siguientes datos de autorización para asegurarse de que Scanner pueda acceder a una imagen:

      COMPANY_EXT_REGISTRY_USERNAME: nombre de la cuenta del registro de la imagen analizada

      COMPANY_EXT_REGISTRY_PASSWORD: contraseña del registro de la imagen analizada

   3. Para usar un certificado y establecer una conexión segura con el registro, debe especificar los datos del certificado en la variable de entorno COMPANY_EXT_REGISTRY_TLS_CERT como una cadena con el formato .PEM:

      -----BEGIN CERTIFICATE-----\n... <datos del certificado> ...\n-----END CERTIFICATE-----.

   4. Especifique las siguientes variables de la comunicación con un servidor proxy:

      HTTP_PROXY: <servidor proxy para solicitudes HTTP>

      HTTPS_PROXY: <servidor proxy para solicitudes HTTPS>

      NO_PROXY: <dominios o máscaras de dominio adecuadas que se excluirán del redireccionamiento>

5. Añadir información para iniciar Scanner. Se añade la información para iniciar Scanner (esta contiene las bases de datos de vulnerabilidades y otros objetos maliciosos) al archivo de configuración Jenkinsfile como una canalización declarativa o de script.

   Ejemplo de la información para iniciar Scanner como una canalización declarativa

   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'

   }

   }

   }

   }

   Ejemplo de los datos para iniciar Scanner como una canalización de script

   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. Generar un artefacto para su descarga

   Puede generar un artefacto para descargar y recibir los resultados del análisis en los formatos .HTML o .JSON. Puede especificar el formato del artefacto en --stout de la siguiente manera:

   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'

   }

   }

   }

   }

   Para generar un artefacto .JSON, vuelva a escribir la línea --html --stdout> result.html' en el ejemplo anterior de la siguiente manera:

   --stdout > result.json',

   y en la línea archiveArtifacts artifacts, especifique el nombre del archivo en el formato definido: 'result.json'.

   Puede obtener los resultados de los análisis en el formato que especificó y también puede visualizarlos desde la sección Resources → CI/CD.

Configurar la integración al proceso de CI/CD de TeamCity

Para configurar la integración a CI/CD de TeamCity:

1. Copie el token de la API en la página My profile para autorizar la API de Kaspersky Container Security en TeamCity.
2. En el menú de configuración de la interfaz web de TeamCity, elija Build Configuration Home → Parameters.
3. Haga clic en Add new parameters para añadir los valores de las siguientes variables de entorno:
   • API_TOKEN: determine el valor copiado del token de la API de Kaspersky Container Security.
   • API_BASE_URL: determine la dirección URL de Kaspersky Container Security.
   • RUST_BACKTRACE: de ser necesario, escriba full para hacer el seguimiento de la pila.
   • SKIP_API_SERVER_VALIDATION: escriba true si usa un certificado autofirmado o si necesita omitir la autenticación del servidor de recepción con el certificado de CA del controlador de entrada.
   • COMPANY_EXT_REGISTRY_USERNAME: determine el nombre de la cuenta del registro de la imagen analizada.
   • COMPANY_EXT_REGISTRY_PASSWORD: determine la contraseña del registro de la imagen analizada.
   • COMPANY_EXT_REGISTRY_TLS_CERT: determine los datos del certificado para establecer una conexión segura con el registro.

     Los datos del certificado se declaran como una cadena en el formato .PEM:
     -----BEGIN CERTIFICATE-----\n... <datos del certificado> ...\n-----END CERTIFICATE-----.

   • HTTP_PROXY: servidor proxy para solicitudes HTTP
   • HTTPS_PROXY: servidor proxy para solicitudes HTTPS
   • NO_PROXY: dominios o máscaras de dominio adecuadas que se excluirán del redireccionamiento
4. Diríjase a la sección Build Configuration Home → Build Step: Command Line y haga clic en Add build step para añadir el paso de compilación.
5. En la ventana que se abre, defina los siguientes parámetros del paso de compilación:
   • En la lista desplegable Runner type, elija Command Line.
   • En la lista desplegable Run, elija Custom script.
   • En el campo Custom script, detalle la ruta al contenedor para el análisis (por ejemplo, /bin/sh /entrypoint.sh nginx:latest).
6. En Docker Settings, especifique los siguientes parámetros de la configuración:
   • En el campo Run step within Docker container, introduzca la dirección del análisis para el registro de Docker. Por ejemplo, company.gitlab.cloud.net:5050/companydev/example/scanner:v2.0.0-with-db.
   • En el campo Additional docker run arguments, aumente el valor de privilegios a --privileged.
7. Haga clic en Save para guardar la configuración.
8. Haga clic en Run, en la esquina superior derecha de la página, para comenzar la compilación.
9. De ser necesario, descargue el artefacto con los resultados del análisis, que estará disponible en la pestaña Artifacts, en la página de resultados de análisis en la interfaz web de TeamCity.

Inicio de página

Definir la ruta a imágenes de contenedores

Para iniciar un análisis, la solución debe determinar la ruta a las imágenes del contenedor que deben analizarse. Esta ruta puede especificarse de dos formas:

• Detallando la etiqueta de la imagen después del nombre del registro, el nombre del repositorio y el nombre de la imagen. La etiqueta es una descripción de la imagen modificable y fácil de leer.

  En este caso, la ruta tendrá el siguiente formato: <registro>/<repositorio>/<nombre de la imagen>:<etiqueta>. Por ejemplo, http://docker.io/library/nginx:1.20.1.

• Detallando el código hash de la imagen después del nombre del registro, el nombre del repositorio y el nombre de la imagen. El código hash es una propiedad interna e integral de una imagen, en particular, el hash de su contenido (se utiliza un algoritmo de hash SHA256).

  Al usar un código hash, la ruta será la siguiente: <registro>/<repositorio>/<nombre de la imagen><código hash>. Por ejemplo, http://docker.io/library/nginx@sha256:af9c...69ce.

Una etiqueta puede asignarse a diferentes códigos hash, mientras que el código hash es exclusivo de cada imagen.

Según el método usado para especificar la ruta a la imagen, Kaspersky Container Security realiza una de las siguientes acciones antes del análisis:

• Convierte la etiqueta en un código hash de confianza.
• Verifica si el código hash especificado en la ruta de la imagen es de confianza. Se considerará que un código hash es de confianza si garantiza cierto nivel de seguridad para mantener la protección deseada respecto del objeto codificado con el algoritmo de hash.

Solo se envían códigos hash de confianza al entorno de ejecución del contenedor.

Antes de ejecutar un contenedor, el contenido de la imagen se compara con el código hash recibido. Para reconocer un código hash como de confianza y una imagen como no dañada, Kaspersky Container Security verifica la integridad y la autenticidad de la firma de la imagen.

Inicio de página

Supervisar la integridad y el origen de las imágenes

Al analizar imágenes en CI/CD, Kaspersky Container Security ofrece protección frente a la suplantación de imágenes a nivel del registro. Para controlar la integridad y el origen de las imágenes de los contenedores desplegados en el clúster del orquestador, se verifican las firmas de las imágenes, comenzando en la etapa de compilación en CI.

La integridad de las imágenes se controla en dos etapas:

• Las imágenes de contenedores se firman después de crearse. Para ello se utilizan aplicaciones externas de firmas.
• Las firmas de las imágenes se verifican antes de desplegar las imágenes.

  La solución guarda una clave de firma, que se basa en la función hash SHA256 y se utiliza como el código para validar la firma. Al desplegarse en un orquestador, Kaspersky Container Security consulta al servidor de firmas para confirmar la autenticidad de la firma.

Kaspersky Container Security verifica las firmas de las imágenes de la siguiente manera:

1. En la sección Administration → Integrations → Image signature validators, puede configurar la integración de la solución a aplicaciones externas de validación de firmas en imágenes.
2. En la sección Policies → Runtime → Policies, se añade una directiva referente a la ejecución para proteger el contenido de la imagen. La directiva referente a la ejecución valida la autenticidad de las firmas. Las firmas digitales se validan sobre la base de la configuración de los validadores de firmas en imágenes.
3. El orquestador inicia el despliegue de imágenes y utiliza un
   controlador de admisión dinámica

   Controlador configurable para acceder a Kubernetes que permite aplicar directivas y es compatible con el sistema de control y gestión.

   para ejecutar una solicitud de despliegue al agente (kube-agent).

   Para enviar la solicitud al agente de Kaspersky Container Security, configure el controlador de admisión dinámica en el archivo de configuración values.yaml.

4. Sobre la base de la directiva referente a la ejecución pertinente, el agente verifica la configuración de la validación de firmas en la sección Administration → Integrations → Image signature validators.
5. Si dicha verificación confirma la autenticidad y la validez de la firma, la solución permite que la imagen se despliegue. De lo contrario, se bloqueará el despliegue.

Ejecutar análisis en modo SBOM

Kaspersky Container Security le permite iniciar Scanner para verificar las imágenes en busca de vulnerabilidades en el modo

Usar una SBOM plantea las siguientes ventajas:

• Menos recursos necesarios para analizar imágenes en busca de vulnerabilidades
• Menor tiempo de análisis debido a la verificación automática del funcionamiento y el uso correctos de los componentes de la solución
• Capacidad de análisis de todas las vulnerabilidades existentes en una imagen sin excepciones
• Alta fiabilidad en los resultados de los análisis

En CI/CD, el proceso de análisis comprende dos etapas: la recepción de un archivo SBOM y el análisis de una imagen sobre la base del archivo SBOM recibido. El análisis de las imágenes se realiza de la siguiente manera:

• Durante el análisis de CI/CD se genera la lista de los componentes de la imagen y se envía el artefacto generado a Kaspersky Container Security.
• Con el controlador de la imagen, la solución reenvía el archivo SBOM recibido para su análisis.

  Para analizar en el modo SBOM, Kaspersky Container Security inicia un análisis con bases de datos preinstaladas que contienen información sobre vulnerabilidades y otros objetos maliciosos (scanner:v2.0-with-db, scanner:v2.0-with-db-java).

Para analizar imágenes en CI/CD, debe especificar los valores de las siguientes variables de entorno en el archivo:

• API_TOKEN: valor del token de la API de Kaspersky Container Security
• API_BASE_URL: URL de Kaspersky Container Security
• API_CA_CERT: datos del certificado de CA del controlador de entrada que permite al componente Scanner ejecutado en CI/CD verificar la autenticidad del servidor de recepción de datos. Si utiliza un certificado autofirmado o desea omitir la verificación del servidor de recepción de datos con el certificado de CA del controlador de entrada, debe proporcionar el valor de la variable para omitir la verificación:

  SKIP_API_SERVER_VALIDATION: 'true'

• COMPANY_EXT_REGISTRY_USERNAME: determine el nombre de la cuenta del registro de la imagen analizada.
• COMPANY_EXT_REGISTRY_PASSWORD: determine la contraseña del registro de la imagen analizada.
• COMPANY_EXT_REGISTRY_TLS_CERT: determine los datos del certificado para establecer una conexión segura con el registro.

  Los datos del certificado se declaran como una cadena en el formato .PEM:
  -----BEGIN CERTIFICATE-----\n... <datos del certificado> ...\n-----END CERTIFICATE-----.

• HTTP_PROXY: servidor proxy para solicitudes HTTP
• HTTPS_PROXY: servidor proxy para solicitudes HTTPS
• NO_PROXY: dominios o máscaras de dominio adecuadas que se excluirán del redireccionamiento

Para los siguientes análisis, Kaspersky Container Security generará un informe en el formato CycloneDX. También puede generar un artefacto con la SBOM para descargarlo desde el proceso de CI/CD en los formatos

Para generar un archivo SBOM con formato .SPDX cuando Scanner opera en la creación de la SBOM:

Introduzca el siguiente comando en el archivo de configuración .gitlab-ci.yml:

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

donde:

<--sbom> indica la creación de un archivo SBOM.

<--spdx> indica que el artefacto se genera con el formato .SPDX.

<--stdout > example.spdx> indica la salida de los datos a un archivo con el formato .SPDX.

Para generar un archivo SBOM con formato .CDX cuando Scanner opera en la creación de la SBOM:

Introduzca el siguiente comando en el archivo de configuración .gitlab-ci.yml:

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

donde:

<--sbom> indica la creación de un archivo SBOM.

<--cdx> indica que el artefacto se genera con el formato .CDX.

<--stdout > example.cdx.json> indica la salida de los datos a un archivo con el formato .JSON.

El archivo resultante (por ejemplo, example.cdx.json) se especifica como un artefacto artifacts: paths:

El análisis con un archivo SBOM solo es posible al analizar imágenes en busca de vulnerabilidades. Si el proceso de CI/CD exige analizar en busca de otros riesgos y amenazas (como configuraciones incorrectas), debe ejecutar el análisis correspondiente de forma independiente y añadir los resultados al controlador de la imagen junto al archivo SBOM.

Ejecutar análisis en modo SBOM básico

Kaspersky Container Security le permite iniciar Scanner para verificar las imágenes en busca de vulnerabilidades en el modo SBOM básico. En este caso, la solución analiza un archivo SBOM creado especialmente y los resultados estarán disponibles en la etapa de CI/CD.

Los datos al escuchar e interceptar el tráfico de red deben transferirse de forma segura entre el entorno de CI/CD y la solución.

Puede generar un artefacto para descargar y recibir los resultados en los formatos .SPDX, .HTML, .JSON o .CDX.

Puede obtener los resultados de los análisis en el formato que especificó y también puede visualizarlos desde la sección Resources → CI/CD.

Ejecutar un análisis en GitLab

Para iniciar el análisis en el modo SBOM básico en GitLab, al configurar el análisis de imágenes en el proceso de CI/CD, debe editar el archivo de configuración .gitlab-ci.yml de la siguiente manera:

1. Añada información sobre la imagen que se analizará en CI/CD de la siguiente manera:

   scan_image:

   stage: scanner

   image:

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

   entrypoint: [""]

   pull_policy: always

2. Detalle la etiqueta de la plataforma de orquestación:

   k8s

   En el ejemplo, la etiqueta k8s se utiliza para Kubernetes, pero también puede especificar otra etiqueta para otra plataforma de orquestación compatible.

3. Especifique el ID de compilación, los datos del registro de imágenes de la imagen analizada y del certificado para establecer una conexión segura con el registro, el ID de la canalización y el token de la API para autorizar las solicitudes del análisis de CI/CD en Kaspersky Container Security de la siguiente manera:

   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 token value>

   HTTP_PROXY: <servidor proxy para solicitudes HTTP>

   HTTPS_PROXY – <proxy server for HTTPS requests>

   NO_PROXY – <domains or appropriate domain masks to be excluded from proxying>

   Los datos del certificado para establecer una conexión segura con el registro de imágenes en la variable COMPANY_EXT_REGISTRY_TLS_CERT se especifican como una cadena en el formato .PEM:
   -----BEGIN CERTIFICATE-----\n... <datos del certificado> ...\n-----END CERTIFICATE----- .

4. Si es necesario, especifique una variable para analizar el certificado de la API de la solución:

   API_CA_CERT: ${KCS_CA_CERT}

   Si no se configura la variable API_CA_CERT, el análisis comenzará, pero no podrá completarse.

5. Especifique la dirección web del servidor host de la API de Kaspersky Container Security:

   API_BASE_URL – <web address>

6. Especifique el comando para crear un artefacto en uno de los siguientes formatos cuando se inicie el análisis:
   • Para generar un artefacto en el formato .JSON:

     script:

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

     artifacts:

     paths:

     - artifact-result.json

   • Para generar un artefacto en el formato .HTML:

     script:

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

     artifacts:

     paths:

     - artifact-result.html

   • Para generar un artefacto SBOM en el formato .SPDX:

     script:

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

     artifacts:

     paths:

     - artifact-result.spdx

   • Para generar un artefacto SBOM en el formato .JSON:

     script:

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

     artifacts:

     paths:

     - artifact-result.cdx.json

Ejemplo de un análisis configurado para ejecutarse en el modo SBOM básico y la generación de un artefacto en el formato .HTML en GitLab

Inicio de página

Ejecutar un análisis fuera del proceso de CI/CD

En caso de recursos limitados, puede ejecutar la herramienta de análisis de Kaspersky Container Security independientemente de los nodos de trabajo en el proceso de CI/CD. Por ejemplo, mediante el comando docker run en un nodo de Docker o como un Job en un clúster de Kubernetes.

Para ahorrar la mayor cantidad de recursos, recomendamos utilizar la imagen scanner: 2.0.0-lite, ya que no contiene bases de datos de vulnerabilidades y envía el archivo SBOM en función de los resultados del análisis de la imagen de destino a la solución que utiliza la API.

Para iniciar la herramienta de análisis de Kaspersky Container Security fuera del proceso de CI/CD, debe especificar los siguientes parámetros obligatorios:

• API_TOKEN: el <valor del token de la API> es el token del usuario de Kaspersky Container Security para la autenticación en la interfaz de la API de la solución.
• API_BASE_URL: la <dirección web> es un enlace para acceder a la interfaz de la API de Kaspersky Container Security. Se puede acceder a la interfaz mediante los protocolos HTTP y HTTPS, según las variables de entorno de la solución desplegada.
• API_CA_CERT: el <certificado en formato .PEM> es una variable para la validación del certificado de la API de la solución.
• SKIP_API_SERVER_VALIDATION = true es una variable que, de ser necesario, se puede especificar para omitir la validación del certificado de la API de Kaspersky Container Security.

También puede especificar parámetros adicionales para el funcionamiento de la herramienta de análisis:

• COMPANY_EXT_REGISTRY_USERNAME: el <nombre de usuario del registro> es el nombre de usuario del registro donde se almacena la imagen que se va a analizar.
• COMPANY_EXT_REGISTRY_PASSWORD: la <contraseña del usuario del registro> es la contraseña del usuario del registro donde se almacena la imagen que se va a analizar.
• BUILD_NUMBER: el <ID del número de compilación> es el ID que se usa para rastrear el número de compilación en la interfaz de la solución. Kaspersky Container Security muestra el número en los resultados del análisis del proceso de CI/CD.
• BUILD_PIPELINE: el <ID del número de canalización> es el identificador que se utiliza para rastrear el número de canalización en la interfaz de la solución. Kaspersky Container Security muestra el número en los resultados del análisis del proceso de CI/CD.
• HTTP_PROXY: el <servidor proxy para solicitudes HTTP> es una variable que indica el uso de un servidor proxy HTTP cuando se requiere acceso a recursos externos.
• HTTPS_PROXY: el <servidor proxy para solicitudes HTTPS> es una variable que indica el uso de un servidor proxy HTTPS cuando se requiere acceso a recursos externos.
• NO_PROXY: los <dominios o máscaras correspondientes a dominios utilizados para la exclusión de proxy> son una variable que indica los recursos disponibles de manera local cuando se utiliza un servidor proxy.

Ejecutar un análisis en Docker

Ejecutar el análisis como un Job en un clúster de Kubernetes

Obtener resultados del análisis en formato JSON o HTML

Al usar Kaspersky Container Security para analizar imágenes en CI/CD, debe generar y guardar un artefacto que contenga los resultados del análisis en la plataforma de CI/CD. Para ello, debe usar un archivo de configuración del sistema de repositorios externo integrado a la solución. Por ejemplo, puede usar un archivo de configuración .gitlab-ci.yml en GitLab.

Puede generar un artefacto que contenga los resultados del análisis en las siguientes situaciones:

• Cuando se realiza un análisis completo de CI/CD, se puede generar un archivo de los resultados del análisis en los formatos .HTML o .JSON.
• Cuando se analiza y se crea una SBOM, se puede generar un archivo que contenga los resultados del análisis en los formatos .SPDX o .JSON.

Para generar un archivo de los resultados del análisis en el formato .HTML:

Introduzca el siguiente comando en el archivo de configuración .gitlab-ci.yml:

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

donde:

<--html> indica que el artefacto se genera con el formato .HTML.

<--stdout > example.html> indica la salida de los datos a un archivo con el formato .HTML.

Para generar un archivo de los resultados del análisis completo de CI/CD en formato .JSON:

Introduzca el siguiente comando en el archivo de configuración .gitlab-ci.yml:

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

donde:

<--stdout > example.json> indica la salida de los datos a un archivo con el formato .JSON.

El archivo resultante (por ejemplo, example.json) se especifica como un artefacto: artifacts: paths:

Inicio de página

Especificar secretos al iniciar un análisis

Al iniciar una tarea de análisis en el proceso de CI/CD, se puede acceder al registro que contiene la imagen de análisis (análisis básico o with-db para la versión correspondiente de Kaspersky Container Security) solo después de una autorización correcta. Para ello, puede pasar los secretos necesarios a la tarea de análisis.

Para autorizar el acceso al registro al iniciar una tarea de análisis:

1. Cree un secreto:

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

2. En la tarea de análisis, especifique el valor de la variable imagePullSecrets:

   imagePullSecrets:

   - name: ci-creds

3. Inicie la tarea de análisis.

   Ejemplo de una tarea de análisis y secretos para la autorización

   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

En este ejemplo, la tarea de análisis contiene los siguientes secretos:

• El secreto para descargar la imagen de análisis (especificado en la variable imagePullSecrets)
• La contraseña para descargar la imagen de análisis si el acceso al registro pertinente está limitado (especificada en la variable COMPANY_EXT_REGISTRY_PASSWORD)

Puede omitir estas contraseñas si puede acceder sin autorización al registro al que la solución obtiene acceso al ejecutar una tarea de análisis.