如何解决Allure报告安全问题

详细且视觉上有吸引力的测试报告对于软件测试人员了解测试结果并做出明智的决策至关重要。Social Discovery Group 团队一丝不苟地关注细节，在 Allure Reports（似乎拥有所有答案的开源巨头）的帮助下制作出视觉上引人入胜的测试报告。然而，我们发现了一个缺陷：安全性。任何有链接的人都可以窥视内部，而且它在子系统之间的适应性不足。在本文中，SDG 测试团队分享了他们如何通过创建适当的 Allure Docker 并修改存储方案来解决 Allure 报告安全问题。

SDG 的开发环境基于微软产品，使用 Azure DevOps 执行 CI/CD 流程，通过 CI 流水线构建自动化测试仓库，再根据测试人员对测试运行的偏好通过多条 CD 流水线进行分类。

让我们考虑一下该方案最初设立的样子：

在此设置中，CD 管道还可作为两个 Allure 报告的生成器：一个用于 Slack 通知，为测试人员提供方便阅读的链接，指定阶段和测试类别；另一个用于将 Allure 报告导出到 Azure DevOps。

这是通过在 Azure DevOps 中安装扩展来实现的，该扩展可以生成报告并随后将其上传到 Azure 存储帐户中静态网站的 $web 容器。启用匿名访问的配置允许通过链接显示报告。

为了增加便利性，还使用了附加插件在构建管道中显示 Allure 报告。

虽然该方案可行，但也存在一些缺点：

首先，这种方法缺乏安全性，因为任何有链接的人都可以访问 Allure 报告。根据测试，报告可能包含有关服务、其漏洞以及任何其他应禁止公开访问的敏感数据的机密信息。由于 Azure 存储帐户中启用了“匿名访问”标志，因此授予了一般访问权限，该标志允许任何人访问该地址。禁用此功能将阻止未经授权的个人从外部访问文件，但也会导致 Azure DevOps 页面上的报告无法访问。

其次，该方法并不适用于所有子系统。如果我们检查 CD 管道中的作业列表，我们会看到本机作业“azcopy”用于将报告复制到存储帐户。此作业仅适用于 Windows 上的代理，使用 Linux 时会返回错误。

第三，查看测试历史和趋势很不方便。唯一可用的报告历史记录是通过 Slack 通知访问的，这不是一种查找特定测试的便捷方法。

所有上述因素都导致我们得出结论，现有系统需要修改。因此，我们考虑了几种解决方案：

1. 创建一种方法来生成统一的.html 文件，将整个 Allure 报告项目合并为一个文档。

2. 利用提供身份验证以查看报告的第三方服务。

3. 搜索具有自身身份验证的预制图像以查看报告。

   
   

现在，让我们更详细地探讨每一个要点。

如前所述，禁用存储帐户中的“匿名访问”功能会限制未经授权的用户通过链接访问文件。为了从外部向特定个人提供访问权限，Azure 本身提供了几种可能的选项 - 其中包括授予 SAS 令牌和配置访问策略。但是，由于生成 Allure 报告的性质，特别是 index.html 文件，它引用了项目结构中的现有 JavaScript 脚本：

打开报告时，页面是空的，因为 Blob 存储本身内的文件之间的访问受到限制。

为了创建一个 .html 文件，我们发现了一个图像部署后，使用嵌入式命令“allure-combine ./path/to/allure/generated/report/folder”可从整个 Allure 项目生成文件。但是，此过程要求代理安装 Python。不幸的是，由于缺少附加到 API 测试结果的文件，这种方法被证明是无效的，而这些文件是确保测试人员工作正常运行的关键组件。

还值得注意的是，Azure 提供 IP 白名单功能，允许筛选需要访问权限的个人。但是，由于需要访问权限的团队没有静态 IP 地址，因此这种方法并不合适。

考虑到 Allure 是一种在开发环境中收集测试的流行做法，网上有付费服务。例如，服务https://qameta.io/在用户友好的 Web 界面中提供 Allure 报告的存储和生成。但是，此类服务通常是付费的，并且所需的功能很少。因此，我们将此实施选项视为最后的手段。

我们最终选择了 allure-docker 服务 Docker 镜像 ( https://github.com/fescobar/allure-docker-service )，该镜像具有集成用户界面面板 ( https://github.com/fescobar/allure-docker-service-ui ) 和身份验证的功能。与服务的通信通过 HTTP/HTTPS 配置，镜像本身通过 API 请求支持功能。

让我们重点介绍一下此解决方案的一些优点：

1. 安全性：数据传输采用SSL和TLS机制加密，并且镜像为内置用户“admin”和“viewer”提供了登录凭证，可以根据用户的需求进行修改并提供给用户。

2. 便利性：该服务带有自己的可视化界面，提供处理 Allure 报告的各种功能。

3. 功能：借助 API 请求，可以使用 Azure DevOps 端的发布管道设计有趣的组合。例如，在单个阶段内生成报告、上传报告，然后清除缓存。

   
   

综上所述，我们的发布流程如下：

值得注意的是，我们并没有放弃允许上传 Allure 报告的 Azure DevOps 扩展，因为那时我们已经过渡到我们自己的代理，并坚持让一切“在我们自己的”机器上工作的想法。

关于存储，我们尝试写入 Azure 存储帐户，特别是使用 azcopy 实用程序上传到文件共享、Blob 和 Blob。

结果差异很大。使用文件共享 az storage file upload-batch 命令时，我们测试的写入速度超过一小时：

当使用 Blob Storage 和 az storage blob upload-batch 命令时，性能提高了六倍，大约需要 11 分钟：

最快的结果是通过 azcopy 工具获得的：

虽然在发布管道中使用了内置的 azcopy 集成，但它与 Linux 计算机不兼容。但是，通过使用 Azure CLI 作业并在代理上安装此实用程序，可以放心使用该命令：

azcopy 复制“源”“目标”--recursive = true

得益于从网络深处发现的 Allure Docker 镜像，我们能够修改报告的存储和显示方案。数据访问现在受密码保护，报告创建和处理仍然很快。此外，从用户（测试人员）的角度来看，更改很小。由于集群中有一个单独的代理，该解决方案独立于其他程序运行，并且不会影响其他开发过程。该解决方案的成本效益与单独的自托管代理（15 美元，前提是它是隔离的）相当，这比现有的替代方案便宜得多。例如，之前考虑过的 qameta.io，单个用户的价格为 30 美元/月。

作者是 Social Discovery Group 的中层 DevOps 工程师 Dmitrijs Gusarovs。