Allure Raporu Güvenlik Sorunlarını Çözme

Ayrıntılı ve görsel olarak çekici test raporları, yazılım test uzmanlarının test sonuçlarını anlamaları ve bilinçli kararlar vermeleri için çok önemlidir. Social Discovery Group'un ekibi, detaylara büyük bir titizlikle dikkat ederek, tüm cevapları biliyormuş gibi görünen açık kaynaklı bir güç merkezi olan Allure Reports'un yardımıyla görsel olarak büyüleyici test raporları hazırlıyor. Ancak bir kusuru ortaya çıkardık: güvenlik. Bağlantıya sahip olan herkes içeriye göz atabiliyordu ve alt sistemlere uyum sağlama yeteneği eksikti. Bu makalede, SDG test ekibi, uygun bir Allure Docker oluşturarak ve depolama düzenini değiştirerek Allure raporlarındaki güvenlik sorunlarını nasıl çözmeyi başardıklarını paylaşıyor.

SDG geliştirme ortamı Microsoft ürünlerini temel alır ve CI/CD işlemlerini yürütmek için Azure DevOps kullanılır. CI hattı aracılığıyla, otomatik testlerin deposu oluşturulur ve ardından test çalıştırmaları için test uzmanlarının tercihlerine dayalı olarak çeşitli CD hatları aracılığıyla kategorilere ayrılır.

Şemayı başlangıçta kurulduğu haliyle ele alalım:

Bu kurulumda, CD hattı aynı zamanda iki Allure raporu için bir oluşturucu görevi de görüyor: Biri Slack bildirimleri için, test kullanıcılarına aşamaları ve test kategorilerini belirten kolay okunabilir bir bağlantı sağlıyor, diğeri ise Allure raporunu Azure DevOps'a aktarmak için.

Bu, Azure DevOps'ta rapor oluşturulmasına ve ardından Azure depolama hesabındaki statik web siteleri için $web kapsayıcısına yükleme yapılmasına olanak tanıyan bir uzantının yüklenmesiyle gerçekleştirilir. Anonim erişimin etkinleştirilmiş konfigürasyonu, raporun bir bağlantı yoluyla görüntülenmesine olanak tanır.

Daha fazla kolaylık sağlamak amacıyla Allure raporunu derleme hattında görüntülemek için ek bir eklenti de kullanıldı.

Bu şema işlevsel olsa da bazı dezavantajları vardır:

İlk olarak, Allure raporlarına bağlantıya sahip olan herkes erişebildiği için bu yöntemin güvenliği yoktur. Teste bağlı olarak rapor, hizmetler, bunların güvenlik açıkları ve kamu erişiminin kısıtlanması gereken diğer hassas veriler hakkında gizli bilgiler içerebilir. Azure depolama hesabında herkesin adrese erişmesini sağlayan "anonim erişim" bayrağının etkinleştirilmesi nedeniyle genel erişim verilir. Bu işlevin devre dışı bırakılması, yetkisiz kişilerin dosyalara harici erişimini durdurur ancak aynı zamanda raporun Azure DevOps sayfasında erişilemez olmasına da neden olur.

İkinci olarak, yöntem alt sistemler arasında evrensel olarak uygulanamaz. CD kanalındaki işlerin listesini incelersek, raporu depolama hesabına kopyalamak için yerel "azcopy" işinin kullanıldığını görürüz. Bu iş yalnızca Windows'taki aracılarla kullanılabilir ve Linux kullanıldığında bir hata döndürür.

Üçüncüsü, test geçmişini ve trendlerini görüntülemenin zorluğu var. Mevcut tek rapor geçmişine Slack bildirimleri aracılığıyla erişilebilir; bu, belirli testleri bulmak için uygun bir yöntem değildir.

Yukarıda sayılan faktörlerin tamamı mevcut sistemin değiştirilmesi gerektiği sonucunu doğurmuştur. Bu nedenle, bu soruna birkaç çözüm düşünüldü:

1. Allure rapor projesinin tamamını tek bir belgede birleştirecek birleşik bir .html dosyası oluşturmak için bir yöntem oluşturmak.

2. Raporun görüntülenmesi için kimlik doğrulama sunan üçüncü taraf hizmetlerinin kullanılması.

3. Raporları görüntülemek için kendi kimlik doğrulamasına sahip önceden hazırlanmış bir görüntüyü arama.

   
   

Şimdi bu noktaların her birini daha ayrıntılı olarak ele alalım.

Daha önce de belirtildiği gibi, depolama hesabındaki "anonim erişim" işlevinin devre dışı bırakılması, yetkisiz kullanıcıların bağlantı yoluyla dosyalara erişimini kısıtlar. Belirli kişilere dışarıdan erişim sağlamak için Azure'un kendisi çeşitli olası seçenekler sunar; bunlar arasında SAS belirteçlerinin verilmesi ve Erişim ilkelerinin yapılandırılması yer alır. Ancak Allure raporunun, özellikle de proje yapısındaki mevcut JavaScript komut dosyalarına referans veren index.html dosyasının oluşturulmasının doğası nedeniyle:

Raporu açarken, blob depolama alanındaki dosyalar arasındaki erişim kısıtlandığından sayfanın boş olduğu görülüyor.

