Allure Report のセキュリティ問題を解決する方法

詳細で視覚的に魅力的なテスト レポートは、ソフトウェア テスターがテスト結果を理解し、情報に基づいた決定を下すために不可欠です。Social Discovery Group のチームは、細部にまで細心の注意を払い、すべての答えを持っているように思えるオープン ソースの強力なツールである Allure Reports の助けを借りて、視覚的に魅力的なテスト レポートを作成します。しかし、セキュリティという欠陥が見つかりました。リンクを持っている人なら誰でも内部を覗くことができ、サブシステム間の適応性が欠けていました。この記事では、SDG テスト チームが、適切な Allure Docker を作成し、ストレージ スキームを変更することで、Allure レポートのセキュリティ問題を解決した方法を紹介します。

SDG 開発環境は Microsoft 製品をベースとしており、CI/CD プロセスの実行には Azure DevOps が活用されています。CI パイプラインを通じて自動テストのリポジトリが構築され、その後、テスト実行のテスターの好みに基づいて複数の CD パイプラインを介して分類されます。

当初設定されたスキームを考えてみましょう。

このセットアップでは、CD パイプラインは 2 つの Allure レポートのジェネレーターとしても機能します。1 つは Slack 通知用で、ステージとテスト カテゴリを指定する読みやすいリンクをテスターに提供します。もう 1 つは Allure レポートを Azure DevOps にエクスポートするためのものです。

これは、Azure DevOps に拡張機能をインストールすることで実現され、レポートの生成と、Azure ストレージ アカウント内の静的 Web サイトの $web コンテナーへのアップロードが可能になります。匿名アクセスの構成を有効にすると、レポートをリンク経由で表示できるようになります。

さらに利便性を高めるために、ビルド パイプラインで Allure レポートを表示するための追加のプラグインも使用されました。

この方式は機能的ですが、いくつかの欠点があります。

まず、この方法では、Allure レポートはリンクを持つ誰でもアクセスできるため、セキュリティが不十分です。テストによっては、レポートにサービスに関する機密情報、その脆弱性、および一般からのアクセスを制限すべきその他の機密データが含まれる場合があります。Azure ストレージ アカウントで「匿名アクセス」フラグが有効になっているため、誰でもアドレスにアクセスでき、一般アクセスが許可されます。この機能を無効にすると、権限のない個人によるファイルへの外部アクセスは停止されますが、Azure DevOps ページでレポートにアクセスできなくなります。

第二に、この方法はサブシステム間で普遍的に適用できるわけではありません。CD パイプラインのジョブの一覧を調べると、ネイティブ ジョブ「azcopy」がレポートをストレージ アカウントにコピーするために使用されていることがわかります。このジョブは Windows 上のエージェントでのみ使用可能であり、Linux を使用するとエラーが返されます。

3 つ目は、テストの履歴と傾向を確認するのが不便なことです。レポートの履歴は Slack 通知を通じてのみアクセス可能で、特定のテストを見つけるのに便利な方法ではありません。

上記のすべての要因から、既存のシステムを変更する必要があるという結論に至りました。そのため、この問題に対するいくつかの解決策が検討されました。

1. Allure レポート プロジェクト全体を 1 つのドキュメントに結合する統合 .html ファイルを生成する方法を作成します。

2. レポートを表示するための認証を提供するサードパーティのサービスを利用する。

3. レポートを表示するための独自の認証を備えた事前作成されたイメージを検索します。

   
   

それでは、それぞれのポイントについてさらに詳しく見ていきましょう。

前述のように、ストレージ アカウントの「匿名アクセス」機能を無効にすると、権限のないユーザーによるリンク経由のファイルへのアクセスが制限されます。外部から特定の個人にアクセスを提供するには、Azure 自体にいくつかのオプションが用意されています。これには、SAS トークンの付与やアクセス ポリシーの構成が含まれます。ただし、Allure レポートを生成する性質上、具体的には、プロジェクト構造内の既存の JavaScript スクリプトを参照する index.html ファイルにより、次のようになります。

レポートを開くと、BLOB ストレージ自体内のファイル間のアクセスが制限されているため、ページが空になります。

