Comment résoudre les problèmes de sécurité des rapports Allure

Des rapports de test détaillés et visuellement attrayants sont essentiels pour que les testeurs de logiciels puissent comprendre les résultats des tests et prendre des décisions éclairées. Avec une attention méticuleuse aux détails, l'équipe du Social Discovery Group crée des rapports de test visuellement captivants avec l'aide d'Allure Reports - la centrale open source qui semblait avoir toutes les réponses. Pourtant, nous avons découvert une faille : la sécurité. Toute personne disposant d’un lien pouvait y jeter un coup d’œil, et son adaptabilité entre les sous-systèmes faisait défaut. Dans cet article, l'équipe de test SDG explique comment elle a réussi à résoudre les problèmes de sécurité des rapports Allure en créant un Allure Docker approprié et en modifiant le schéma de stockage.

L'environnement de développement SDG est basé sur les produits Microsoft, avec Azure DevOps utilisé pour exécuter les processus CI/CD. Grâce au pipeline CI, le référentiel de tests automatisés est construit, suivi d'une catégorisation via plusieurs pipelines CD en fonction des préférences des testeurs pour les exécutions de tests.

Considérons le système tel qu'il a été initialement mis en place :

Dans cette configuration, le pipeline CD sert également de générateur pour deux rapports Allure : un pour les notifications Slack, fournissant aux testeurs un lien facilement lisible spécifiant les étapes et les catégories de tests, et un autre pour exporter le rapport Allure vers Azure DevOps.

Ceci est réalisé grâce à l'installation d'une extension dans Azure DevOps, qui permet la génération de rapports et le téléchargement ultérieur vers le conteneur $web pour les sites Web statiques dans le compte de stockage Azure. La configuration activée de l'accès anonyme permet d'afficher le rapport via un lien.

Pour plus de commodité, un plugin supplémentaire a également été utilisé pour afficher le rapport Allure dans le pipeline de build.

Bien que ce système soit fonctionnel, il présente certains inconvénients :

Premièrement, cette méthode manque de sécurité car les rapports Allure sont accessibles à toute personne disposant du lien. En fonction du test, le rapport peut contenir des informations confidentielles sur les services, leurs vulnérabilités et toute autre donnée sensible dont l'accès au public doit être restreint. L'accès général est accordé en raison de l'indicateur « accès anonyme » activé dans le compte de stockage Azure, qui permet à toute personne ayant accès à l'adresse. La désactivation de cette fonction mettrait fin à l’accès externe aux fichiers pour les personnes non autorisées, mais rendrait également le rapport inaccessible sur la page Azure DevOps.

Deuxièmement, la méthode n’est pas universellement applicable à tous les sous-systèmes. Si nous examinons la liste des tâches dans le pipeline CD, nous verrons que la tâche native « azcopy » est utilisée pour copier le rapport sur le compte de stockage. Ce travail n'est disponible qu'avec les agents sous Windows et lors de l'utilisation de Linux, il renvoie une erreur.

Troisièmement, il y a l’inconvénient de consulter l’historique et les tendances des tests. Le seul historique disponible des rapports est accessible via les notifications Slack, ce qui n'est pas une méthode pratique pour rechercher des tests spécifiques.

Tous les facteurs mentionnés ci-dessus conduisent à la conclusion que le système existant doit être modifié. Plusieurs solutions à ce problème ont donc été envisagées :

1. Création d'une méthode pour générer un fichier .html unifié qui combinerait l'intégralité du projet de rapport Allure en un seul document.

2. Utilisation de services tiers offrant une authentification pour afficher le rapport.

3. Recherche d'une image prédéfinie avec sa propre authentification pour visualiser les rapports.

   
   

Examinons maintenant chacun de ces points plus en détail.

Comme mentionné précédemment, la désactivation de la fonction « accès anonyme » dans le compte de stockage restreint l'accès aux fichiers via le lien pour les utilisateurs non autorisés. Pour fournir un accès à des personnes spécifiques de l'extérieur, Azure lui-même propose plusieurs options possibles, notamment l'octroi de jetons SAS et la configuration des stratégies d'accès. Cependant, en raison de la nature de la génération du rapport Allure, en particulier du fichier index.html, qui fait référence aux scripts JavaScript existants dans la structure du projet :

Lors de l'ouverture du rapport, la page s'avère vide car l'accès entre les fichiers au sein du stockage blob lui-même est restreint.

