Utilización de los grupos de IBM Cloud Object Storage como archivo de pruebas

Puede configurar los depósitos de IBM Cloud Object Storage (COS) para almacenar las pruebas generadas por las comprobaciones de cumplimiento integradas en los flujos de trabajo de DevSecOps. Las pruebas de conformidad crean el seguimiento de auditoría que los auditores buscan durante una auditoría de conformidad. Uno de los objetivos de DevSecOps es la generación y el almacenamiento automatizados de pruebas en archivos pruebas auditables. Para obtener más información, consulte Bloqueador de pruebas.

El proceso de automatización del cumplimiento normativo almacena la siguiente información en el bucket de COS:

Artefactos de tarea
Resultados de pruebas, resultados de análisis o cualquier salida guardada por las tareas.
Registros de tareas
Una vez ejecutado el proceso, los registros de esa ejecución se envían al almacén de pruebas.
Pruebas
Información sobre las tareas y sus resultados, que pueden ser un error o un éxito. Para obtener más información sobre el formato de las pruebas que se envían, consulte Resumen de pruebas.

Configuración del grupo

Se debe crear una instancia de nube dedicada Object Storage antes de establecer una integración continua o una cadena de herramientas de despliegue continuo. Este grupo de COS se utiliza para el almacenamiento relacionado con la conformidad, ya que los casilleros de pruebas se deben crear en el límite de las aplicaciones. Esto ayuda a mejorar la resiliencia de su conducto. Para obtener más información, consulte Resiliencia.

Para configurar tu depósito de Cloud Object Storage para que actúe como almacén de pruebas de cumplimiento como parte de un proceso de integración continua o de implementación continua, puedes utilizar la siguiente información como guía. Los scripts de plantilla del pipeline o de la cadena de herramientas no configuran el locker en Cloud Object Storage.

Consulte esta página para obtener más información sobre las consideraciones (granularidad, seguridad,...) para utilizar Cloud Object Storage como prueba de conformidad.

Política de retención

Puedes configurar los buckets de Cloud Object Storage para aplicar una política o un periodo de retención a los objetos subidos, lo que también se conoce como Object Storage inmutables. El Almacenamiento de objetos inmutables conserva registros electrónicos y mantiene la integridad de los datos. Las políticas de retención garantizan que los datos se almacenen en formato WORM (Write-One-Read-Many), de forma que no se puedan borrar ni reescribir. No puede cambiar ni suprimir objetos en grupos protegidos dentro del periodo de retención, ni suprimir los grupos protegidos con objetos propiamente dichos hasta que se haya terminado el periodo de retención. La política se aplica hasta el final de un período de retención y hasta que se eliminan todas las retenciones legales.

Se recomienda que los equipos establezcan una política de retención para los grupos que se utilizan como archivo de pruebas que almacena cada objeto durante un mínimo de 365 días.

Permisos de acceso del grupo

Cuando se utilizan canalizaciones en la nube dentro del entorno de la nube de servicios compartidos ( DevSecOps ), los objetos como las pruebas, los resúmenes de pruebas y los artefactos se canalizan o se leen desde los depósitos en el sistema de operaciones compartidas ( IBM Cloud Object Storage, COS). Las herramientas no crean, actualizan, eliminan ni alteran ningún objeto o cubo.

Para garantizar un acceso seguro a sus depósitos de nube de Object Storage, al tiempo que se facilitan las operaciones necesarias de canalización, siga estas políticas de acceso:

  • Lector.

    1. Este permiso garantiza que los procesos de transferencia de datos ( Continuous Delivery, CD) puedan verificar la configuración de retención del bucket sin modificar ningún dato.
    2. Requerido para leer las evidencias generadas por el canal de CI

  • Redactor de objetos.

    1. Este permiso permite que los procesos de integración continua (CI), entrega continua (CD) y control de configuración (CC) carguen o escriban nuevos objetos en los buckets.

Pasos para crear credenciales de servicio

