Как решить проблемы безопасности отчета Allure

Подробные и визуально привлекательные отчеты об испытаниях имеют решающее значение для тестировщиков программного обеспечения, поскольку они позволяют понять результаты испытаний и принять обоснованные решения. С тщательным вниманием к деталям команда Social Discovery Group создает визуально привлекательные отчеты об испытаниях с помощью Allure Reports — мощной платформы с открытым исходным кодом, в которой, казалось, есть ответы на все вопросы. Тем не менее, мы обнаружили недостаток: безопасность. Любой, у кого была ссылка, мог заглянуть внутрь, а адаптируемость к различным подсистемам отсутствовала. В этой статье группа тестирования SDG рассказывает, как им удалось решить проблемы безопасности отчетов Allure, создав правильный Allure Docker и изменив схему хранения.

Среда разработки SDG основана на продуктах Microsoft, а Azure DevOps используется для выполнения процессов CI/CD. Посредством CI-конвейера создается репозиторий автоматических тестов с последующей категоризацией по нескольким CD-конвейерам на основе предпочтений тестировщиков при выполнении тестов.

Рассмотрим схему в том виде, в котором она была изначально настроена:

В этой настройке конвейер CD также служит генератором двух отчетов Allure: один для уведомлений Slack, предоставляющий тестировщикам удобочитаемую ссылку с указанием этапов и категорий тестов, а другой для экспорта отчета Allure в Azure DevOps.

Это достигается за счет установки расширения в Azure DevOps, которое позволяет создавать отчеты и последующую загрузку в контейнер $web для статических веб-сайтов в учетной записи хранения Azure. Включенная конфигурация анонимного доступа позволяет отображать отчет по ссылке.

Для дополнительного удобства также был использован дополнительный плагин для отображения отчета Allure в конвейере сборки.

Данная схема функциональна, но имеет определенные недостатки:

Во-первых, этому методу не хватает безопасности, поскольку отчеты Allure доступны любому, у кого есть ссылка. В зависимости от теста отчет может содержать конфиденциальную информацию о сервисах, их уязвимостях и любые другие конфиденциальные данные, к которым следует ограничить публичный доступ. Общий доступ предоставляется благодаря включенному флагу «анонимного доступа» в учетной записи хранения Azure, который предоставляет любому пользователю доступ к адресу. Отключение этой функции прекратит внешний доступ к файлам для неавторизованных лиц, но также сделает отчет недоступным на странице Azure DevOps.

Во-вторых, метод не универсально применим ко всем подсистемам. Если мы рассмотрим список заданий в конвейере CD, мы увидим, что собственное задание «azcopy» используется для копирования отчета в учетную запись хранения. Это задание доступно только для агентов в Windows, а при использовании Linux оно возвращает ошибку.

В-третьих, неудобно просматривать историю испытаний и тенденции. Единственная доступная история отчетов доступна через уведомления Slack, что не является удобным способом поиска конкретных тестов.

Все вышеперечисленные факторы позволили сделать вывод о том, что существующая система нуждается в модификации. Поэтому было рассмотрено несколько вариантов решения этой проблемы:

1. Создание метода создания единого файла .html, который объединит весь проект отчета Allure в один документ.

2. Использование сторонних сервисов, предлагающих аутентификацию для просмотра отчета.

3. Поиск готового изображения со своей аутентификацией для просмотра отчетов.

   
   

Теперь давайте углубимся в каждый из этих пунктов более подробно.

Как говорилось ранее, отключение функции «анонимного доступа» в учетной записи хранения ограничивает доступ к файлам по ссылке для неавторизованных пользователей. Чтобы предоставить доступ конкретным лицам извне, сама Azure предлагает несколько возможных вариантов — в их число входят предоставление токенов SAS и настройка политик доступа. Однако из-за особенностей создания отчета Allure, в частности файла index.html, который ссылается на существующие сценарии JavaScript в структуре проекта:

