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.yamlDevSecOps. - 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.jsones la cartografía de puntos específicos encontrados en la inspección del código fuente y que pueden descartarse..pipeline-config.yamlque 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 enfalse, 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
scriptcuando 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.