Para acceder a su cubo COS mediante Cloud Pipelines:

  1. Navegue hasta Credenciales de servicio:
  2. Crear una nueva credencial:
    • Haga clic en "Crear" y siga las indicaciones para crear una nueva credencial de servicio para su bucket COS.

Pasos para asignar acceso a los buckets de COS

Para asignar los permisos de acceso adecuados a sus depósitos COS:

  1. Navegue hasta Permisos de cubo de IAM:
  2. Asignar funciones y políticas:
    • Asigne el rol de Lector a los canales de CD para comprobar las políticas de retención.
    • Asigne la función de escritor de objetos a los canales CI, CD y CC para escribir pruebas en cubos.

Cuando utilice el depósito de la Object Storage nube como almacenamiento de pruebas, los permisos recomendados son «Lector» y « Escritor de objetos ». Deben evitarse los permisos con privilegios más altos (por ejemplo, acceso de nivel de administrador) para evitar la modificación accidental o maliciosa de sus objetos.

Clases de almacenamiento

Los costes varían para los equipos con diferentes configuraciones y frecuencias de despliegue. No se recomienda utilizar el nivel gratuito como buckets de Cloud Object Storage, ya que el nivel gratuito no se puede configurar para que sea inmutable.

Estimación de muestra

Si estás trabajando con un proceso de referencia de integración continua o de implementación continua con seis pruebas en cada uno, una sola ejecución conjunta de integración continua e implementación continua genera 37 solicitudes de clase A y seis de clase B.

  • La integración continua graba seis registros, seis artefactos y seis pruebas, lo que equivale a 18 PUT de clase A.
  • La implementación continua lee seis pruebas (seis GET de clase B), escribe seis pruebas, seis registros, seis artefactos y un resumen, lo que equivale a 19 PUT de clase A.

Con una media de cinco microservicios (cinco × integración continua) y cuatro regiones de implementación (cuatro × implementación continua), una implementación completa equivale a 166 solicitudes de clase A y 24 de clase B.

Con un despliegue completo por semana (cuatro por cada mes), puede calcular 664 solicitudes de clase A y 96 de clase B al mes.

La cantidad de datos que se recopila varía según el caso de uso. Con tamaños medios para pruebas (1 kB), artefactos de prueba (100 kB) y registros (15 kB), puede calcular 0.01 GByte de datos que se crean y transfieren al mes.

Resiliencia

Se recomienda utilizar la resiliencia Cross-Region o la resiliencia Regional si es necesario mantenerse dentro de unos límites. Para obtener más información sobre estas regiones, consulte Puntos finales y ubicaciones de almacenamiento.

Nombre de grupo

Los nombres de los buckets de Object Storage en la nube deben ser únicos a nivel global y cumplir con los requisitos del DNS. Los nombres deben tener entre 3 y 63 caracteres de longitud y deben contener letras en minúsculas, números y guiones. Los nombres de grupo deben empezar y terminar por una letra en minúsculas o por un número. Los nombres que se parecen a las direcciones IP no están permitidos. Los nombres de grupo son exclusivos en todo el sistema de IBM Cloud Object Storage y no pueden contener información personal como, por ejemplo, una parte de un nombre o dirección, o cuentas financieras y de seguridad o SSN.

Los nombres de grupo deben ser exclusivos porque todos los grupos de la nube pública comparten un espacio de nombres global. Este requisito permite acceder a un bucket sin necesidad de proporcionar ninguna información sobre la instancia del servicio ni sobre la cuenta. Tampoco es posible crear un bucket cuyo nombre comience por cosv1- o account-, ya que estos prefijos están reservados por el sistema.

Punto final

Utilice puntos finales de private para la mayoría de las solicitudes que se originan desde dentro de IBM Cloud® y utilice puntos finales de public para la mayoría de las solicitudes que se originan desde fuera de IBM Cloud®. Para obtener más información, consulte Tipos de punto final.

