Cómo traer su propia app a DevSecOps

Hay varias formas de incorporar su propia aplicación a una cadena de herramientas de integración continua y despliegue continuo ( DevSecOps ).

Usar muestras

Para integrar su propia aplicación en una cadena de herramientas de integración continua ( DevSecOps ) para una integración y un despliegue continuos y sin problemas, comience con nuestras configuraciones de muestra.

Node.js ejemplo

Cree la cadena de herramientas de DevSecOps utilizando la app de ejemplo predeterminada que se proporciona. La hello-compliance-app aloja un servidor Node.js que proporciona una página web estática.

Otras muestras

También puede empezar utilizando una de estas muestras:

  • Code-engine-compliance-app: este repositorio contiene una aplicación de cumplimiento de código ( Node.js ) que ilustra estrategias de compilación de código ( Code Engine ) y puede implementarse como una aplicación de compilación de código ( Code Engine ) o un trabajo de compilación de código ( Code Engine ).
  • Go-compliance-app: este repositorio contiene un microservicio Go que utiliza Gin, implementado mediante helm.
  • Python-compliance-app: este repositorio contiene un microservicio de Python que utiliza Flask, implementado mediante helm.
  • Node-cloudant-compliance-app: este repositorio contiene una aplicación de cumplimiento normativo ( Node.js ) implementada mediante kubectl, que interactúa con una instancia de registro de configuración ( Cloudant ) creada a través de infraestructura como código (Terraform).

Utilizar la configuración de DevSecOps inferida

Una vez que haya agregado su propio repositorio de código fuente de aplicaciones a la cadena de herramientas CI de DevSecOps, puede utilizar la función de configuración de canalización de Inferred DevSecOps para comenzar de inmediato. Esta función:

  • No requiere ninguna personalización inicial.
  • Inferencia el contenido del archivo de configuración de canalizaciones .pipeline-config.yaml DevSecOps.
  • Identifica los scripts necesarios para crear, probar e implementar el código.
  • Proporciona el código para estos scripts.

Utilice esta función para incorporar fácil y rápidamente sus microservicios o aplicaciones a canalizaciones de DevSecOps, y agilizar la adopción de DevSecOps.

Generación de un archivo yaml de configuración de canalización de CI para un repositorio de código fuente determinado (configuración inferida de DevSecOps en modo autónomo)

Puede generar un archivo pipeline-config para un repositorio de código fuente determinado de forma estática/en modo autónomo. Esta función se basa en la misma lógica que la configuración inferida de DevSecOps y se proporciona a través de un script específico en la imagen base de conformidad de DevSecOps.

Requisitos previos

  • Disponga de un motor Docker en funcionamiento en su entorno local
  • yq para ejecutar los siguientes comandos

Uso

El script se encuentra en la siguiente ruta de la imagen base de cumplimiento: /opt/one-pipeline/polyglot/tools/enable-devsecops.sh.

El uso del script es enable-devsecops.sh [--configuration <key>=value]* [--configuration-file <filename>] [--version <v9|v10|v11>]* <path to source code directory>

Los siguientes fragmentos ilustran cómo utilizar este script.

# clone the source code repository that you want to generate CI pipeline config for
git clone https://us-south.git.cloud.ibm.com/open-toolchain/hello-containers
cd hello-containers

