Azure DevOps Issuer Emekliye Ayrılıyor: WIF Geçişi Şart
Microsoft, Azure DevOps tarafında uzun süredir elimizde olan bir parçayı daha yavaş yavaş kenara alıyor. Bu kez hedefte Azure DevOps issuer var — yanı Workload Identity Federation (WIF) service connection’larında gördüğümüz o https://vstoken.dev.azure.com prefix’i (buna dikkat edin). Resmî tarih net: 1 Temmuz 2027. Ama işin garip tarafı şu; geçişi bugünden planlamayan ekipler, 2026 yazından itibaren pipeline’larda uyarı görmeye başlayacak.
Garip gelecek ama, Açık konuşayım, bu ilk bakışta “ufak bir konfigürasyon değişikliği” gibi dürüyor. Değil. Hele bir de Türkiye’de bankacılıkta, telco’da ve büyük perakendede iş biraz büyüyor, çünkü WIF service connection’ları çoğu kurumsal pipeline’ın omurgası hâline geldi; bir tanesi aksadığında gecelik deployment zinciri uzuyor, bazen de neredeyse tamamen kilitleniyor. Evet, can sıkıcı.
Olayın özeti: Ne değişiyor, neden değişiyor?
Eh, İki yıl önceye gidelim. Azure DevOps’a WIF desteği geldiğinde, bunu yaşayanlar ne demek istediğimi iyi bilir, service principal secret rotation derdi bir anda hafifledi; pipeline’lar kısa ömürlü OIDC token’larıyla Azure kaynaklarına konuşmaya başladı, uzun yaşayan credential kalmadı, secret saklama işi de bayağı azaldı. İyi öldü yanı.
Şimdi işin yönü biraz değişiyor. Microsoft bu kez OIDC token’ı üreten tarafı elden geçiriyor; eskiden token’ı Azure DevOps kendi çıkarıyordu (vstoken.dev.azure.com üzerinden), artık bunu Microsoft Entra issuer yapacak: https://login.microsoftonline.com/. Yanı federated credential’ın güvendiği taraf değişiyor — Azure DevOps yerine direkt Entra ID devreye giriyor. Daha açık söyleyeyim, peki neden? Çünkü işin merkezî tek yerde olsun istiyorlar.
Bakın, Microsoft’un kafasındaki mantık şu: WIF kullanan pek çok Azure servislerinde — GitHub Actions hariç — issuer standardı tek olsun. Bakınca fena durmuyor, hem yönetim tarafı sadeleşiyor hem de güvenlik denetimi daha rahat oluyor; Entra’da bir kere federated credential tanımlıyorsun, sonra aynı yapı başka yerlerde de yürüyebiliyor. Bu arada yeni açılan service connection’ların yarısından fazlası zaten Entra issuer kullanıyor, yanı Kasım 2025’ten beri varsayılan davranış çoktan değişmiş durumda. Şaşırdım açıkçası.
signInAudience: AzureADMultipleOrgs) bu kapsamın dışında. Onlar için Azure DevOps issuer çalışmaya devam edecek — ta ki Entra issuer o senaryoları da destekleyene kadar.Takvim: Kim, ne zaman, neyi yapacak?
Microsoft bu sefer eli biraz açık davranmış gibi. Yaklaşık 1.5 yıllık bir geçiş penceresi var, fena değil; ama tecrübeyle sabit, böyle “zaten daha çok var” denilen işler hep son üç ayda baş ağrısına dönüyor.
İşte tam da bu noktada devreye giriyor.
| Tarih | Ne oluyor? | Sizi nasıl etkiler? |
|---|---|---|
| Kasım 2025 (geçmiş) | Yeni service connection’lar default Entra issuer ile oluşturuluyor | Yeni yapılanlar zaten güvende |
| 1 Temmuz 2026 | Azure DevOps issuer resmen deprecated | Mevcut bağlantılar çalışıyor ama uyarı görünüyor |
| Temmuz 2026 – Haziran 2027 | Pipeline run’larda ve UI’da warning | Geçiş için gerçek pencere bu |
| 1 Temmuz 2027 | End of life — Azure DevOps issuer tamamen kapanıyor | Dönüştürülmeyen bağlantılar patlıyor |
Peki can alıcı nokta ne? Deprecated olması çalışmıyor demek değil. Bir süre daha iş görüyor, sadece her yerde uyarı göstermeye başlıyor. Rahat rahat erteleyeyim derseniz, bir noktadan sonra duvara tosluyorsunuz.
Peki, garip gelecek ama, Açık konuşayım, 2027 Temmuz’u geldiğinde dönüşmeyen bağlantılar tamamen kapanacak. Gecelik production deployment’ınız varsa ve sabah pipeline kırmızı yanıyorsa, “dur bir dakika ne öldü?” diye bakınmak zorunda kalırsınız (yanlış duymadınız). Evet, tam da öyle.
Geçiş aslında ne kadar zor?
Şunu fark ettim: Teknik tarafta, açık konuşayım, çok da göz korkutan bir şey yok. UI üzerinden “Convert” butonuna basıp geçebiliyorsunuz. Ama dur bir saniye — gerçek hayatta iş öyle temiz ilerlemiyor, çünkü asıl sürpriz teknik detayda değil, yetki tarafında çıkıyor.
İdeal senaryo: Tek tık dönüşüm
Küçük bir detay: Service connection listesinde Azure DevOps issuer kullananlar artık listenin en üstünde sarı uyarıyla görünüyor. Bağlantıya girip “Convert” dediğinizde Azure DevOps arka planda Entra’da yeni bir federated credential oluşturuyor, eski olanı bırakıyor, service connection’ı güncelliyor; yanı kağıt üstünde olay baya kısa,. Sahada bu kadar pürüzsüz akması her zaman mümkün olmuyor.
Gerçek senaryo: İzin labirenti
İşin can sıkan kısmı burada başlıyor. Conversion için Entra’da app registration üzerinde federated credential ekleme yetkisi lazım. Türkiye’deki kurumsal yapılarda bu yetki çoğu zaman platform ya da identity ekibinde kalıyor (DevOps mühendisinde değil), dolayısıyla süreç hemen uzuyor; hani teknik olarak basit görünen şey, organizasyon şemasına takılıp kalıyor (şaşırtıcı ama gerçek)
- Pipeline sahibi: Service connection’ı dönüştürmek istiyor
- Entra admin: “Bana ticket aç, ben bakayım”
- Güvenlik ekibi: “Önce risk değerlendirmesi”
- Change Advisory Board: “Önümüzdeki ay toplantımız var”
Sonuç mu? Tek tıklık iş, 3 haftalık süreç. Bunu Türk kurumlarında defalarca gördüm, şaşırtıcı değil aslında; o yüzden geçişi teknik bir görev gibi değil, organizasyonel bir proje gibi ele almak daha doğru oluyor.
Çok konuştum, örnekle göstereyim.
Managed identity tarafı
User-assigned managed identity kullananlarda da mantık çok farklı değil — federated credential’ın issuer alanı değişiyor ve sizden Azure resource provider üzerinde Microsoft.ManagedIdentity/userAssignedIdentities/federatedIdentityCredentials/write izni bekleniyor (en azından benim deneyimim böyle). Custom RBAC rolleriyle çalışan ekipler bu izni rolüne koymuş mu diye bakmak iyi fikir; yoksa conversion ekranında 403 görüp nedenini anlamak yarım günü alabiliyor. Deep Agents + Cosmos DB: Operasyonel Veride Plan-Eylem-Doğrulama yazımızda bu konuya da değinmiştik. Daha fazla bilgi için ChatGPT’de Sağlık Zekası: GPT-5.5 Ne Kadar Güvenli? yazımıza bakabilirsiniz.
Bu emekliliği basit bir “issuer URL değişikliği” gibi okumayın. Sahada gördüğüm tablo şu: Service connection sayısı 200’ü geçen kurumlarda envanter çıkarmak bile yarım gün sürüyor. Plan yapmadan başlamayın.
Federated credential nasıl görünüyor? Önce-Sonra
Konunun teknik tarafını biraz elle tutulur hâle getireyim. Eskiden Entra app registration içindeki federated credential kabaca şöyle duruyordu: Daha fazla bilgi için Binlog MCP Server: Build Sorunlarını Copilot’a Çözdürmek yazımıza bakabilirsiniz.
{
"name": "azuredevops-myproject-prod",
"issuer": "https://vstoken.dev.azure.com/{org-guid}",
"subject": "sc://myorg/myproject/prod-connection",
"audiences": ["api://AzureADTokenExchange"]
}Şimdi işin rengi değişiyor. Yeni dünyada aynı kayıt, ama issuer tarafı farklı bir yere kayıyor:
{
"name": "azuredevops-myproject-prod",
"issuer": "https://login.microsoftonline.com/{tenant-id}/v2.0",
"subject": "sc://myorg/myproject/prod-connection",
"audiences": ["api://AzureADTokenExchange"]
}Subject pattern aynı kalıyor, bu iyi haber. Yanı service connection isimlendirme şemanızı baştan aşağı ellemiyorsunuz; sadece issuer URL’i. Doğrulama akışı başka bir yola giriyor, hani can alıcı fark da tam burada çıkıyor.
Evet.
Türkiye perspektifi: Kurumsal yapılar için ne demek?
Türkiye’deki kurumsal Azure adopsiyonunda bir şeyi sık görüyorum: WIF’e geçen ekipler genelde küçük, çevik takımlar oluyor. Büyük kurumsal yapılar işe hâlâ service principal + secret ikilisiyle devam ediyor; KeyVault’ta secret rotasyonu da bazı yerlerde manuel gidiyor, itiraf edelim, işte durum biraz böyle.
Bu duyuru aslında ikinci dalganın habercisi. Çünkü 2027’de Azure DevOps tarafında WIF kullanmak tek seçenek hâline gelecek (secret tabanlı service connection’lar. Ayrı bir emeklilik takviminde). Yanı WIF’e daha geçmediyseniz, iki kere dönüşüm yapmak yerine doğrudan yeni standarda (Entra issuer’lı WIF) geçmek daha mantıklı dürüyor.
Enterprise vs startup farkı
Küçük bir startup ya da 10-15 kişilik bir dev ekibiyseniz, bu emeklilik sizin için gerçekten bir öğleden sonra işi olabilir. Service connection sayınız 5-10 civarındadır, hepsini tek tek dönüştürürsünüz, biter gider. Çay molası bile çıkar. SharePoint Copilot Apps: Sohbete Gerçek Arayüz Geliyor yazımızda bu konuya da değinmiştik.
Dürüst olmak gerekirse, 50+ developer, çoklu organization. 300+ pipeline olan bir kurumsal yapıdaysanız hikâye biraz değişiyor, hatta baya değişiyor; çünkü burada mesele sadece bağlantıları çevirmek değil (envanteri çıkarmak, sahipliği netleştirmek, pilotu seçmek ve ilk günlerde koşan job’ları izlemek gerekiyor), yoksa dönüşüm ortada kalıyor. Bu konuyla ilgili Kubernetes CVE Kayıt Düzeltmesi: Tarayıcılarınız Şaşıracak yazımıza da göz atmanızı tavsiye ederim.
- Envanter: Azure DevOps REST API ile tüm service connection’ları listeleyip issuer alanına göre filtreleyin
- Sahiplik haritası: Her connection hangi takımın, hangi pipeline’larda kullanılıyor?
- Pilot grup: Düşük riskli 5-10 connection ile başlayın, hatayı orada görün (bence en önemlisi)
- Batch dönüşüm: Az-DevOps CLI veya REST API ile toplu conversion script’i
- Monitöring: İlk 48 saat pipeline’ları yakın takip — özellikle gece çalışan scheduled run’lar
Bu listeyi okurken “biz zaten yapıyoruz” diyorsanız ne âlâ. Ama “hmm, envanterim bile yok” diyenler — ki sahada gördüğüm çoğunluk böyle — şimdiden başlamalı. Daha açık söyleyeyim, peki neden? Çünkü en büyük sorun teknik değil, nerede ne var önü bilmemek.
Bir hata, bin pişmanlık: Sık yapılan yanlış
Şöyle söyleyeyim, Bu geçişlerde en çok gördüğüm şey şu: Ekip, eski federated credential’ı dönüştürdükten hemen sonra Entra’dan silmek istiyor. Temizlik yapalım diye düşünüyorlar. Ama iş öyle yürümüyor; hâlâ o connection’ı kullanan eski branch’ler, bir de yeniden koşan eski pipeline run’ları varsa, ortalık bir anda karışıyor.
Ne yalan söyleyeyim, Açık konuşayım, ben burada biraz frene basılmasını öneriyorum. Conversion sonrası eski federated credential’ı en az 30 gün bırakın, çünkü pipeline log’larında AADSTS70021 ya da buna benzer auth hataları görünmüyorsa bile, arkada bekleyen bir job çıkıp sizi şaşırtabiliyor; acele edip silince sorun sonra geri dönüyor.
Peki neden?
Peki neden? Bir de Conditional Access tarafı var. Bazı kurumlarda Entra issuer’lı token’lar için CA policy’leri ayrı yazılıyor, hani ilk bakışta önemsiz gibi dürüyor ama geçişten önce identity ekibiyle bunu konuşmazsanız pipeline token alıyor, sonra policy’ye takılıyor. Sız de sebebi belirsiz hataların içinde kalıyorsunuz.
Maliyet ve operasyonel etki
Vallahi, Direkt bir maliyet kalemi yok, yanı WIF kullanmak ücretsiz; Entra issuer’a geçmek de öyle (en azından benim deneyimim böyle). Ama işin asıl tarafı başka: dolaylı maliyet var, üstelik küçümsenecek gibi değil. 200 connection’lı bir kurumda envanter çıkarma, planlama yapma, dönüşümü yürütme. Sonra doğrulama için benim kaba tahminim 80-120 saat arası; TL tarafında bakınca da bir senior DevOps mühendisinin yarım aylık efforu gibi düşünün. Kısa cevap bu.
Bak şimdi, bu yüzden FinOps açısından ben şunu öneriyorum: Geçişi 2026’nın ikinci yarısında, warning’ler görünmeye başladıktan hemen sonra planlayın. Ne çok erken gidin, çünkü gereksiz bir aciliyet yaratıyor; ne de çok geç kalın, yoksa deadline paniği başlıyor ve ekip saçma sapan koşuşturuyor (evet, doğru duydunuz). Açık konuşayım, tam da burada ritim önemli. Bu konunun yanında Copilot Autofix Azure DevOps’ta: Alert Yığını Bitiyor mu? yazısında bahsettiğim alert yönetimi yaklaşımı da işe yarıyor, çünkü bu warning’lerin pipeline log’larında boğulmasını biraz olsun engelliyor. Evet.
Şimdi gelelim işin can alıcı noktasına.
Aksiyon planı: Bugün ne yapmalı?
Lafı uzatmadan, somut adımlar:
- Azure DevOps’ta her organization için service connection listesini açın. Sarı uyarı ile gelenleri tek tek sayın, çünkü işin asıl borcu orada dürüyor.
- Bu sayıyı 18’e bölün — 2026 sonuna kadar ay ay kaç connection dönüştürmeniz gerektiğini böylece görürsünüz, kaba ama fena değil bir tempo çıkar.
- Entra admin ekibiyle kısa bir senkronizasyon toplantısı yapın. federatedIdentityCredentials/write yetkisinin hangi rollerde olduğunu netleştirin; yoksa sonra “bizde vardı sanıyorduk” muhabbeti başlıyor.
- Pilot olarak dev/test ortamına bakan 3-5 connection’ı bu hafta dönüştürün. Pipeline’ları çalıştırın, sonra bir daha çalıştırın; evet, bazen ilk deneme sizi yanıltıyor. — ciddi fark yaratıyor
- Production connection’ları için bir change window planlayın — rollback prosedürü dahil olsun, çünkü o gün kimsenin sürpriz istemeyeceği belli.
- Yeni oluşturulacak connection’lar için ekibe “her zaman Entra issuer kullanın” politikasını yazılı hâle getirin. Kulağa basit geliyor ama unutulunca geri dönüşü uğraştırıyor.
Bu arada küçük bir not: CI/CD güvenlik tarafını bütünsel görmek istiyorsanız, Bot PR’lere de CI yolu açıldı: Güvenlikte ince ayar zamanı yazımdaki pipeline trust modeli ile GitHub Code Quality artık ücretli: Kurumlar neyi hesap etmeli? yazısındaki maliyet planlama yaklaşımını yan yana koyunca tablo biraz daha netleşiyor, hatta şaşırdım açıkçası, ikisi birlikte düşünülmeden resim tam oturmuyor.
Sıkça Sorulan Sorular
Azure DevOps issuer’dan Entra issuer’a geçiş downtime gerektirir mi?
Kısa cevap: hayır. Yanı doğru yapılırsa herhangi bir kesinti yaşamıyorsunuz. Conversion sırasında Azure DevOps yeni federated credential’ı oluşturup eskisini bırakıyor — hani ikisi bir arada var olabiliyor kısaca. O sırada aktif çalışan pipeline run’ları etkilenmiyor, sonraki run’lar zaten yeni issuer ile çalışıyor. Ama bence her ihtimale karşı kritik production pipeline’larını tam conversion anında çalıştırmayın, gereksiz risk almaya gerek yok.
Multi-tenant uygulamalarım var, ben de bu geçişi yapmalı mıyım?
Bak şimdi, Şu an için hayır, sizi doğrudan ilgilendirmiyor. Multi-tenant uygulamalar (signInAudience: AzureADMultipleOrgs) bu emeklilik duyurusunun dışında tutulmuş. Microsoft, bu senaryolar için Entra issuer desteği gelene kadar Azure DevOps issuer’ı çalıştırmaya devam edecek (buna dikkat edin). Ama açıkçası bu durumu takip etmenizi öneririm — ileride ayrı bir duyuru gelebilir.
Pipeline run’da warning görüyorum ama hata almıyorum, ne yapmalıyım?
Warning şu an için sadece bir bilgilendirme, yanı pipeline’ınız hâlâ çalışıyor demek. Ama 1 Temmuz 2027’den itibaren bu connection tamamen ölü olacak. Tecrübeme göre böyle şeyleri son aya bırakmak pek iyi fikir değil — warning gördüğünüz anda dönüşümü planlamaya başlayın. Bir de şunu ekleyeyim: pipeline log’larındaki bu warning’i CI sistemde alerting’e bağlamak gerçekten işe yarıyor, gözden kaçmıyor.
Custom RBAC rolüm var, conversion için hangi izne ihtiyacım var?
Bence, Managed identity kullanıyorsanız Microsoft.ManagedIdentity/userAssignedIdentities/federatedIdentityCredentials/write iznine ihtiyacınız var. App registration tarafında işe Entra’da Application Administrator veya direkt app üzerinde Owner yetkisi yeterli oluyor. Aslında custom rol kullanıyorsanız tek yapmanız gereken bu action’ı role eklemek — oldukça basit.
Azure Government veya Azure China kullanıyoruz, bu bizi etkiler mi?
Hayır, bu duyuru sadece Azure public cloud için geçerli. Yanı Non-public cloud ortamlarında (Government, China, Stack) Azure DevOps issuer çalışmaya devam ediyor, herhangi bir şey yapmanıza gerek yok. Ama şunu da belirteyim: bu senaryolar için de uzun vadede Entra issuer’a geçiş planlanıyor — sadece henüz net bir tarih açıklanmış değil (yanlış duymadınız)
Kaynaklar ve İleri Okuma
Aslında, Configure workload identity federation with Azure DevOps — Microsoft Learn
Workload identity federation — Microsoft Entra Documentation
Configure an app to trust an external identity provider — Microsoft Entra
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
0 comments