Para los conductos que se ejecutan en la región de Londres, utilice los puntos finales de direct debido a la infraestructura de trabajador gestionada por conducto.

Configuración de Toolchains con el cubo COS

Para almacenar evidencias, activos y adjuntos, configure el cubo COS en sus canalizaciones. Dado que este depósito se utiliza para recuperar la información existente, debería tener acceso a Reader y Object Writer. Para configurar este bucket en la canalización.

Propiedades del entorno para la configuración de cubo de COS |Nombre |Tipo |Descripción |Obligatorio u opcional | Bloqueado o desbloqueado | |:----------|:------------------------------|:------------------|:----------|:----------| | cos-api-key | SECRET | La clave API de Cloud Object Storage. | Obligatorio | Bloqueado | | cos-access-key-id | SECRET | La clave de acceso de Cloud Object Storage ID de las credenciales HMAC. (Se proporciona junto con cos-secret-access-key en lugar de cos-api-key)| Obligatorio | Desbloqueado | | cos-secret-access-key | SECRET | La clave de acceso secreta de Cloud Object Storage de las credenciales HMAC. (Se proporciona junto con cos-access-key-id en lugar de cos-api-key) | Obligatorio | Desbloqueado | | cos-bucket-name | texto | El nombre del bucket de su instancia de Cloud Object Storage que se utiliza como almacén de pruebas. |Obligatorio | Desbloqueado | | cos-endpoint | texto | El punto final que lee las pruebas de la instancia de Cloud Object Storage que se utiliza como almacén de pruebas. Para obtener más información, consulte Tipos de puntos finales. | Obligatorio | Desbloqueado |

Configure el mismo cubo en todas sus canalizaciones CI/CD/CC.

Migración de Git Evidence Locker a COS Evidence Locker

Para mejorar el rendimiento, la fiabilidad y la escalabilidad de la compilación, se ha dejado de admitir Evidence Lockers basados en Git. Pasarse a los almacenes de Cloud Object Storage pruebas basados en COS ayuda a reducir la dependencia de Git las operaciones y evita los problemas de limitación de velocidad de Git hosting los proveedores.

Todos los usuarios deben actualizar sus cadenas de herramientas y procesos para utilizar un COS Evidence Locker.

Cuando su cadena de herramientas solo utiliza un Git Evidence Locker

Sigue estos pasos para completar la migración:

Cuando su cadena de herramientas utiliza tanto Git como COS Evidence Lockers

Si ya tienes ambos configurados:

  • Elimine la propiedad evidence-repo environment de todas las canalizaciones.
  • Elimine la GitHub/GitLab integración asociada al repositorio de pruebas en su cadena de herramientas.

Preparación de canalizaciones de CD para la migración de Git a COS Evidence Locker

Si sus canalizaciones de CI y CD dependen de un Git Evidence Locker, las canalizaciones de CD deben iniciarse para utilizar el Evidence Locker de COS. Puedes elegir uno de los siguientes enfoques.

Enfoque 1: Bootstrap utilizando ambos almacenes de pruebas

En este enfoque, COS Evidence Locker está habilitado mientras Evidence Git Locker permanece configurado. Al ejecutar ambos en paralelo, el COS Evidence Locker se puede iniciar automáticamente utilizando el Git Evidence Locker.

  • Mantenga la configuración Git del armario de pruebas en su lugar.
  • Habilite el COS Evidence Locker.
  • Ejecute el proceso de canalización de CD utilizando una versión de definición de canalización anterior a v10.46.1 (recomendado: v10.45.0 ).
  • Una vez completada la ejecución, elimine la configuración Git de Evidence Locker tal y como se ha descrito anteriormente.

Enfoque 2: Bootstrap sin Git Evidence Locker

Utilice este enfoque si prefiere una migración limpia sin depender de Git.

  • Elimine la Git configuración de Evidence Locker.
  • Realice una ejecución única del canal de CD con el force-redeploy parámetro establecido en true.
  • Una vez finalizada la ejecución, restablezca force-redeploy a false o elimine el parámetro por completo.