単一の.htmlファイルを作成するために、画像これをデプロイすると、埋め込みコマンド「allure-combine ./path/to/allure/generated/report/folder」を使用して、Allure プロジェクト全体からファイルを生成できるようになります。ただし、このプロセスでは、エージェントに Python がインストールされている必要があります。残念ながら、このアプローチは、テスターの作業が適切に機能するための重要なコンポーネントである API テストの結果に添付されたファイルがないため、効果的ではないことが判明しました。

Azure では、アクセスを必要とする個人をフィルタリングできる IP ホワイトリストが提供されていることも注目に値します。ただし、アクセスを必要とするチームには静的 IP アドレスがないため、この方法は適切ではありませんでした。

Allure は開発環境でテストを収集するための一般的な方法であるため、オンラインで利用できる有料サービスがあります。たとえば、 https://qameta.io/というサービスは、ユーザーフレンドリーな Web インターフェイスで Allure レポートの保存と生成を提供します。ただし、このようなサービスは通常有料であり、必要な機能は最小限です。そのため、この実装オプションは最後の手段として検討しました。

私たちが選んだのは、認証機能を備えたユーザー インターフェイス パネル ( https://github.com/fescobar/allure-docker-service-ui ) の統合機能を備えた allure-docker サービス Docker イメージ ( https://github.com/fescobar/allure-docker-service ) でした。サービスとの通信は HTTP/HTTPS 経由で構成され、イメージ自体は API リクエストによる機能をサポートしています。

このソリューションの利点をいくつか紹介します。

1. セキュリティ: データ転送は SSL および TLS メカニズムを使用して暗号化され、イメージは組み込みユーザー「admin」および「viewer」にログイン資格情報を提供します。この資格情報は、ユーザーのニーズに応じて変更および提供できます。

2. 利便性: このサービスには、Allure レポートを操作するためのさまざまな機能を提供する独自のビジュアル インターフェイスが付属しています。

3. 機能: API リクエストのおかげで、Azure DevOps 側のリリース パイプラインとの興味深い組み合わせを考案できます。たとえば、レポートを生成し、アップロードし、1 つのステージ内でキャッシュをクリアするなどです。

   
   

結論として、私たちのリリース パイプラインは次のようになります。

注目すべきは、Allure レポートのアップロードを可能にする Azure DevOps 拡張機能から移行しなかったことです。その時点で、私たちはすでに独自のエージェントに移行しており、すべてを「独自の」マシンで動作させるという考え方に固執していたからです。

ストレージに関しては、Azure ストレージ アカウントへの書き込み、具体的には azcopy ユーティリティを使用してファイル共有、BLOB、BLOB にアップロードする実験を行いました。

結果は大きく異なりました。ファイル共有コマンド az storage file upload-batch を使用した場合、テストの書き込み速度は 1 時間を超えました。

az storage blob upload-batch コマンドで Blob Storage を使用すると、パフォーマンスが 6 倍向上し、所要時間は約 11 分になりました。

最も速い結果は azcopy ツールによるものでした:

リリース パイプラインで azcopy の組み込み統合を使用する場合、Linux マシンとは互換性がありません。ただし、Azure CLI ジョブを使用し、このユーティリティをエージェントにインストールすることで、コマンドを自信を持って使用できます。

azcopy コピー 'ソース' '宛先' --recursive=true

ネットの奥深くから Allure Docker イメージを発見したおかげで、レポートの保存と表示スキームを変更することができました。データ アクセスはパスワードで保護されるようになり、レポートの作成と処理は高速のままです。さらに、ユーザー (テスター) の観点からは、変更は最小限です。このソリューションは、クラスター内の別のエージェントのおかげで他のプログラムから独立して動作し、他の開発プロセスに影響を与えることはありません。このソリューションのコスト効率は、別のセルフホスト エージェント (分離されている場合は 15 ドル) と同等で、既存の代替手段よりもはるかに安価です。たとえば、以前に検討した qameta.io では、1 ユーザーあたりの価格は月額 30 ドルです。

著者は、Social Discovery Group の中級 DevOps エンジニア、Dmitrijs Gusarovs です。