Cómo resolver problemas de seguridad del informe Allure

Los informes de prueba detallados y visualmente atractivos son cruciales para que los probadores de software comprendan los resultados de las pruebas y tomen decisiones informadas. Con meticulosa atención al detalle, el equipo de Social Discovery Group elabora informes de prueba visualmente cautivadores con la ayuda de Allure Reports, la potencia de código abierto que parecía tener todas las respuestas. Sin embargo, descubrimos un defecto: la seguridad. Cualquiera que tuviera un enlace podía echar un vistazo al interior y faltaba su adaptabilidad entre subsistemas. En este artículo, el equipo de pruebas de SDG comparte cómo lograron resolver los problemas de seguridad de los informes de Allure creando un Allure Docker adecuado y modificando el esquema de almacenamiento.

El entorno de desarrollo SDG se basa en productos de Microsoft, y se utiliza Azure DevOps para ejecutar procesos CI/CD. A través de la canalización de CI, se construye el repositorio de pruebas automatizadas, seguido de la categorización a través de varias canalizaciones de CD según las preferencias de los evaluadores para las ejecuciones de pruebas.

Consideremos el esquema tal como fue configurado originalmente:

En esta configuración, la canalización de CD también sirve como generador para dos informes de Allure: uno para notificaciones de Slack, que proporciona a los evaluadores un enlace convenientemente legible que especifica etapas y categorías de prueba, y otro para exportar el informe de Allure a Azure DevOps.

Esto se logra mediante la instalación de una extensión en Azure DevOps, que permite la generación de informes y su posterior carga al contenedor $web para sitios web estáticos en la cuenta de almacenamiento de Azure. La configuración habilitada de acceso anónimo permite visualizar el informe a través de un enlace.

Para mayor comodidad, también se utilizó un complemento adicional para mostrar el informe de Allure en el proceso de compilación.

Si bien este esquema es funcional, tiene ciertos inconvenientes:

En primer lugar, este método carece de seguridad, ya que cualquier persona que tenga el enlace puede acceder a los informes de Allure. Dependiendo de la prueba, el informe puede contener información confidencial sobre los servicios, sus vulnerabilidades y cualquier otro dato sensible cuyo acceso público deba restringirse. El acceso general se otorga debido al indicador habilitado de "acceso anónimo" en la cuenta de almacenamiento de Azure, que proporciona a cualquier persona acceso a la dirección. Deshabilitar esta función impediría el acceso externo a los archivos para personas no autorizadas, pero también haría que el informe fuera inaccesible en la página de Azure DevOps.

En segundo lugar, el método no es universalmente aplicable en todos los subsistemas. Si examinamos la lista de trabajos en la canalización del CD, veremos que el trabajo nativo "azcopy" se usa para copiar el informe a la cuenta de almacenamiento. Este trabajo solo está disponible con agentes en Windows y, cuando se usa Linux, devuelve un error.

En tercer lugar, está el inconveniente de ver el historial y las tendencias de las pruebas. Se puede acceder al único historial de informes disponible a través de notificaciones de Slack, lo que no es un método conveniente para encontrar pruebas específicas.

Todos los factores antes mencionados llevaron a la conclusión de que es necesario modificar el sistema existente. Por lo tanto, se consideraron varias soluciones a este problema:

1. Crear un método para generar un archivo .html unificado que combinaría todo el proyecto del informe Allure en un solo documento.

2. Utilizar servicios de terceros que ofrecen autenticación para ver el informe.

3. Búsqueda de una imagen prefabricada con su propia autenticación para ver informes.

   
   

Ahora, profundicemos en cada uno de estos puntos con más detalle.

Como se mencionó anteriormente, deshabilitar la función de "acceso anónimo" en la cuenta de almacenamiento restringe el acceso a los archivos a través del enlace para usuarios no autorizados. Para proporcionar acceso a personas específicas desde el exterior, el propio Azure ofrece varias opciones posibles, que incluyen la concesión de tokens SAS y la configuración de políticas de acceso. Sin embargo, debido a la naturaleza de la generación del informe Allure, específicamente el archivo index.html, que hace referencia a scripts JavaScript existentes en la estructura del proyecto:

Al abrir el informe, la página resulta estar vacía porque el acceso entre archivos dentro del propio almacenamiento de blobs está restringido.

