Preguntas frecuentes para DevSecOps

Encuentra respuestas a las preguntas más frecuentes sobre el uso de DevSecOps.

¿Cuál es la diferencia entre las canalizaciones CI y CC?

Es posible que observe que las canalizaciones CI y CC tienen pasos comunes. Las exploraciones y comprobaciones que se realizan son de naturaleza y detalles similares. En la tabla siguiente se indican las diferencias entre los conductos CI y CC.

Diferencias entre los procesos CI y CC
Proceso de IC Tubería CC
Forma parte de la cadena de herramientas CI. Forma parte de la cadena de herramientas CC.
Se activa después de que una solicitud de fusión se fusione con la rama master Puede activarse manualmente o a intervalos predefinidos independientes de un calendario de despliegue.
Los detalles de un repositorio de códigos de aplicación y de un URL e de aplicación se introducen como parte del proceso de configuración. Se proporcionan los detalles de la aplicación URL y del repositorio de código de la aplicación después de configurar la cadena de herramientas CC y antes de iniciar la primera ejecución de la canalización.
Las incidencias que se crean como parte de las diversas exploraciones y comprobaciones durante los controles de conformidad no tienen fecha de vencimiento. Las incidencias que se crean como parte de los diversos escaneos y comprobaciones durante los controles de conformidad llevan una fecha de vencimiento.
Las incidencias que se crean se detectan durante la construcción. Las incidencias que se crean se detectan durante escaneos periódicos del entorno de ensayo o producción.
El archivo summary.json no se genera al final de cada ejecución de la tubería CI. El archivo summary.json no se genera al final de cada ejecución de la tubería CI.
Incluye pasos como la creación de artefactos de aplicación, la firma de artefactos y el despliegue en el clúster de desarrollo. Esto, a su vez, crea entradas para la cadena de CD. Sólo ejecuta las exploraciones y comprobaciones necesarias para las pruebas de conformidad.

¿Cómo puede un usuario personalizar la canalización?

Una canalización se personaliza utilizando scripts personalizados. Los scripts personalizados son puntos de extensión en la canalización donde los adoptantes, equipos y usuarios pueden proporcionar scripts para ejecutar tareas personalizadas para sus estrategias de CI/CD.

Los scripts personalizados controlan las etapas de la interconexión. Puede utilizar un archivo de configuración (pipeline-config.yaml) para configurar el comportamiento de las etapas, el contenido de los scripts y el artefacto base que ejecuta los scripts. Los scripts y la configuración de las etapas del pipeline se cargan desde un repositorio de aplicaciones similares a .travis.yml o Jenkinsfile o un repositorio personalizado.

Para obtener más información, consulte Personalización de canalizaciones mediante scripts personalizados.

Imagen multiarco para las limitaciones de las plataformas s390x y Power

One-Pipeline proporciona soporte nativo para las plataformas s390x y Power utilizando runtimeClassName (una cadena para indicar el perfil de tiempo de ejecución) en el archivo de configuración de one-pipeline. Sin embargo, este soporte nativo viene con algunas limitaciones y recomendaciones:

  • Limitaciones:
    • Esta función está disponible solo en v11.
    • El tiempo de arranque del pod es superior al de la clase de ejecución x86.
    • Debe utilizar podman con las cargas de trabajo s390x o Power. Docker no está disponible.
      • Es necesario actualizar los scripts de usuario para que funcionen con el comando podman en lugar del comando docker
      • La imagen del escenario debe tener podman instalado.
  • Recomendaciones: utilice las clases en tiempo de ejecución de x86 para
    • escaneado, ya que las distintas imágenes de las herramientas de escaneado pueden no ser compatibles con varios arcos.
    • firma de imágenes, ya que no se dispone de soporte multiarquitectura (trabajo en curso).

¿Cómo puedo crear una imagen base personalizada para múltiples arquitecturas?

One Pipeline ofrece una imagen base oficial para múltiples arquitecturas que es compatible con las siguientes plataformas:

  • linux/amd64
  • linux/ppc64le
  • linux/s390x

