Como resolver problemas de segurança do relatório Allure

Relatórios de teste detalhados e visualmente atraentes são cruciais para que os testadores de software entendam os resultados dos testes e tomem decisões informadas. Com atenção meticulosa aos detalhes, a equipe do Social Discovery Group cria relatórios de teste visualmente cativantes com a ajuda do Allure Reports – a potência do código aberto que parecia ter todas as respostas. No entanto, descobrimos uma falha: segurança. Qualquer pessoa com um link poderia espiar o interior, e faltava sua adaptabilidade entre subsistemas. Neste artigo, a equipe de testes do SDG compartilha como eles conseguiram resolver problemas de segurança de relatórios do Allure criando um Allure Docker adequado e modificando o esquema de armazenamento.

O ambiente de desenvolvimento SDG é baseado em produtos Microsoft, com Azure DevOps utilizado para executar processos de CI/CD. Por meio do pipeline de CI, é construído o repositório de testes automatizados, seguido da categorização por meio de diversos pipelines de CD com base nas preferências dos testadores para execução de testes.

Vamos considerar o esquema tal como foi originalmente configurado:

Nessa configuração, o pipeline de CD também serve como gerador para dois relatórios do Allure: um para notificações do Slack, fornecendo aos testadores um link convenientemente legível especificando estágios e categorias de teste, e outro para exportar o relatório do Allure para o Azure DevOps.

Isto é conseguido através da instalação de uma extensão no Azure DevOps, que permite a geração de relatórios e posterior upload para o contentor $web para sites estáticos na conta de armazenamento do Azure. A configuração habilitada de acesso anônimo permite que o relatório seja exibido através de um link.

Para maior comodidade, um plugin adicional também foi usado para exibir o relatório Allure no pipeline de construção.

Embora este esquema seja funcional, ele tem algumas desvantagens:

Em primeiro lugar, este método carece de segurança, pois os relatórios do Allure são acessíveis a qualquer pessoa com o link. Dependendo do teste, o relatório pode conter informações confidenciais sobre serviços, suas vulnerabilidades e quaisquer outros dados confidenciais cujo acesso público deva ser restrito. O acesso geral é concedido devido ao sinalizador de "acesso anônimo" habilitado na conta de armazenamento do Azure, que fornece a qualquer pessoa acesso ao endereço. Desabilitar essa função interromperia o acesso externo aos arquivos para indivíduos não autorizados, mas também tornaria o relatório inacessível na página do Azure DevOps.

Em segundo lugar, o método não é universalmente aplicável em todos os subsistemas. Se examinarmos a lista de trabalhos no pipeline do CD, veremos que o trabalho nativo "azcopy" é usado para copiar o relatório para a conta de armazenamento. Este trabalho está disponível apenas com agentes no Windows e, ao usar Linux, retorna um erro.

Em terceiro lugar, há a inconveniência de visualizar o histórico e as tendências dos testes. O único histórico de relatórios disponível pode ser acessado por meio de notificações do Slack, o que não é um método conveniente para encontrar testes específicos.

Todos os factores acima mencionados levaram à conclusão de que o sistema existente necessita de ser modificado. Portanto, foram consideradas diversas soluções para este problema:

1. Criação de um método para gerar um arquivo .html unificado que combinaria todo o projeto de relatório do Allure em um documento.

2. Utilizar serviços de terceiros que oferecem autenticação para visualização do relatório.

3. Busca de imagem pré-fabricada com autenticação própria para visualização de relatórios.

   
   

Agora, vamos nos aprofundar em cada um desses pontos com mais detalhes.

Conforme mencionado anteriormente, desabilitar a função de “acesso anônimo” na conta de armazenamento restringe o acesso aos arquivos através do link para usuários não autorizados. Para fornecer acesso a indivíduos específicos de fora, o próprio Azure oferece várias opções possíveis - incluindo a concessão de tokens SAS e a configuração de políticas de acesso. No entanto, devido à natureza da geração do relatório Allure, especificamente do arquivo index.html, que faz referência a scripts JavaScript existentes na estrutura do projeto:

Ao abrir o relatório, a página fica vazia porque o acesso entre arquivos dentro do próprio armazenamento de blobs é restrito.