Para crear un único archivo .html, descubrimos un imagen que, cuando se implementó, facilitó la generación del archivo a partir de un proyecto completo de Allure utilizando el comando integrado "allure-combine ./path/to/allure/generated/report/folder". Sin embargo, este proceso requiere que el agente tenga instalado Python. Desafortunadamente, este enfoque resultó ineficaz debido a la falta de archivos adjuntos a los resultados de las pruebas de API, que son componentes cruciales para garantizar el correcto funcionamiento del trabajo de los evaluadores.

También vale la pena señalar que Azure ofrece listas blancas de IP, que permiten filtrar las personas que requieren acceso. Sin embargo, dado que el equipo que necesita acceso no tiene una dirección IP estática, este método no era adecuado.

Teniendo en cuenta que Allure es una práctica popular para recopilar pruebas en el entorno de desarrollo, existen servicios pagos disponibles en línea. Por ejemplo, el servicio https://qameta.io/ proporciona almacenamiento y generación de informes Allure en una interfaz web fácil de usar. Sin embargo, estos servicios suelen ser pagos y la funcionalidad requerida es mínima. Por lo tanto, consideramos esta opción de implementación como último recurso.

La elección que elegimos fue la imagen Docker del servicio allure-docker ( https://github.com/fescobar/allure-docker-service ) con la capacidad de integración del panel de interfaz de usuario ( https://github.com/fescobar/ allure-docker-service-ui ) con autenticación. La comunicación con el servicio se configura a través de HTTP/HTTPS y la imagen en sí admite la funcionalidad a través de solicitudes API.

Destaquemos algunas ventajas de esta solución:

1. Seguridad: la transmisión de datos se cifra mediante mecanismos SSL y TLS, y la imagen proporciona a los usuarios integrados "administrador" y "espectador" credenciales de inicio de sesión que pueden modificarse y proporcionarse a los usuarios según sus necesidades.

2. Comodidad: el servicio viene con su propia interfaz visual que ofrece varias funcionalidades para trabajar con informes de Allure.

3. Funcionalidad: gracias a las solicitudes de API, se pueden idear combinaciones interesantes con canales de lanzamiento en el lado de Azure DevOps. Por ejemplo, generar un informe, cargarlo y luego borrar el caché en una sola etapa.

   
   

En conclusión, nuestro proceso de lanzamiento se ve así:

Vale la pena señalar que no nos alejamos de la extensión Azure DevOps, que permite cargar informes de Allure, ya que en ese momento ya habíamos hecho la transición a nuestros propios agentes y nos adherimos a la idea de que todo funcionara "por nuestra cuenta". " máquinas.

Con respecto al almacenamiento, experimentamos escribiendo en cuentas de almacenamiento de Azure, específicamente cargando en File Share, Blob y Blob usando la utilidad azcopy.

Los resultados variaron significativamente. Al usar el comando para carga por lotes de archivos de almacenamiento de File Share az, la velocidad de escritura para nuestra prueba fue de más de una hora:

Al usar Blob Storage con el comando az Storage blob upload-batch, el rendimiento se multiplicó por seis, en aproximadamente 11 minutos:

El resultado más rápido fue mediante la herramienta azcopy:

Si bien se utiliza la integración incorporada de azcopy en el proceso de lanzamiento, es incompatible con las máquinas Linux. Sin embargo, al utilizar el trabajo de la CLI de Azure e instalar esta utilidad en el agente, se puede emplear el comando con confianza:

copia azcopy 'FUENTE' 'DESTINO' --recursivo = verdadero

Gracias al descubrimiento de la imagen de Allure Docker desde lo más profundo de la red, pudimos modificar el esquema de almacenamiento y visualización de los informes. El acceso a los datos ahora está protegido con contraseña y la creación y el procesamiento de informes siguen siendo rápidos. Además, desde la perspectiva de los usuarios (probadores), los cambios son mínimos. La solución funciona independientemente de otros programas, gracias a un agente separado en el clúster, y no puede afectar otros procesos de desarrollo. La rentabilidad de esta solución es comparable a la de un agente autohospedado independiente (15 dólares, siempre que esté aislado), que es mucho más barato que las alternativas existentes. Por ejemplo, el qameta.io considerado anteriormente, donde el precio para un solo usuario es de $30/mes.

Escrito por Dmitrijs Gusarovs, ingeniero medio de DevOps en Social Discovery Group.