Apache JMeter REST API Token Yönetimi: Master-Slave Yapısında Token Kullanımı

Apache JMeter ile REST API performans testleri gerçekleştirirken kimlik doğrulama amacıyla kullanılan Bearer Token, JWT veya benzeri erişim tokenlarının nasıl yönetileceği özellikle distributed test mimarisinde önem kazanır. Master ve 4-5 slave makineden oluşan bir JMeter altyapısında tokenı doğrudan User Defined Variables üzerinden GUI'de tanımlamak operasyonel açıdan oldukça pratiktir. Örneğin master makinedeki test planında TOKEN isimli bir değişken oluşturup değerine gerçek tokenı yazabilir ve HTTP Header Manager içerisinde "Authorization: Bearer ${TOKEN}" şeklinde kullanabilirsiniz. Distributed test başlatıldığında JMeter test planını remote engine'lere gönderdiği için slave makinelerde ayrıca ayrı bir TOKEN değişkeni oluşturmanız veya her slave için ayrı bir text/CSV dosyası hazırlamanız gerekmez. Bu yaklaşım özellikle tüm slave makinelerin aynı REST API'ye, aynı kullanıcı hesabı veya aynı yetkilendirme tokenı ile eriştiği senaryolarda yönetimi ciddi şekilde kolaylaştırır. Token tek noktadan değiştirilir ve test planı üzerinden tüm remote engine'lere uygulanır. Ancak burada önemli bir güvenlik ayrımı vardır: Tokenı GUI'deki User Defined Variables alanına yazmak, tokenın güvenli şekilde saklandığı anlamına gelmez. Değer JMX test planının içerisinde bulunabileceğinden, JMX dosyasına erişebilen kişiler tokenı görebilir. Ayrıca test planının paylaşılması, versiyon kontrol sistemine alınması veya başka ortamlara taşınması durumunda tokenın da istemeden paylaşılması riski oluşur. Dolayısıyla GUI yöntemi operasyonel basitlik açısından avantajlı, ancak secret yönetimi açısından tek başına ideal değildir. Token değerini bir text veya CSV dosyasında tutmak ise test planı ile secret değerini birbirinden ayırma avantajı sağlar. JMX dosyasını açan kişi doğrudan token değerini görmez; test planında yalnızca ${TOKEN} değişkeni bulunur ve değer CSV Data Set Config gibi bir mekanizma üzerinden okunabilir. Ancak Distributed JMeter mimarisinde burada farklı bir operasyonel yük ortaya çıkar.

Master üzerinde bulunan CSV dosyasının slave makinelerde de erişilebilir olması gerekir. 4-5 slave kullanıyorsanız dosyanın her makineye kopyalanması, doğru path'in tanımlanması, dosyanın güncel tutulması ve token değiştiğinde bütün makinelerde güncellenmesi gerekir. Ayrıca CSV dosyasının bulunduğu makinelerde dosyaya erişimi olan kullanıcılar tokenı yine okuyabilir; dolayısıyla CSV kullanmak tokenı otomatik olarak güvenli hale getirmez. Aynı token tüm slave'lerde kullanılacaksa, yalnızca token yönetimi amacıyla 4-5 ayrı dosya oluşturmak gereksiz operasyonel karmaşıklık yaratabilir.

Bu nedenle küçük ve kontrollü bir performans test ortamında GUI üzerinden User Defined Variables kullanmak pratik bir çözümdür. Daha kurumsal yapılarda ise tokenı JMX ve CSV dışında tutarak environment variable, JMeter property veya merkezi bir secret management mekanizması üzerinden sağlamak daha doğru bir yaklaşımdır. Böylece test planı paylaşılabilir kalırken gerçek erişim bilgileri ayrı bir güvenlik katmanında yönetilebilir.

* TOKEN bilgisini User Defined Variables bölümünde değişken olarak tanımlayarak, aynı test planı üzerinden hem Master hem de Slave makinelerde bu değerin kullanılmasını sağlayabilirsiniz. Böylece her Slave makinede ayrıca token için ayrı bir Text veya CSV dosyası oluşturmanıza gerek kalmaz. Token, test planı içerisinde ${TOKEN} değişkeni üzerinden çağrılarak REST API isteklerinde kullanılabilir.

Burak AVCI - Update: 26.08.2026