Para criar um único arquivo .html, descobrimos um imagem que, quando implantado, facilitou a geração do arquivo de um projeto Allure inteiro usando o comando incorporado "allure-combine ./path/to/allure/generated/report/folder". No entanto, este processo requer que o agente tenha o Python instalado. Infelizmente, esta abordagem mostrou-se ineficaz devido à ausência de arquivos anexados aos resultados dos testes da API, componentes cruciais para garantir o bom funcionamento do trabalho dos testadores.

Também é importante notar que o Azure oferece lista de permissões de IP, que permite a filtragem de indivíduos que necessitam de acesso. Porém, como a equipe que necessita de acesso não possui um endereço IP estático, esse método não era adequado.

Considerando que o Allure é uma prática popular de coleta de testes no ambiente de desenvolvimento, existem serviços pagos disponíveis online. Por exemplo, o serviço https://qameta.io/ fornece armazenamento e geração de relatórios Allure em uma interface web amigável. No entanto, esses serviços são normalmente pagos e a funcionalidade necessária é mínima. Portanto, consideramos esta opção de implementação como último recurso.

A escolha que escolhemos foi a imagem Docker do serviço allure-docker ( https://github.com/fescobar/allure-docker-service ) com a capacidade de integração do painel de interface do usuário ( https://github.com/fescobar/ allure-docker-service-ui ) com autenticação. A comunicação com o serviço é configurada via HTTP/HTTPS, e a própria imagem oferece suporte à funcionalidade por meio de solicitações de API.

Vamos destacar algumas vantagens desta solução:

1. Segurança: A transmissão de dados é criptografada usando mecanismos SSL e TLS, e a imagem fornece aos usuários integrados "admin" e "visualizador" credenciais de login que podem ser modificadas e fornecidas aos usuários com base em suas necessidades.

2. Conveniência: O serviço vem com interface visual própria que oferece diversas funcionalidades para trabalhar com relatórios Allure.

3. Funcionalidade: graças às solicitações de API, combinações interessantes podem ser criadas com pipelines de lançamento no lado do Azure DevOps. Por exemplo, gerar um relatório, carregá-lo e limpar o cache em um único estágio.

   
   

Concluindo, nosso pipeline de lançamento é assim:

Vale ressaltar que não nos afastamos da extensão Azure DevOps, que permite o upload de relatórios Allure, pois nessa época já havíamos feito a transição para nossos próprios agentes e aderido à ideia de ter tudo funcionando "por conta própria "máquinas.

Em relação ao armazenamento, experimentamos gravar em contas de armazenamento do Azure, carregando especificamente para File Share, Blob e Blob usando o utilitário azcopy.

Os resultados variaram significativamente. Ao usar o comando para File Share az storage file upload-batch, a velocidade de gravação para nosso teste foi superior a uma hora:

Ao utilizar o Blob Storage com o comando az storage blob upload-batch, o desempenho melhorou seis vezes, demorando aproximadamente 11 minutos:

O resultado mais rápido foi pela ferramenta azcopy:

Embora use a integração interna do azcopy no pipeline de lançamento, ele é incompatível com máquinas Linux. No entanto, ao utilizar o trabalho Azure CLI e instalar este utilitário no agente, o comando pode ser empregue com confiança:

azcopy copy 'FONTE' 'DESTINO' --recursive=true

Graças à descoberta da imagem Allure Docker nas profundezas da rede, conseguimos modificar o esquema de armazenamento e exibição dos relatórios. O acesso aos dados agora é protegido por senha e a criação e o processamento de relatórios permanecem rápidos. Além disso, do ponto de vista dos utilizadores (testadores), as mudanças são mínimas. A solução opera independentemente de outros programas, graças a um agente separado no cluster, e não pode afetar outros processos de desenvolvimento. A relação custo-benefício desta solução é comparável à de um agente auto-hospedado separado (US$ 15, desde que isolado), que é muito mais barato do que as alternativas existentes. Por exemplo, o anteriormente considerado qameta.io, onde o preço para um único usuário é de US$ 30/mês.

Escrito por Dmitrijs Gusarovs, engenheiro Middle DevOps do Social Discovery Group.