При открытии отчета страница оказывается пустой, поскольку доступ между файлами внутри самого хранилища BLOB-объектов ограничен.

Чтобы создать один файл .html, мы обнаружили изображение это при развертывании облегчило создание файла из всего проекта Allure с помощью встроенной команды «allure-combine ./path/to/allure/generated/report/folder». Однако для этого процесса требуется, чтобы на агенте был установлен Python. К сожалению, такой подход оказался неэффективным из-за отсутствия файлов, прикрепленных к результатам тестов API, которые являются важнейшими компонентами для обеспечения корректной работы тестировщиков.

Также стоит отметить, что Azure предлагает белый список IP-адресов, который позволяет фильтровать лиц, которым требуется доступ. Однако, поскольку у команды, нуждающейся в доступе, нет статического IP-адреса, этот метод не подошел.

Учитывая, что Allure — популярная практика сбора тестов в среде разработки, в Интернете доступны платные сервисы. Например, сервис https://qameta.io/ обеспечивает хранение и формирование отчетов Allure в удобном веб-интерфейсе. Однако такие услуги обычно платные, а требуемый функционал минимален. Поэтому мы рассматривали этот вариант реализации в крайнем случае.

Мы остановились на образе Docker сервиса allure-docker ( https://github.com/fescobar/allure-docker-service ) с возможностью интеграции панели пользовательского интерфейса ( https://github.com/fescobar/ allure-docker-service-ui ) с аутентификацией. Связь с сервисом настраивается через HTTP/HTTPS, а сам образ поддерживает функциональность через запросы API.

Выделим некоторые преимущества данного решения:

1. Безопасность: передача данных шифруется с использованием механизмов SSL и TLS, а образ предоставляет встроенным пользователям «администратор» и «просмотрщик» учетные данные для входа, которые можно изменить и предоставить пользователям в зависимости от их потребностей.

2. Удобство: Сервис имеет собственный визуальный интерфейс, предлагающий различные функциональные возможности для работы с отчетами Allure.

3. Функциональность. Благодаря запросам API можно создавать интересные комбинации с конвейерами выпуска на стороне Azure DevOps. Например, создание отчета, его загрузка и последующая очистка кеша за один этап.

   
   

В заключение наш конвейер релизов выглядит так:

Стоит отметить, что мы не отошли от расширения Azure DevOps, позволяющего выгружать отчеты Allure, так как к тому времени уже перешли на собственных агентов и придерживались идеи, чтобы все работало «самостоятельно». "машины.

Что касается хранилища, мы экспериментировали с записью в учетные записи хранения Azure, в частности с загрузкой в File Share, Blob и Blob с помощью утилиты azcopy.

Результаты существенно различались. При использовании команды пакетной загрузки файлов File Share az Storage скорость записи в нашем тесте составила более часа:

При использовании хранилища BLOB-объектов с пакетной командой az Storage BLOB-загрузки производительность повысилась в шесть раз, что заняло примерно 11 минут:

Самый быстрый результат дал инструмент azcopy:

Несмотря на использование встроенной интеграции azcopy в конвейер выпуска, она несовместима с машинами Linux. Однако, используя задание Azure CLI и установив эту утилиту на агенте, команду можно уверенно использовать:

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

Благодаря обнаружению из глубин сети образа Allure Docker, нам удалось доработать схему хранения и отображения отчетов. Доступ к данным теперь защищен паролем, а создание и обработка отчетов остаются быстрыми. При этом с точки зрения пользователей (тестировщиков) изменения минимальны. Решение работает независимо от других программ благодаря отдельному агенту в кластере и не может влиять на другие процессы разработки. Экономическая эффективность этого решения сопоставима с рентабельностью отдельного агента, размещаемого на собственном сервере (15 долларов США при условии, что он изолирован), что намного дешевле существующих альтернатив. Например, ранее рассмотренный qameta.io, где цена за одного пользователя составляет 30 долларов в месяц.

Автор: Дмитрий Гусаров, средний DevOps-инженер Social Discovery Group.