Esta ejecución única del canal de CD garantiza que el COS Evidence Locker se complete con todos los activos de inventario existentes. Solo se necesita una única ejecución inicial y usted puede. Si prefiere no activar una implementación real, puede omitir las etapas de implementación y prueba de aceptación para ejecutar el proceso de CD sin realizar ninguna acción de implementación.

Puede optar por archivar el Git archivo de pruebas después de la eliminación, ya que sería necesario para fines de auditoría.

Migrar de un bucket de COS a otro bucket de COS

Migrar de un bucket COS a otro Si ya es usuario del armario de evidencias COS y necesita migrar de un bucket COS a otro, es importante que se asegure de que la transición se realice sin problemas y sin interrumpir sus flujos de trabajo. A continuación se indican los pasos y consideraciones para la migración entre los buckets de COS.

Razones de la migración:

  • Reestructuración organizativa: Es posible que desee dejar de utilizar un grupo de COS y empezar a utilizar otro.
  • Traslado de la cuenta: La cuenta debe trasladarse de una cuenta a otra, posiblemente debido a cambios organizativos o requisitos de cumplimiento.

Pasos para migrar:

Configurar el bucket de copia de seguridad de COS: si está migrando de un bucket de COS antiguo a uno nuevo, asegúrese de que su canalización esté configurada para utilizar tanto el bucket antiguo como el nuevo. Esto permite una migración fluida sin interrumpir sus flujos de trabajo existentes.

  • Cree el nuevo cubo de COS como se define en los pasos anteriores.
  • Configurar políticas de IAM: Asegúrese de que el nuevo depósito de COS tenga las políticas de IAM necesarias para el acceso de Reader y Object Writer, según lo requieran sus procesos.
  • Actualizar variables de entorno

En las cadenas de herramientas de IBM, actualice las variables de entorno para incluir tanto los antiguos como los nuevos buckets de COS. Para configurar el cubo antiguo, utilice el prefijo backup- en todas las propiedades COS env y utilice las propiedades normales para configurar el nuevo cubo COS.

Nombre Tipo Descripción Obligatoria u opcional Bloqueado o desbloqueado
backup-cos-api-key SECRET La clave de la API de Backup Cloud Object Storage. Obligatorio Bloqueada
backup-cos-access-key-id SECRET Cloud Object Storage La clave de acceso de la copia de seguridad de la ID de la clave de acceso de las credenciales HMAC. (Se proporciona junto con backup-cos-secret-access-key en lugar de backup-cos-api-key) Obligatorio Desbloqueado
backup-cos-secret-access-key SECRET La clave de acceso secreta de Backup Cloud Object Storage, de las credenciales HMAC. (Se proporciona junto con backup-cos-access-key-id en lugar de backup-cos-api-key) Obligatorio Desbloqueado
backup-cos-bucket-name Texto El nombre del depósito de copias de seguridad de su instancia de Cloud Object Storage que se utiliza como almacén de pruebas. Obligatorio Desbloqueado
backup-cos-endpoint Texto El punto final que lee las pruebas de la instancia de copia de seguridad de Cloud Object Storage que se utiliza como almacén de pruebas. Para obtener más información, consulte Tipos de puntos finales. Obligatorio Desbloqueado

No elimine el bucket antiguo durante 365 días, ya que sería necesario a efectos de auditoría.

Guía de resolución de problemas para tuberías de funcionamiento lento

  1. force-redeploy no se debe establecer en true, a menos que sea una redistribución de todas las entradas.
  2. La tubería de promoción debe utilizarse para promover el conjunto correcto de delta, de modo que el cálculo de delta sea correcto.
  3. Si ve este tipo de líneas, significa que la tubería CI no está generando los resúmenes correctos. Vuelva a la tubería CI y compruebe si hay algún error al crear los mini-resúmenes en el paso de finalización.