Cómo utilizan los repositorios las canalizaciones DevSecOps

Para crear, probar y desplegar su aplicación, las canalizaciones DevSecOps utilizan dos repositorios:

• app-repo: el repositorio de aplicaciones, que contiene el código fuente de la aplicación.
• config-repo: el repositorio de configuración, que contiene los archivos y scripts YAML de configuración de interconexión.

En la aplicación de ejemploDevSecOps, estos dos repositorios son los mismos. La mayoría de los que adoptan DevSecOps empiezan con este patrón. Pero, a medida que incorpore más microservicios, es posible que sea necesario un repositorio de configuración de interconexión dedicado y separado. Puesto que el repositorio de aplicaciones y el repositorio de configuración son los mismos en la app de ejemplo, el repositorio se clona dos veces cuando se ejecutan las interconexiones, lo que puede provocar errores. Por lo tanto, es una buena práctica tener un repositorio de configuración independiente para alojar archivos de configuración y secuencias de comandos que se puedan compartir y reutilizar entre diferentes cadenas de herramientas y canalizaciones DevSecOps. Para obtener más información sobre cómo personalizar el repositorio de configuración, consulte los pasos de personalización avanzados.

DevSecOps consideran que los scripts app-repo y config-repo son dos repositorios distintos. Los scripts clonan los repositorios dos veces durante la etapa de inicio de la interconexión. Estos clones se conocen como app-repo y one-pipeline-config-repo. Cada etapa se ejecuta en el contexto de config repo.

Opción 1: Añadir el repositorio de aplicaciones y utilizar el repositorio de aplicaciones de ejemplo como repositorio de configuración

Para añadir el repositorio de aplicaciones a la cadena de herramientas y utilizar el repositorio de aplicaciones de ejemplo como repositorio de configuración, realice los pasos siguientes:

1. En la consola ' IBM Cloud ', haz clic en el icono ' Menú ' ' > ' Automatización de plataformas > ' Cadenas de herramientas, y selecciona la cadena de herramientas que quieras editar.
2. Pulse Añadir.
3. Seleccione dónde se aloja el repositorio de la app, ya sea Gitlab o GitHub.
4. Utilice el servidor predeterminado o añada uno nuevo.
5. Introduzca la dirección de correo electrónico ( URL ) del servidor personalizado y el token de acceso personal.
6. Pulse Crear integración.
7. Introduzca el repositorio de código fuente de su aplicación URL.
8. Pulse Crear integración.

A continuación, especifique el repositorio de aplicación de ejemplo como repositorio de configuración completando los pasos siguientes:

1. En la consola ' IBM Cloud ', haz clic en el icono ' Menú ' ' > ' Automatización de plataformas > ' Cadenas de herramientas, y selecciona la cadena de herramientas que quieras editar.
2. Pulse pr-pipeline.
3. Pulse Valores y vaya a la pestaña Propiedades de entorno.
4. Edite el valor de la propiedad pipeline-config-repo para que apunte al repositorio de aplicaciones de muestra URL.
5. Vuelva a la cadena de herramientas de AC.
6. Pulse ci-pipeline.
7. Pulse Valores y vaya a la pestaña Propiedades de entorno.
8. Edite el valor de la propiedad pipeline-config-repo para que apunte al repositorio de aplicaciones de muestra URL.

Las interconexiones de AC ahora utilizan el repositorio de apps de ejemplo pipeline-config como repositorio de configuración.

Opción 2: Sustituir el repositorio de aplicaciones de ejemplo por su propio repositorio de aplicaciones

Para sustituir el repositorio de apps de ejemplo por su propio repositorio de apps, realice los pasos siguientes:

1. En la consola ' IBM Cloud ', haga clic en el icono ' Menú ' ' > ' Automatización de plataformas > ' Cadenas de herramientas, y seleccione la cadena de herramientas CI que desea editar.
2. Busque el repositorio de código fuente de aplicación de ejemplo y seleccione Configurar.
3. Sustituya el repositorio URL por el repositorio de código fuente de su aplicación URL.
4. Pulse Guardar integración.

Después de sustituir el repositorio de la app de ejemplo, asegúrese de que el nuevo repositorio de la app contiene un archivo .pipeline-config.yaml y los scripts correspondientes. Copie el archivo .pipeline-config.yaml y los scripts del repositorio de aplicaciones de ejemplo en el repositorio de aplicaciones o utilice este archivo de configuración de ejemplo.

Configuración de las interconexiones de AC

Después de añadir el repositorio de aplicaciones, debe configurar las interconexiones de AC para que funcionen con el nuevo repositorio.

Uso de scripts personalizados con DevSecOps

El archivo ' pipeline-config.yaml ' es el componente clave que orquesta y personaliza el comportamiento del pipeline DevSecOps. El archivo utiliza scripts para crear, probar y desplegar la aplicación. El archivo define cómo se configuran las etapas y qué scripts se ejecutan. Para obtener más información, consulte scripts personalizados.

Hay dos categorías principales de scripts que se utilizan en los pipelines DevSecOps:

• Scripts relacionados con la aplicación que se utilizan para crear, probar y desplegar la aplicación. Estos scripts son su propia responsabilidad y están fuera del alcance del soporte DevSecOps. Puesto que estos scripts no tienen una implementación predeterminada, debe añadirlos a la aplicación o al repositorio de configuración. Es posible que tenga que extraer los scripts de Jenkins u otro origen.
• Scripts de seguridad y conformidad que ejecutan exploraciones de seguridad y conformidad. La mayoría se proporcionan con scripts predeterminados que puede alterar temporalmente para utilizar su propia implementación personalizada.