Para la mayoría de los casos de uso, recomendamos utilizar directamente la imagen base oficial:

icr.io/continuous-delivery/toolchains/devsecops/baseimage:<version>

Si tu aplicación requiere paquetes adicionales del sistema operativo, entornos de ejecución de idiomas u otras dependencias personalizadas, puedes crear tu propia imagen base multiarquitectura personalizada como parte de tu proceso de integración continua (CI).

Utiliza « Docker » Buildx con la opción « --platform » en el paso « build-artifact »:

docker buildx build \
  --platform linux/amd64,linux/ppc64le,linux/s390x \
  -t <registry>/<namespace>/<image>:<tag> \
  --push .

Esto crea imágenes específicas para cada arquitectura y las publica como un único manifiesto de imágenes para múltiples arquitecturas. Los entornos de ejecución de contenedores descargan automáticamente la imagen adecuada para la plataforma de destino.

Enfoque recomendado

  1. Utiliza la imagen base «One Pipeline» como imagen « FROM » en tu Dockerfile.
  2. Añade únicamente los paquetes o dependencias adicionales que requiera tu aplicación.
  3. Compila y publica la imagen utilizando Docker Buildx en tu proceso de integración continua (CI).
  4. Comprueba la imagen publicada en docker buildx imagetools inspect o skopeo inspect.

Para obtener más información sobre la compatibilidad con múltiples arquitecturas y sus limitaciones, consulta « Limitaciones de las imágenes multiarquitectura para las plataformas s390x y Power ».

Activación del pipeline mediante CLI

Una canalización puede activarse utilizando la CLI de IBM Cloud o una API. Con la CLI, puede iniciar una canalización proporcionando la cadena de herramientas y los ID de canalización. Mediante la API, puede enviar una solicitud POST con la autenticación y las cabeceras adecuadas para activar la canalización.

Para más información, véase Utilización de activadores

¿Qué variable de entorno se utiliza para clonar repositorios de Git?

Los flujos de trabajo de « DevSecOps » utilizan un sistema jerárquico de tokens para autenticar las operaciones del repositorio « Git », incluida la clonación. La propiedad de entorno « git-token » actúa como token predeterminado, pero puedes sustituirla por tokens más específicos para mejorar la seguridad y el control de acceso.

Orden de prioridad de los tokens

El canal procesa los tokens de autenticación de Git siguiendo el siguiente orden de prioridad (de mayor a menor):

  1. Token de acceso personal (PAT) especificado en la integración de la cadena de herramientas para un repositorio concreto
  2. Token específico del repositorio: git-token-[repo_name]-[repo_org]
  3. Token específico de la organización: git-token-[repo_org]
  4. Token predeterminado: git-token
  5. OAuth token de la integración de la cadena de herramientas (si se utiliza « OAuth » en lugar de «PAT»)

Ejemplos de nombres de tokens

Para un repositorio en https://github.com/my-org/my-app:

  • Específico del repositorio: git-token-my-app-my-org
  • Específico de la organización: git-token-my-org

Consideraciones importantes

  • Si se utiliza el mismo git-token tanto para leer repositorios (clonación) como para realizar operaciones de escritura (establecer el estado de PR/CI, actualizar el inventario), el acceso de solo lectura no es suficiente. El token debe tener permisos de escritura.
  • El uso de tokens específicos para cada repositorio u organización te permite aplicar el principio del privilegio mínimo, otorgando únicamente los permisos necesarios para cada repositorio.

Para obtener más información sobre las funciones de los tokens del repositorio, consulta « Recuperación de información y tokens del repositorio ».

¿Cómo se comprueban los cambios en la configuración de « OnePipeline »?

Para probar los cambios en la configuración de « OnePipeline », es necesario adoptar un enfoque sistemático que evite interrumpir los flujos de trabajo de producción mientras se validan las personalizaciones.

Comprensión de los componentes de « OnePipeline »