Pour créer un seul fichier .html, nous avons découvert un image qui, une fois déployé, a facilité la génération du fichier à partir d'un projet Allure entier à l'aide de la commande intégrée "allure-combine ./path/to/allure/generated/report/folder". Cependant, ce processus nécessite que Python soit installé sur l'agent. Malheureusement, cette approche s'est révélée inefficace en raison de l'absence de fichiers joints aux résultats des tests API, éléments cruciaux pour assurer le bon fonctionnement du travail des testeurs.

Il convient également de noter qu'Azure propose une liste blanche IP, qui permet de filtrer les personnes ayant besoin d'un accès. Cependant, comme l’équipe ayant besoin d’un accès ne dispose pas d’adresse IP statique, cette méthode n’était pas adaptée.

Étant donné qu'Allure est une pratique populaire pour collecter des tests dans l'environnement de développement, des services payants sont disponibles en ligne. Par exemple, le service https://qameta.io/ permet le stockage et la génération de rapports Allure dans une interface Web conviviale. Cependant, ces services sont généralement payants et les fonctionnalités requises sont minimes. Nous avons donc considéré cette option de mise en œuvre en dernier recours.

Le choix que nous avons retenu était l'image Docker du service allure-docker ( https://github.com/fescobar/allure-docker-service ) avec la capacité d'intégration du panneau d'interface utilisateur ( https://github.com/fescobar/ allure-docker-service-ui ) avec authentification. La communication avec le service est configurée via HTTP/HTTPS et l'image elle-même prend en charge les fonctionnalités via des requêtes API.

Soulignons quelques avantages de cette solution :

1. Sécurité : la transmission des données est cryptée à l'aide des mécanismes SSL et TLS, et l'image fournit aux utilisateurs intégrés "admin" et "viewer" des informations de connexion qui peuvent être modifiées et fournies aux utilisateurs en fonction de leurs besoins.

2. Commodité : le service est livré avec sa propre interface visuelle offrant diverses fonctionnalités pour travailler avec les rapports Allure.

3. Fonctionnalité : Grâce aux requêtes API, des combinaisons intéressantes peuvent être imaginées avec les pipelines de release côté Azure DevOps. Par exemple, générer un rapport, le télécharger, puis vider le cache en une seule étape.

   
   

En conclusion, notre pipeline de versions ressemble à ceci :

Il convient de noter que nous n'avons pas abandonné l'extension Azure DevOps, qui permet le téléchargement de rapports Allure, car à ce moment-là, nous étions déjà passés à nos propres agents et avions adhéré à l'idée que tout fonctionne « par nous-mêmes ». " Machines.

Concernant le stockage, nous avons expérimenté l'écriture sur des comptes de stockage Azure, en particulier le téléchargement vers File Share, Blob et Blob à l'aide de l'utilitaire azcopy.

Les résultats variaient considérablement. Lors de l’utilisation de la commande File Share az storage file upload-batch, la vitesse d’écriture pour notre test était supérieure à une heure :

Lors de l’utilisation du stockage Blob avec la commande az storage blob upload-batch, les performances ont été multipliées par six, ce qui a pris environ 11 minutes :

Le résultat le plus rapide a été obtenu avec l'outil azcopy :

Bien qu’il utilise l’intégration intégrée d’azcopy dans le pipeline de versions, il est incompatible avec les machines Linux. Cependant, en utilisant la tâche Azure CLI et en installant cet utilitaire sur l’agent, la commande peut être utilisée en toute confiance :

azcopy copie 'SOURCE' 'DESTINATION' --recursive=true

Grâce à la découverte de l'image Allure Docker venue des profondeurs du net, nous avons pu modifier le schéma de stockage et d'affichage des rapports. L'accès aux données est désormais protégé par mot de passe, et la création et le traitement des rapports restent rapides. De plus, du point de vue des utilisateurs (testeurs), les changements sont minimes. La solution fonctionne indépendamment des autres programmes, grâce à un agent distinct dans le cluster, et ne peut pas affecter les autres processus de développement. La rentabilité de cette solution est comparable à celle d’un agent auto-hébergé distinct (15 $, à condition qu’il soit isolé), ce qui est beaucoup moins cher que les alternatives existantes. Par exemple, qameta.io, précédemment considéré, où le prix pour un seul utilisateur est de 30 $/mois.

Écrit par Dmitrijs Gusarovs, ingénieur Middle DevOps chez Social Discovery Group.