export compliance_base_image=$(curl -L https://us-south.git.cloud.ibm.com/open-toolchain/compliance-pipelines/-/raw/open-v10/definitions/ci-trigger.yaml?ref_type=heads | yq '.spec.params[] | select(.name == "compliance-baseimage") | .default')

# environment variable compliance_base_image should contains a value like icr.io/continuous-delivery/toolchains/devsecops/devsecops-baseimage:3.109.7_commons-1.50.2 or upper

# define hint for unit-test and acceptance-test configuration properties as the hello-containers
# sample has specific npm script entries for it

docker run --platform linux/amd64 -v.:/src --rm -it $compliance_base_image /opt/one-pipeline/polyglot/tools/enable-devsecops.sh --configuration hint-npm-unit-testing-script=test-unit --configuration hint-npm-acceptance-testing-script=test-fvt /src

Puede proporcionar parámetros específicos utilizando las opciones de --configuration (o --configuration-file <file path> con un archivo que contenga un par clave-valor).

Los parámetros proporcionados configurarán el proceso de extracción de DevSecOps y los parámetros disponibles se describen aquí: configuración del punto de extracción

docker run --platform linux/amd64 -v.:/src --rm -it $compliance_base_image /opt/one-pipeline/polyglot/tools/enable-devsecops.sh --configuration hint-npm-unit-testing-script=test-unit --configuration hint-npm-acceptance-testing-script=test-fvt /src

Resultados

polyglot-spots.json y .pipeline-config.yaml se añaden al directorio raíz del repositorio de código fuente.

  • polyglot-spots.json es la cartografía de puntos específicos encontrados en la inspección del código fuente y que pueden descartarse.
  • .pipeline-config.yaml que utilizará el proceso CI

Ahora puedes empujar el .pipeline-config.yaml al repositorio git de código fuente y utilizarlo como repositorio de la aplicación como se describe en Onboarding an application.

Adición de parámetros de etapa

El código fuente de cada aplicación de ejemplo contiene un archivo « .pipeline-config.yaml ». El archivo .pipeline-config.yaml es el archivo de configuración principal que utilizan las cadenas de herramientas de integración continua y despliegue continuo en todas las etapas del proceso de ejecución del pipeline.

Añada un archivo de configuración .pipeline-config.yaml que contenga las siguientes propiedades necesarias para cada etapa:

image
El nombre de la imagen de « Docker » que se utiliza para ejecutar la fase. Por ejemplo, utilice el código siguiente para firmar las imágenes:
image: icr.io/continuous-delivery/pipeline/image-signing:1.0.   0@sha256:e9d8e354668ba3d40be2aaee08298d2aa7f0e1c8a1829cca4094ec93830e3e6a
abort_on_failure

Establece esta propiedad en « true » para detener la ejecución del proceso si falla una etapa. Si esta propiedad se establece en false, el paso se marca como pasado con un estado de aviso, también conocido como estado ámbar, y la interconexión continúa ejecutándose.

script

El script que lleva a cabo las acciones necesarias en la fase. Crea los scripts en el directorio «script» del repositorio de la aplicación y ejecútalos desde esa ubicación. Por ejemplo, el siguiente fragmento de código muestra el contenido de la sección script cuando se desea firmar las imágenes:

script: |
   #!/usr/bin/env bash
   STAGE_DIND="true"
   STAGE_ABORT_ON_FAILURE="false"
   STAGE_IMAGE_PULL_POLICY="IfNotPresent"
   source scripts/sign_image.sh
dind

Establece esta propiedad en « true » si deseas habilitar las funciones de « docker » en el proceso en ejecución. Una vez que hayas determinado qué parámetros son necesarios, puedes definir los distintos pasos del proceso.

setup

Define esta etapa para ejecutar los scripts de preconfiguración.

setup:
   image: icr.io/continuous-delivery/pipeline/pipeline-base-image:2.      12@sha256:ff4053b0bca784d6d105fee1d008cfb20db206011453071e86b69ca3fde706a4
   script: |
   #!/usr/bin/env bash
   echo "Please insert any required pre-build tasks in this stage."
test

Define esta etapa para ejecutar los casos de prueba de la aplicación.

test:
   abort_on_failure: false
image: icr.io/continuous-delivery/pipeline/pipeline-base-image:2.      12@sha256:ff4053b0bca784d6d105fee1d008cfb20db206011453071e86b69ca3fde706a4
script: |
   #!/usr/bin/env bash
   cd ../"$(load_repo app-repo path)"
   #npm ci
   #npm test
   source test/test.sh
static-scan

Defina esta etapa para ejecutar una exploración estática en el código.

static-scan:
   dind: true
   image: icr.io/continuous-delivery/pipeline/pipeline-base-image:2.12@sha256:ff4053b0bca784d6d105fee1d008cfb20db206011453071e86b69ca3fde706a4
   script: |
   #!/usr/bin/env bash
   echo "Please insert script to invoke/execute static scan tool like SonarQube on the application source code."
containerize

Define esta etapa para compilar y contenerizar tu aplicación.

containerize:
   dind: true
   image: icr.io/continuous-delivery/pipeline/pipeline-base-image:2.      12@sha256:ff4053b0bca784d6d105fee1d008cfb20db206011453071e86b69ca3fde706a4
   script: |
   #!/usr/bin/env bash

   if [[ "$PIPELINE_DEBUG" == 1 ]]; then
   trap env EXIT
   env
   set -x
   fi
   source scripts/build_setup.sh
   source scripts/build.sh
deploy

Define esta etapa para implementar tu aplicación en el entorno de destino.

deploy:
   image: icr.io/continuous-delivery/pipeline/pipeline-base-image:2.      12@sha256:ff4053b0bca784d6d105fee1d008cfb20db206011453071e86b69ca3fde706a4
   script: |
   #!/usr/bin/env bash

   if [[ "$PIPELINE_DEBUG" == 1 ]]; then
   trap env EXIT
   env
   set -x
   fi
   source scripts/deploy_setup.sh
   source scripts/deploy.sh
sign-artifact

Por defecto, la cadena de herramientas de CI DevSecOps firma todas las imágenes que se construyen durante la etapa de containerización. Las claves GPG que se proporcionan durante la configuración de la cadena de herramientas se utilizan para firmar las imágenes. Si desea personalizar el proceso de firma de imágenes, añada la siguiente definición de etapa en .pipeline-config.yaml:

sign-artifact:
   abort_on_failure: false
   image: icr.io/continuous-delivery/pipeline/image-signing:1.0.      0@sha256:e9d8e354668ba3d40be2aaee08298d2aa7f0e1c8a1829cca4094ec93830e3e6a
   script: |
   #!/usr/bin/env bash
   STAGE_DIND="true"
   STAGE_ABORT_ON_FAILURE="false"
   STAGE_IMAGE_PULL_POLICY="IfNotPresent"
   source scripts/sign_image.sh
acceptance-test

Configura esta etapa para que se ejecute la prueba de aceptación tras la implementación.

acceptance-test:
   abort_on_failure: false
   image: icr.io/continuous-delivery/pipeline/pipeline-base-image:2.      12@sha256:ff4053b0bca784d6d105fee1d008cfb20db206011453071e86b69ca3fde706a4
   script: |
   #!/usr/bin/env bash
   export APP_URL=$(cat ../app-url)
   source scripts/setup_go.sh
   echo "APP_URL :- ${APP_URL}"
   go run acceptance-test/acceptance-test.test.go
release

Define esta fase para cargar las pruebas y los elementos de prueba generados en las fases anteriores.

release:
   abort_on_failure: false
   image: icr.io/continuous-delivery/toolchains/devsecops/compliance-baseimage:2.26.      1@sha256:a780174a64474187b01b5e40a1721d8307f02897ac6f3eba2d482d4f4926edf1
   script: |
   #!/usr/bin/env bash
   source scripts/release.sh
scan-artifact

Defina esta etapa para ejecutar una exploración de vulnerabilidades en los artefactos generados.

scan-artifact:
   abort_on_failure: false
   image: icr.io/continuous-delivery/pipeline/pipeline-base-image:2.      6@sha256:7f588468622a981f89cf5e1212aaf75fface9da6169b5345ca52ab63d8215907
   script: |
   #!/usr/bin/env bash
   source scripts/va_scan.sh
dynamic-scan

Defina esta etapa para ejecutar el escaneo dinámico en la aplicación desplegada.

dynamic-scan:
   dind: true
   abort_on_failure: false
   image: icr.io/continuous-delivery/pipeline/pipeline-base-image:2.12@sha256:ff4053b0bca784d6d105fee1d008cfb20db206011453071e86b69ca3fde706a4
   script: |
   #!/usr/bin/env bash
   echo "Please insert script to invoke/execute dynamic scan tool like OWASP ZAP on the built and deployed application."

Para obtener más información sobre las etapas, consulte scripts personalizados.