OnePipeline consta de dos componentes principales personalizables:

  • Definiciones de procesos de Tekton: definiciones de procesos gestionadas de forma centralizada para flujos de trabajo de PR, CI, CD y CC, disponibles en el repositorio compliance-pipelines. Las nuevas versiones se publican cada dos semanas.

    • v10: Versión estable con concurrencia limitada
    • v11: Versión de última generación con máxima personalización y capacidad de trabajo simultáneo

  • Configuración del canal (.pipeline-config.yaml): archivo de configuración personalizado que anula los comportamientos predeterminados del canal, incluidas las imágenes, los scripts, las arquitecturas y las propiedades del canal. Este archivo se puede guardar en el repositorio de su aplicación o en un repositorio de configuración centralizado.

Enfoque de prueba 1: uso de un archivo de configuración de pruebas

Este es el método recomendado para probar los cambios de configuración sin afectar a los procesos de producción.

  1. Crear una rama de prueba

    • Crea una rama en el repositorio que contenga tu archivo .pipeline-config.yaml
    • Realiza los cambios de configuración en esta rama

  2. Configurar un activador de prueba

    • Duplica el activador de pipeline existente en tu cadena de herramientas
    • Ponle un nombre claro (por ejemplo, « Manual-Test-Config »)
    • Actualiza las propiedades del disparador para que apunten a tu configuración de prueba:
      • pipeline-config: Nombre del archivo de configuración
      • pipeline-config-branch: El nombre de tu rama de pruebas
      • pipeline-config-repo: Repositorio URL que contiene la configuración

  3. Prueba en modo de desarrollo

    • Activa el modo de desarrollo en las propiedades del disparador
    • Ejecuta el proceso de automatización para validar tus scripts personalizados
    • El modo de desarrollo omite la recopilación de pruebas, la creación de incidencias de cumplimiento y las actualizaciones de inventario, lo que lo hace ideal para iteraciones rápidas
    • Importante: El modo de desarrollo no es adecuado para cargas de trabajo de producción

  4. Prueba con comprobaciones de conformidad

    • Después de validar los scripts en modo de desarrollo, desactiva dev-mode
    • Mantén desactivadas las actualizaciones de inventario durante las pruebas
    • Llevar a cabo un proceso completo que incluya la recopilación de pruebas y la gestión de incidencias
    • Comprueba que todas las comprobaciones de conformidad se superen según lo previsto

  5. Promocionar a producción

    • Cuando las pruebas sean satisfactorias, crea una solicitud de incorporación de cambios para fusionar tus modificaciones con la rama principal
    • Los cambios se aplicarán automáticamente a los desencadenantes de producción
    • Si surge algún problema, puedes revertir rápidamente los cambios

Enfoque de prueba 2: Modificación de la disposición del proceso

Bifurcación de definiciones de canalizaciones (avanzado)

  • (Crea una rama del repositorio compliance-pipelines )
  • Desarrolla y prueba los cambios en tu bifurcación
  • Añade el repositorio bifurcado como una integración de Git en tu cadena de herramientas
  • Actualiza temporalmente la definición del pipeline para que haga referencia a tu bifurcación
  • Configura un activador en modo de desarrollo para probar la nueva definición del pipeline
  • Sigue los pasos de la prueba del Método 1

Prácticas recomendadas

  • Prueba siempre primero en modo de desarrollo para detectar rápidamente los errores de script
  • Utiliza nombres descriptivos para los desencadenantes de las pruebas a fin de evitar confusiones
  • Documenta los cambios de configuración en los mensajes de confirmación
  • Mantén desactivados los desencadenantes de las pruebas o elimínalos tras la prueba para evitar ejecuciones accidentales
  • Considera la posibilidad de crear una cadena de herramientas de prueba específica para los cambios importantes en el proceso de desarrollo
  • Revisa detenidamente los registros del proceso para asegurarte de que todas las etapas se ejecutan según lo previsto

Para obtener más información sobre cómo personalizar los procesos, consulta Scripts personalizados y