So lösen Sie Sicherheitsprobleme beim Allure-Bericht

Detaillierte und optisch ansprechende Testberichte sind für Softwaretester entscheidend, um Testergebnisse zu verstehen und fundierte Entscheidungen zu treffen. Mit akribischer Liebe zum Detail erstellt das Team der Social Discovery Group visuell ansprechende Testberichte mithilfe von Allure Reports – dem Open-Source-Kraftpaket, das alle Antworten zu haben schien. Doch wir entdeckten einen Fehler: die Sicherheit. Jeder mit einem Link konnte einen Blick hineinwerfen, und die Anpassungsfähigkeit an Subsysteme war mangelhaft. In diesem Artikel berichtet das SDG-Testteam, wie es die Sicherheitsprobleme der Allure-Berichte lösen konnte, indem es einen richtigen Allure-Docker erstellte und das Speicherschema änderte.

Die SDG-Entwicklungsumgebung basiert auf Microsoft-Produkten, wobei Azure DevOps zur Ausführung von CI/CD-Prozessen verwendet wird. Über die CI-Pipeline wird das Repository automatisierter Tests erstellt, gefolgt von einer Kategorisierung über mehrere CD-Pipelines basierend auf den Präferenzen der Tester für Testläufe.

Betrachten wir das Schema, wie es ursprünglich eingerichtet wurde:

In diesem Setup dient die CD-Pipeline auch als Generator für zwei Allure-Berichte: einen für Slack-Benachrichtigungen, der Testern einen bequem lesbaren Link mit Angaben zu Phasen und Testkategorien bietet, und einen anderen zum Exportieren des Allure-Berichts nach Azure DevOps.

Dies wird durch die Installation einer Erweiterung in Azure DevOps erreicht, die die Berichtserstellung und den anschließenden Upload in den $web-Container für statische Websites im Azure-Speicherkonto ermöglicht. Die aktivierte Konfiguration des anonymen Zugriffs ermöglicht die Anzeige des Berichts über einen Link.

Für zusätzlichen Komfort wurde auch ein zusätzliches Plug-In verwendet, um den Allure-Bericht in der Build-Pipeline anzuzeigen.

Dieses Schema funktioniert zwar, weist aber bestimmte Nachteile auf:

Erstens ist diese Methode nicht sicher, da die Allure-Berichte für jeden mit dem Link zugänglich sind. Je nach Test kann der Bericht vertrauliche Informationen über Dienste, ihre Schwachstellen und andere sensible Daten enthalten, die nicht öffentlich zugänglich sein sollten. Allgemeiner Zugriff wird gewährt, da das Flag „anonymer Zugriff“ im Azure-Speicherkonto aktiviert ist, wodurch jeder auf die Adresse zugreifen kann. Das Deaktivieren dieser Funktion würde den externen Zugriff auf die Dateien für unbefugte Personen unterbinden, aber auch den Bericht auf der Azure DevOps-Seite unzugänglich machen.

Zweitens ist die Methode nicht universell auf alle Subsysteme anwendbar. Wenn wir die Liste der Jobs in der CD-Pipeline untersuchen, sehen wir, dass der native Job „azcopy“ verwendet wird, um den Bericht in das Speicherkonto zu kopieren. Dieser Job ist nur mit Agenten unter Windows verfügbar und gibt bei Verwendung von Linux einen Fehler zurück.

Drittens ist es umständlich, Testverläufe und Trends anzuzeigen. Der einzige verfügbare Berichtsverlauf ist über Slack-Benachrichtigungen zugänglich, was keine praktische Methode ist, um bestimmte Tests zu finden.

Alle oben genannten Faktoren führten zu dem Schluss, dass das bestehende System geändert werden muss. Daher wurden mehrere Lösungen für dieses Problem in Betracht gezogen:

1. Erstellen einer Methode zum Generieren einer einheitlichen HTML-Datei, die das gesamte Allure-Berichtsprojekt in einem Dokument zusammenfasst.

2. Nutzung von Diensten von Drittanbietern, die eine Authentifizierung zum Anzeigen des Berichts anbieten.

3. Suche nach einem vorgefertigten Bild mit eigener Authentifizierung zum Anzeigen von Berichten.

   
   

Lassen Sie uns nun auf jeden dieser Punkte genauer eingehen.

Wie bereits erwähnt, beschränkt das Deaktivieren der Funktion „anonymer Zugriff“ im Speicherkonto den Zugriff auf Dateien über den Link für nicht autorisierte Benutzer. Um bestimmten Personen von außen Zugriff zu gewähren, bietet Azure selbst mehrere mögliche Optionen – dazu gehören die Gewährung von SAS-Tokens und die Konfiguration von Zugriffsrichtlinien. Aufgrund der Art der Generierung des Allure-Berichts, insbesondere der Datei index.html, die auf vorhandene JavaScript-Skripte in der Projektstruktur verweist, gilt jedoch Folgendes:

Beim Öffnen des Berichts stellt sich heraus, dass die Seite leer ist, da der Zugriff zwischen Dateien innerhalb des Blob-Speichers selbst eingeschränkt ist.

