Llevamos un tiempo explicando lo fácil que es integrar nuestra instancia de Faraday a nuestro proceso de desarrollo de aplicaciones Python integradas con Heroku. En nuestros últimos posts, lo hicimos utilizando Acciones de GitHub, Jenkins, y Travis CI.
Hoy vamos a ponerlo en práctica utilizando la versión en la nube de GitLab CI/CD y añadiremos un nuevo uso SonarQube como nueva herramienta de exploración de códigos.
Como hicimos en el último post, vamos a suponer que ya tienes un repositorio python en algún servidor git que ya está configurado usando Heroku. Puedes leer nuestro primer post si quieres saber cómo configurar esto y obtener más contexto.
GitLab puede utilizarse de dos maneras: una de ellas es la versión local, que requiere ser instalada en su propia infraestructura, y la otra es la versión en la nube. Vamos a centrarnos únicamente en la versión en la nube porque todas las GitLab configuración y configuración de los corredores no es importante para este documento.
El lector debe saber que este post se centrará en la .gitlab-ci.yml cómo configurarlo para que sea leído, ejecutado e integrado con nuestra instancia de Faraday fácilmente, evitando configuraciones personalizadas. Sin embargo, le sugerimos leer la guía GitLab CI/CD para entender completamente cómo funciona esta herramienta.
Por último, supondremos que el lector ya sabe cómo SonarQube funciona y vamos a centrarnos únicamente en la configuración necesaria para integrarlo con nuestra instancia de Faraday.
Paso 1: Creación del archivo .gitlab-ci.ylm
Si has leído los posts anteriores, probablemente ya entiendas cómo funcionan estas herramientas de CI/CD. Normalmente requieren crear un archivo en la raíz de tu proyecto con un nombre específico, y GitLab no es la excepción.
Vamos a crear un nuevo archivo en la raíz de nuestro proyecto llamado .gitlab-ci.yml. Este archivo le dirá a GitLab todos los pasos que necesita ejecutar para construir, desplegar y escanear nuestra aplicación, y cómo subir los resultados del escaneo a Faraday.
Empezaremos a escribir lo siguiente en este nuevo archivo:
imagen: docker:latest servicios: - docker:dind etapas: - construir - desplegar - prueba - subirvariables:MOUNT_POINT: /builds/$CI_PROJECT_PATH/output
Explicaremos qué hemos hecho en las líneas anteriores y qué significa cada una.
Esto es muy similar a lo que hicimos con Travis CI en el post anterior:
- imagen:
Todos los pipelines que se ejecutan en GitLab se ejecutan en docker. Puedes definir qué imagen docker quieres que ejecute tu pipeline con esta palabra clave. En nuestro caso, estamos usando una imagen docker especial que contiene una instancia docker en su interior porque necesitamos ejecutar construcción docker y docker run más tarde. Si quiere saber más sobre el imagen palabra clave que puede lea la documentación oficial.
- servicios: Esta palabra clave le permite declarar los servicios necesarios para su canalización como mongodb, redis, etc. Necesitamos habilitar el docker dentro de nuestro docker mage, por lo que necesitaremos el comando docker:dind servicio. Esto puede cambiar en función de su proyecto específico, por lo que le sugerimos que lea la documentación oficial.
- etapas: Esta palabra clave te permite definir todas las etapas que tendrá nuestro pipeline. GitLab tiene 5 etapas por defecto pero puedes redefinirlas a tu gusto. Cada trabajo tendrá que declarar a qué etapa pertenece, pero por defecto pertenecerá a prueba etapa. Debe saber que todos los trabajos que se ejecuten en una etapa específica se ejecutarán en paralelo y las etapas se ejecutarán secuencialmente. Para más información le sugerimos lea la documentación oficial.
- variables: Como hicimos en Travis CI, puedes definir variables de entorno dentro de este archivo y también en el proyecto GitLab. Aquí estamos definiendo la variable de entorno $MOUNT_POINT porque necesitamos enlazar los sistemas de archivos docker más tarde. Probablemente te habrás dado cuenta de que estamos utilizando una variable de entorno predefinida de GitLab llamada $CI_PROJECT_PATH. Le sugerimos lea la documentación oficial con todas las variables predefinidas de GitLab.
Paso 2: Definir los puestos de trabajo
Definamos los trabajos de cada etapa:
imagen: docker:latest
servicios:
- docker:dind
etapas:
- build
- desplegar
- probar
- subir
variables:
MOUNT_POINT: /builds/$CI_PROJECT_PATH/output
construir:
stage: build
script:
- apk update
- apk upgrade
- apk add curl jq python3 python3-dev build-base libffi-dev libressl-dev gettext
- curl -O https://bootstrap.pypa.io/get-pip.py
- python3 get-pip.py
- python3 -V
- pip install virtualenv
- virtualenv venv
- fuente venv/bin/activate
- pip install -r requisitos.txt
- mkdir -p $MOUTN_POINT
- bandit -r $CI_PROJECT_PATH -f xml -o $MOUNT_POINT/flaskapp_faraday_bandit.xml --exit-zero
- docker run --rm -e SONAR_HOST_URL=$SONARQUBE_URL -e SONAR_LOGIN=$SONARQUBE_TOKEN -v /builds/$CI_PROJECT_PATH:/usr/src sonarsource/sonar-scanner-cli -Dsonar.organization=$SONARQUBE_ORGANIZATION -Dsonar.projectKey=$SONARQUBE_PROJECT
artefactos:
paths:
- $MOUNT_POINT/flaskapp_faraday_bandit.xml
desplegar:
stage: deploy
script:
- build
script:
- apk update
- apk upgrade
- apk add git
- git remote rm heroku || true
- git remote add heroku https://heroku:$HEROKU_API_KEY@git.heroku.com/$HEROKU_APP_NAME.git > /dev/null
- git push heroku HEAD:master -f
comprobación de vulnerabilidades:
stage: test
script:
- docker pull owasp/zap2docker-stable
- docker run -u root -v $MOUNT_POINT:/zap/wrk/:rw --network=host -t owasp/zap2docker-stable zap-baseline.py -t $ZAP_SCAN_URL -x flaskapp_faraday_zap.xml || true
artefactos:
paths:
- $MOUNT_POINT/flaskapp_faraday_zap.xml
subir-resultados:
stage: build
script:
- apk update
- apk upgrade
- apk add git curl
- curl -u "$SONARQUBE_TOKEN:" $SONARQUBE_URL/api/issues/search?componentKeys=$SONARQUBE_PROJECT&types=VULNERABILITY&p=1&ps=500 > $MOUNT_POINT/flaskapp_faraday_sonarqube.json # ATENCIÓN: Debe iterar si el total < 500 (tamaño de página)
- docker build https://github.com/flopezluksenberg/docker-faraday-report-uploader.git -t faraday-uploader
- export CURRENT_DATE=${fecha+'%Y-%m-%d'}
- docker run --name faraday-uploader --rm -v $MOUNT_POINT:$MOUNT_POINT -e HOST=$FARADAY_URL -e USERNAME=$FARADAY_USERNAME -e PASSWORD=$FARADAY_PASSWORD -e WORKSPACE=$CI_PROJECT_NAME-$CURRENT_DATE-$CI_COMMIT_SHORT_SHA -e FILES=$MOUNT_POINT/flaskapp_faraday_zap.xml faraday-uploader
- docker run --name faraday-uploader --rm -v $MOUNT_POINT:$MOUNT_POINT -e HOST=$FARADAY_URL -e USERNAME=$FARADAY_USERNAME -e PASSWORD=$FARADAY_PASSWORD -e WORKSPACE=$CI_PROJECT_NAME-$CURRENT_DATE-$CI_COMMIT_SHORT_SHA -e FILES=$MOUNT_POINT/flaskapp_faraday_bandit.xml faraday-uploader
- docker run --name faraday-uploader --rm -v $MOUNT_POINT:$MOUNT_POINT -e HOST=$FARADAY_URL -e USERNAME=$FARADAY_USERNAME -e PASSWORD=$FARADAY_PASSWORD -e WORKSPACE=$CI_PROJECT_NAME-$CURRENT_DATE-$CI_COMMIT_SHORT_SHA -e FILES=$MOUNT_POINT/flaskapp_faraday_sonarqube.json faraday-uploader
Parece grande pero si lees lo que hicimos es casi lo mismo que hicimos en los post anteriores pero con algunos cambios relacionados con esta herramienta.
Debemos mencionar que algunos comandos se repetirán en diferentes etapas. Esto ocurre porque cada etapa se ejecuta de forma independiente.
Tenemos que mencionar que la etapa de prueba se ejecutará después de la etapa de despliegue, porque nos referimos a probar la aplicación en ejecución con Zap.
Vamos a explicar cada trabajo y cada concepto que aparece mientras leemos como hicimos en nuestros posts anteriores.
Paso 2.1: Crear trabajo
Este es el primer job a ejecutar. Como puede ver, hemos definido que este trabajo pertenece a la etapa de construcción, por lo que puede darse cuenta de que podemos cambiar el trabajo del nombre si lo desea
Cuando comenzamos este post dijimos que estamos usando una imagen docker para ejecutar todos los trabajos. Eso significa que tal vez no tenemos todas las herramientas necesarias en la imagen y tal vez tenemos que instalar algunos de ellos
Para ello, tenemos que ejecutar los 3 primeros comandos: actualización pk, actualización apk, apk .
Luego, para terminar este trabajo, instalamos python 3 y virtualenv. Después ejecutamos bandido como ya hicimos en anteriores entradas.
Es importante mencionar que el artefacto nos permite exponer algunos ficheros como resultado del trabajo y nos permite compartir ficheros entre etapas (recordemos que hemos dicho que cada etapa es independiente). En este caso hemos guardado el fichero generado en el directorio definido en $MOUNT_POINT. Este sistema de archivos compartidos entre etapas ocurre en Acciones de GitHub también si te acuerdas.
Por último, como puedes ver, hemos ejecutado un escaneo sonar utilizando algunas variables de entorno que definiremos más adelante. En este caso nuestro proyecto no tiene integración directa con el sonar porque no tenemos un sonar-project.properties creado, así que usamos el cli para pasar los datos requeridos como organización y llave del proyecto. Si su proyecto ya está integrado con SonarQube, puede evitar esas variables.
Paso 2.2: Despliegue del trabajo
Empezamos este trabajo instalando git mando. Necesitamos git porque nuestra aplicación se desplegará en Heroku y utilizamos git para hacerlo (Esto es lo mismo que hicimos en nuestros posts anteriores).
De nuevo hemos utilizado dos variables que deben definirse en el proyecto GitLab: HEROKU_API_KEY y HEROKU_APP_NAME. Más adelante explicaremos cómo configurarlo.
Paso 2.3: vuln-checking Job
Este trabajo es bastante sencillo porque sólo descargamos la imagen docker zap, la ejecutamos y guardamos el archivo resultante en $MOUNT_POINT/flaskapp_faraday_zap.xml.
Puedes ver de nuevo que estamos utilizando otra variable de entorno que definiremos más adelante llamada $ZAP_SCAN_URL.
Por último, publicamos el archivo de resultados mediante la función artefactos como hicimos en la fase de construcción.
Paso 2.3: cargar-resultados Job
Sólo queda subir los archivos generados por bandido, zapproyectos de SonarQube a nuestra instancia de Faraday.
Empezamos este trabajo instalando git y rizo. Necesitamos git porque se utiliza para descargar la imagen docker personalizada que utilizaremos más adelante.
Ahora hay que prestar atención. El rizo está descargando el SonarQube generados en el primer trabajo porque los necesitamos para subirlos a nuestro Insights y Blog instancia. Hay notas importantes al respecto:
- En el momento de escribir este post, sonar-scanner-cli no nos permite guardar el resultado en un archivo. El resultado se carga en SonarQube automáticamente.
- Por lo tanto, para obtener esos números necesitamos hacer una petición a la API de SonarQube.
- Esta API fue desarrollada para crear este tipo de integración, y esa es la razón por la que existe un paginador. Este paginador puede traerle hasta 500 elementos.
- NOTA IMPORTANTE: Estamos evitando validar si la longitud de las incidencias recibidas es mayor que el tamaño de la página e iterar para recuperar las incidencias que faltan porque esto es sólo un ejemplo con fines educativos. Debe asegurarse de recuperar todas las incidencias cuando integre su instancia de Faraday con SonarQube.
A continuación, hemos creado la variable conocida $FECHA_ACTUAL que hemos utilizado para el nombre del espacio de trabajo. Por último, cargamos los archivos.
En este punto debemos mencionar todas las variables predefinidas de GitLab y algunas variables personalizadas utilizadas anteriormente:
Las variables predefinidas de GitLab que hemos utilizado son las siguientes:
- $CI_NOMBRE_PROYECTO: Es el nombre del proyecto
- $CI_COMMIT_SHORT_SHA: En posts anteriores hemos utilizado el número de compilación para crear el espacio de trabajo, pero GitLab no dispone de esa variable, por lo que hemos decidido sustituirla por ésta.
Las variables personalizadas utilizadas aquí son las siguientes:
- $FARADAY_URL
- $FARADAY_USERNAME
- $FARADAY_PASSWORD
- $SONARQUBE_URL
- $SONARQUBE_TOKEN
- $SONARQUBE_PROJECT
Paso 3: Creación de variables de entorno personalizadas en GitLab
Antes de ejecutar nuestro pipeline necesitamos crear nuestras variables de entorno personalizadas que hemos utilizado junto con todo el contenido del archivo .gitlab-ci.yml archivo. En nuestro caso, como mencionamos en la introducción, estamos utilizando la versión en la nube de GitLab.
Para ello tenemos que ir a nuestro repositorio en GitLab que probablemente sea https://gitlab.com/// . Una vez allí, tenemos que ir a Ajustes → CI/CD situado en el menú de la izquierda
En esta página podemos configurar un montón de características de esta herramienta. En este caso ampliaremos la sección Variables.
Una vez allí tenemos la opción Añadir variable. Cuando haga clic ahí, verá el siguiente modal donde puede añadir la clave y el valor de su variable de entorno.
Una vez que hayas añadido todas las variables de entorno, verás algo como esto:
Pasos 3.1: Variables de SonarQube
Hemos utilizado 4 variables relacionadas con SonarQube configuración.
Como hemos explicado antes, nuestro proyecto no tiene SonarQube integración porque no tiene la sonar-project.properties y esa es la razón por la que hemos añadido las variables $SONARQUBE_ORGANIZACION y $SONARQUBE_PROJECT.
En $SONARQUBE_URL es la variable SonarQube URL host que necesita ser expuesta a internet.
Por último, el $SONARQUBE_TOKEN variable puede obtenerse a través del SonarQube y se utiliza para cargar resultados y consultar la API de búsqueda. Para obtener este token es necesario ir a su SonarQube host y vaya a Mi Cuenta -> Seguridad -> Tokens. En esta página debe elegir un nombre para su nuevo token y hacer clic en Generar token. Entonces verá algo como lo siguiente:
Ahora puedes añadir esta variable al GitLab Pipeline.
Eso es todo, puedes comprometerte y empujar tu .gitlab-ci.yml y ver la ejecución.
Paso 4: Comprobación de los resultados finales
La interfaz de usuario de GitLab es bastante simple. Para ver la ejecución de nuestro pipeline tenemos que ir a CI/CD → Pipelines en el menú de la izquierda que hemos mostrado antes.
Una vez allí, si todo fue como esperábamos, verás algo como esto:
Si hace clic en "Pipeline out", el último trabajo tendrá el siguiente aspecto:
Y eso es todo. Ahora podemos ver nuestro nuevo espacio de trabajo en Faraday:
Si entramos en la sección Gestionar veremos los vulns detectados:
Conclusiones
En general, GitLab es bastante sencillo de configurar al menos en la versión clod y más aún si lo hemos hecho antes en Acciones en GitHub, Jenkinsproyectos de Travis CI.
Queremos mencionar lo útiles que son los plugins faraday y la variedad que tiene porque la integración SonarQube tomó sólo algunas líneas nuevas en nuestro archivo pipeline,
Enlaces útiles
App Vuln Management: Integración de Faraday en el proceso de desarrollo de software - Parte 3
App Vuln Management: Integración de Faraday en el proceso de desarrollo de software - Parte 2
App Vuln Management: Integración de Faraday en el proceso de desarrollo de software - Parte 1
Cargador de informes Docker Faraday
Ejemplo de repositorio (rama: GitLab)
Ejemplo de aplicación vulnerable
Documentación oficial de Gitlab CI/CD
Documentación del escáner SonarQube
Descargue todos nuestros documentos sobre DevSecOps aquí