Tek bir .html dosyası oluşturmak için şunu keşfettik: resim Bu, konuşlandırıldığında gömülü "allure-combine ./path/to/allure/geneated/report/folder" komutunu kullanarak Allure projesinin tamamından dosya oluşturulmasını kolaylaştırdı. Ancak bu işlem, aracının Python'un kurulu olmasını gerektirir. Ne yazık ki, test uzmanlarının çalışmalarının düzgün işleyişini sağlamak için hayati önem taşıyan bileşenler olan API testlerinin sonuçlarına eklenen dosyaların bulunmaması nedeniyle bu yaklaşımın etkisiz olduğu ortaya çıktı.

Ayrıca Azure'un, erişime ihtiyaç duyan kişilerin filtrelenmesine olanak tanıyan IP beyaz listesi özelliğini sunduğunu da belirtmekte fayda var. Ancak erişime ihtiyaç duyan ekibin statik IP adresi olmadığı için bu yöntem uygun olmadı.

Allure'un geliştirme ortamında test toplama konusunda popüler bir uygulama olduğu göz önüne alındığında, çevrimiçi olarak ücretli hizmetler mevcuttur. Örneğin, https://qameta.io/ hizmeti, kullanıcı dostu bir web arayüzünde Allure raporlarının depolanmasını ve oluşturulmasını sağlar. Ancak bu tür hizmetler genellikle ücretlidir ve gerekli işlevsellik minimum düzeydedir. Bu nedenle bu uygulama seçeneğini son çare olarak değerlendirdik.

Kararlaştırdığımız seçim, kullanıcı arayüzü panelinin ( https://github.com/fescobar/ ) entegrasyon özelliğine sahip allure-docker hizmeti Docker görüntüsü ( https://github.com/fescobar/allure-docker-service ) oldu. allure-docker-service-ui ) kimlik doğrulaması ile. Hizmetle iletişim, HTTP/HTTPS aracılığıyla yapılandırılır ve görüntünün kendisi, API istekleri aracılığıyla işlevselliği destekler.

Bu çözümün bazı avantajlarını vurgulayalım:

1. Güvenlik: Veri aktarımı, SSL ve TLS mekanizmaları kullanılarak şifrelenir ve görüntü, yerleşik "yönetici" ve "görüntüleyici" kullanıcılara, ihtiyaçlarına göre değiştirilebilen ve kullanıcılara sağlanabilen oturum açma kimlik bilgilerini sağlar.

2. Kolaylık: Hizmet, Allure raporlarıyla çalışmak için çeşitli işlevler sunan kendi görsel arayüzüyle birlikte gelir.

3. İşlevsellik: API istekleri sayesinde Azure DevOps tarafında yayın işlem hatları ile ilgi çekici kombinasyonlar tasarlanabilir. Örneğin, tek bir aşamada rapor oluşturmak, yüklemek ve ardından önbelleği temizlemek.

   
   

Sonuç olarak, sürüm hattımız şuna benzer:

Allure raporlarının yüklenmesine olanak tanıyan Azure DevOps uzantısından uzaklaşmadığımızı belirtmekte fayda var; çünkü o zamana kadar zaten kendi aracılarımıza geçmiştik ve her şeyin "kendi başımıza" çalışması fikrine bağlı kalmıştık. "makineler.

Depolamayla ilgili olarak, azcopy yardımcı programını kullanarak Azure depolama hesaplarına yazmayı, özellikle Dosya Paylaşımı, Blob ve Blob'a yüklemeyi denedik.

Sonuçlar önemli ölçüde farklılık gösterdi. File Share az Storage file upload-batch komutunu kullanırken testimizin yazma hızı bir saatin üzerindeydi:

Blob Storage'ı az Storage blob upload-batch komutuyla kullanırken performans yaklaşık 11 dakika sürecek şekilde altı kat arttı:

En hızlı sonuç azcopy aracıyla elde edildi:

Yayın hattında azcopy'nin yerleşik entegrasyonunu kullanırken, Linux makineleriyle uyumlu değildir. Ancak Azure CLI işini kullanarak ve bu yardımcı programı aracıya yükleyerek komut güvenle kullanılabilir:

azcopy kopyası 'KAYNAK' 'HEDEF' --recursive=true

Allure Docker görüntüsünün ağın derinliklerinden keşfedilmesi sayesinde raporların depolama ve görüntüleme düzenini değiştirebildik. Veri erişimi artık parola korumalıdır ve rapor oluşturma ve işleme hızlı kalır. Üstelik kullanıcıların (test uzmanlarının) bakış açısına göre değişiklikler minimum düzeydedir. Çözüm, kümedeki ayrı bir aracı sayesinde diğer programlardan bağımsız olarak çalışır ve diğer geliştirme süreçlerini etkileyemez. Bu çözümün maliyet etkinliği, mevcut alternatiflerden çok daha ucuz olan, kendi kendine barındırılan ayrı bir aracınınkiyle karşılaştırılabilir (izole olması koşuluyla 15 dolar). Örneğin, daha önce ele alınan qameta.io'da tek bir kullanıcı için fiyat ayda 30$'dır.

Social Discovery Group Orta DevOps Mühendisi Dmitrijs Gusarovs tarafından yazılmıştır.