Um eine einzelne HTML-Datei zu erstellen, haben wir eine Bild das bei der Bereitstellung die Generierung der Datei aus einem gesamten Allure-Projekt mithilfe des eingebetteten Befehls „allure-combine ./Pfad/zu/allure/generiertem/Berichtsordner“ erleichterte. Dieser Vorgang erfordert jedoch, dass auf dem Agenten Python installiert ist. Leider erwies sich dieser Ansatz als ineffektiv, da den Ergebnissen der API-Tests keine Dateien beigefügt waren, die für die ordnungsgemäße Funktion der Arbeit der Tester von entscheidender Bedeutung sind.

Es ist auch erwähnenswert, dass Azure IP-Whitelists bietet, mit denen Personen gefiltert werden können, die Zugriff benötigen. Da das Team, das Zugriff benötigt, jedoch keine statische IP-Adresse hat, war diese Methode nicht geeignet.

Da Allure eine beliebte Methode zum Sammeln von Tests in der Entwicklungsumgebung ist, stehen online kostenpflichtige Dienste zur Verfügung. Beispielsweise bietet der Dienst https://qameta.io/ die Speicherung und Generierung von Allure-Berichten in einer benutzerfreundlichen Weboberfläche. Solche Dienste sind jedoch in der Regel kostenpflichtig und die erforderliche Funktionalität ist minimal. Daher haben wir diese Implementierungsoption als letzten Ausweg betrachtet.

Wir haben uns für das Docker-Image des Allure-Docker-Dienstes ( https://github.com/fescobar/allure-docker-service ) mit der Integrationsfunktion des Benutzeroberflächen-Panels ( https://github.com/fescobar/allure-docker-service-ui ) mit Authentifizierung entschieden. Die Kommunikation mit dem Dienst wird über HTTP/HTTPS konfiguriert und das Image selbst unterstützt die Funktionalität über API-Anfragen.

Lassen Sie uns einige Vorteile dieser Lösung hervorheben:

1. Sicherheit: Die Datenübertragung wird mithilfe von SSL- und TLS-Mechanismen verschlüsselt und das Image stellt den integrierten Benutzern „Admin“ und „Viewer“ Anmeldeinformationen zur Verfügung, die geändert und den Benutzern je nach Bedarf zur Verfügung gestellt werden können.

2. Komfort: Der Dienst verfügt über eine eigene visuelle Benutzeroberfläche, die verschiedene Funktionen für die Arbeit mit Allure-Berichten bietet.

3. Funktionalität: Dank API-Anfragen können interessante Kombinationen mit Release-Pipelines auf der Azure DevOps-Seite entwickelt werden. Beispielsweise das Generieren eines Berichts, dessen Hochladen und anschließendes Leeren des Caches in einer einzigen Phase.

   
   

Zusammenfassend sieht unsere Release-Pipeline folgendermaßen aus:

Es ist erwähnenswert, dass wir uns nicht von der Azure DevOps-Erweiterung verabschiedet haben, die das Hochladen von Allure-Berichten ermöglicht, da wir zu diesem Zeitpunkt bereits auf unsere eigenen Agenten umgestiegen waren und an der Idee festhielten, dass alles „auf unseren eigenen“ Maschinen läuft.

In Bezug auf den Speicher haben wir mit dem Schreiben auf Azure-Speicherkonten experimentiert, insbesondere mit dem Hochladen auf File Share, Blob und Blob mithilfe des Dienstprogramms „azcopy“.

Die Ergebnisse variierten erheblich. Bei Verwendung des Befehls für File Share az storage file upload-batch betrug die Schreibgeschwindigkeit für unseren Test über eine Stunde:

Bei Verwendung von Blob Storage mit dem Befehl az storage blob upload-batch verbesserte sich die Leistung um das Sechsfache und dauerte ungefähr 11 Minuten:

Das schnellste Ergebnis wurde mit dem Tool Azcopy erzielt:

Bei Verwendung der integrierten Integration von azcopy in der Releasepipeline ist es nicht mit Linux-Computern kompatibel. Wenn Sie jedoch den Azure CLI-Job verwenden und dieses Dienstprogramm auf dem Agent installieren, kann der Befehl problemlos verwendet werden:

azcopy kopiert „QUELLE“ „ZIEL“ – recursive=true

Dank der Entdeckung des Allure Docker-Images aus den Tiefen des Netzes konnten wir das Speicher- und Anzeigeschema von Berichten ändern. Der Datenzugriff ist jetzt passwortgeschützt und die Erstellung und Verarbeitung von Berichten bleibt schnell. Darüber hinaus sind die Änderungen aus Sicht der Benutzer (Tester) minimal. Die Lösung arbeitet dank eines separaten Agenten im Cluster unabhängig von anderen Programmen und kann andere Entwicklungsprozesse nicht beeinträchtigen. Die Kosteneffizienz dieser Lösung ist vergleichbar mit der eines separaten, selbst gehosteten Agenten (15 $, sofern er isoliert ist), der viel günstiger ist als bestehende Alternativen. Beispielsweise das zuvor betrachtete qameta.io, bei dem der Preis für einen einzelnen Benutzer 30 $/Monat beträgt.

Geschrieben von Dmitrijs Gusarovs, Middle DevOps Engineer bei der Social Discovery Group.