Excepto para la etapa de inicio, cada etapa de una interconexión de AC, CD o CC se puede personalizar con sus propios scripts para alterar temporalmente la implementación predeterminada de la etapa. La etapa de inicio no se puede personalizar con sus propios scripts.

Aunque los scripts Bash se proporcionan como ejemplos, puede crear, probar y desplegar la aplicación utilizando otros lenguajes como Python o Go. Asegúrese de que está utilizando el image correcto para cada etapa. Consulte las imágenesDocker en la sección Pipelines DevSecOps.

Consulte la tabla Etapas y tareas que resumen diversas etapas del conducto de AC. La tabla también proporciona una información consolidada sobre si la etapa tiene una implementación de referencia predeterminada, si se puede personalizar o omitir, o si hay una recopilación de pruebas explícita necesaria para la ejecución de la etapa.

Configuración de la interconexión de CD

En el flujo de trabajo de integración continua y despliegue continuoDevSecOps, el proceso de integración continua envía actualizaciones al repositorio de inventario durante la fase " deploy-release " del proceso de integración continua. Para obtener más información, consulte el script release.sh de ejemplo.

En este flujo de trabajo, varios activadores de CI y diferentes cadenas de herramientas de CI DevSecOps pueden contribuir al mismo repositorio de inventario.

Al contrario que la interconexión de AC, el script de despliegue que utiliza la interconexión de CD debe adaptarse de los scripts actuales en Jenkins, Travis o alguna otra plataforma para utilizar las entradas del repositorio de inventario.

Este código de ejemplo muestra cómo recuperar información del inventario y utilizarla para ejecutar un despliegue de Kubernetes.

Localización de scripts DevSecOps

Los pipelines DevSecOps vienen con herramientas de seguridad y escaneo predeterminadas y scripts asociados.

Por ejemplo, el inicio de un registro de etapa hace referencia al script predeterminado:

scan-artifact:
  image: icr.io/continuous-delivery/pipeline/pipeline-base-ubi:3.24
  dind: true
  dind_image: icr.io/continuous-delivery/toolchains/devsecops/docker:20.10.21-dind
  abort_on_failure: false
  image_pull_policy: IfNotPresent
  script: |
    #!/bin/sh

    "/opt/commons/scan-artifact/scan.sh"

/opt/commons/scan-artifact/scan.sh es el script predeterminado.

El pipeline DevSecOps proporciona la ruta a la carpeta raíz de la librería commons en una variable de entorno llamada ' COMMONS_PATH, que está disponible en todas las tareas y pasos. Para acceder a un script que está incorporado en la imagen base de conformidad, utilice la variable COMMONS_PATH con la carpeta de script que necesita:

source "${COMMONS_PATH}/<script folder in commons>/<script file name>

Consulte la tabla Etapas y tareas que resume varias etapas de la interconexión de CD. La tabla también proporciona una información consolidada sobre si la etapa tiene una implementación de referencia predeterminada, si se puede personalizar o omitir, o si hay una recopilación de pruebas explícita necesaria para la ejecución de la etapa.

Propiedades de entorno

Los pipelines DevSecOps vienen con propiedades de entorno predefinidas, pero puedes añadir tantas propiedades personalizadas como necesites. Puede acceder a estos valores de propiedades en los scripts utilizando Mandato get_env.

Después de añadir la propiedad y su valor predeterminado opcional al conducto o desencadenante, utilice el mandato get_env en el script para recuperar el valor de la propiedad. El ejemplo siguiente recupera el valor de la propiedad my-variable:

MY_VARIABLE=$(get_env my-variable "")

También puede alterar dinámicamente el valor de una propiedad en un script utilizando Mandato set_env. El ejemplo siguiente altera temporalmente el valor de la propiedad my-variable:

set_env my-variable new-value

Omitir etapas

Algunas etapas pueden ser irrelevantes. Por ejemplo, es posible que no esté creando ninguna imagen de Docker o que todavía no haya implementado pruebas de aceptación. Si desea omitir una etapa, puede editar el archivo .pipeline-config.yaml para incluir exit 0 o establecer la variable skip en true.

El ejemplo siguiente añade exit 0 para omitir una etapa:

scan-artifact:
  image: icr.io/continuous-delivery/pipeline/pipeline-base-ubi:3.24
  dind: true
  dind_image: icr.io/continuous-delivery/toolchains/devsecops/docker:20.10.21-dind
  abort_on_failure: false
  image_pull_policy: IfNotPresent
  skip: false
  runAfter: null
  script: |
    #!/bin/sh

    exit 0
    "/opt/commons/scan-artifact/scan.sh"

Imágenes Docker en los procesos DevSecOps

De forma predeterminada, las canalizaciones DevSecOps utilizan IBM Continuous Delivery. Estas imágenes contienen algunas de las herramientas más comunes como, por ejemplo, Node y Java para ejecutar los scripts. También puede utilizar imágenes de otros proveedores o sus propias imágenes personalizadas que contengan las herramientas que prefiera.

Las imágenes Docker utilizadas por las canalizaciones DevSecOps se especifican en el archivo " .pipeline-config.yaml ". Cada etapa puede utilizar una imagen diferente.

scan-artifact:
  image: icr.io/continuous-delivery/pipeline/pipeline-base-ubi:3.24
  dind: true
  dind_image: icr.io/continuous-delivery/toolchains/devsecops/docker:20.10.21-dind
(...)