Cosmos DB Azure RBAC Entegrasyonu: İki Dünya Birleşiyor
📋 İçindekiler
-
# YENİ YÖNTEM — standart Azure RBAC az role assignment create \ --assignee $PRINCIPAL_ID \ --role "Cosmos DB Data Contributor" \ --scope "/subscriptions/$SUB/resourceGroups/myrg/providers/Microsoft.DocumentDB/databaseAccounts/mycosmosacc"Şöyle söyleyeyim, Baktığınızda fark hemen çıkıyor ortaya değil mi? İkinci yöntem, Storage Account’a Blob Contributor vermekle aynı dilde konuşuyor. Ekip içi eğitim açısından bu baya önemli; yeni gelen birine “Azure’da yetki nasıl verilir?” sorusunu tek kalıpla anlatabileceksiniz artık.
Peki Türkiye’de kurumsal müşteriler için anlamı ne?
Burada biraz durmak lazım çünkü Türkiye’de işin rengi biraz farklı oluyor. Logosoft’ta danıştığımız müşterilerin önemli kısmı — özellikle bankalar, sigorta şirketleri ve kamu kurumları — KVKK ve BDDK denetimleri için kim, hangi veriye, ne zaman erişti? sorusuna net cevap vermek zorunda kalıyor. Daha fazla bilgi için
- Mevcut SQL RBAC atamalarınız çalışmaya devam edecek. Bu güzel haber — geriye dönük uyumluluk var yanı acele edip her şeyi taşımak zorunda değilsiniz. — bunu es geçmeyin
- Custom rol yok. “Sadece şu container’da read ama şu partition key’de write” gibi ince ayarları şimdilik yapamıyorsunuz.
- Scope desteği gelişiyor. Şu anda account-level atamalar net çalışıyor; database ve container seviyesindeki davranışlar değişebilir yanı dikkat etmek gerekiyor.
- UX değişebilir. Microsoft açık açık söylüyor: feedback’e göre arayüz güncellenebilir. Dokümantasyon yazıyorsanız ekran görüntülerini koymadan önce iki kere düşünün derim.
Kendi ortamımda ilk denememde ben de hata aldım — role assignment yapıldı ama uygulama tarafında erişim 401 döndü. Sebebi token cache çıktı. Yeni rol atandıktan sonra Managed Identity’nın token’ını yenilemek gerekiyor; eski token hâlâ eski yetkileri bellekte tutuyordu. Çözüm basit: uygulamayı restart etmek ya da token lifetime dolana kadar beklemek. Ufak detay ama valla saatimi yedi.
Evet.
Daha büyük resmin bir parçası — peki nereye doğru?
Dürüst olayım: bu duyuru tek başına devrim falan değil. Ama Microsoft’un son 1-2 yılda Entra ID merkezli güvenlik mimarisini bütün servislere yayma stratejisinin önemli parçalarından biri. Entra External ID Native Auth SSO: Tam Entegre Deneyim tarafında da benzer bir konsolidasyon var. Kubelet API Yetkilendirmesi GA Öldü: Güvenlik Devrimi yazımda anlattığım Kubernetes tarafındaki yetkilendirme dönüşümü de aynı çizgide gidiyor aslında;
“Tek kimlik, tek yetkilendirme, tek audit.” mottosu boşuna seçilmemiş gibi dürüyor. Ben bu yaklaşıma yakın hissediyorum kendimi. Yıllardır AZ-500 sınavına hazırlanırken anlattığım least privilege prensibinin sahada uygulanabilir hâle gelmesi için böyle entegrasyonlar şart oluyor.
Tam da öyle.
Maliyet tarafına kısa bir bakış atalım mı?
Kısaca değineyim: RBAC entegrasyonunun kendisi ekstra ücret getirmiyor. Cosmos DB’nizin RU/s tüketimi neyse o devam ediyor. Ama dolaylı tasarruf var — operasyonel yük azalıyor, audit hazırlığı kısalıyor, yapılan hata sayısı düşüyor. Türkiye’de orta ölçekli bir müşteride compliance hazırlık maliyetinin yıllık altı haneli rakamlara çıkabildiğini düşünürsek, burası işe yarayan bir kazanım gibi dürüyor.
Peki neden?
Peki ilk adım olarak ne yapmalısınız?
Eğer Cosmos DB kullanıyorsanız şöyle ilerlemenizi öneririm:
- Mevcut data plane RBAC atamalarınızı listeleyin.
az cosmosdb sql role assignment listkomutuyla dökümünü çıkarın. - Hangi uygulamanın hangi yetkiye ihtiyacı olduğunu sade bir tabloya yazın. Çoğu zaman bazı uygulamaların gereğinden fazla yetkili olduğunu fark ediyorsunuz.
Sıkça Sorulan Sorular
Mevcut SQL RBAC atamalarım bozulur mu?
Hayır, bozulmuyor. Microsoft geriye dönük uyumluluğu koruyacağını net bir şekilde söyledi. Yanı eski data plane atamalarınız sorunsuz çalışmaya devam ediyor. Yeni modele geçişi de aslında incremental yapabilirsiniz — mesela yeni uygulamaları yeni modelle kurarsınız, eskilere hiç dokunmazsınız.
Custom rol oluşturabilir miyim?
Şu an yok maalesef. Private preview’da sadece iki built-in rol var: Data Reader ve Data Contributor. Açıkçası ince ayarlı yetki ihtiyacınız varsa bence GA olana kadar mevcut SQL RBAC modelinde kalmak daha mantıklı.
Ekstra ücret çıkar mı?
Hayır, RBAC entegrasyonunun kendisi ücretsiz. Cosmos DB’nın standart RU/s ve storage maliyetlerinin dışında herhangi bir ek fatura kalemi gelmiyor. Hatta tecrübeme göre operasyonel maliyetleri bir miktar düşürmesi de oldukça muhtemel.
Production’da kullanabilir miyim?
Şu an için hayır. Microsoft zaten açıkça “private preview, production önerilmez” diyor. Önce test ve geliştirme ortamlarında deneyin, geri bildirimlerinizi verin, sonra GA duyurusunu bekleyin. Bence 2026’nın ilk yarısında GA gelir — ama bu tamamen benim öngörüm, resmî bir bilgi değil.
Terraform ile yönetebilir miyim?
Şunu fark ettim: Evet! Bence en güzel taraflarından biri de bu zaten. Standart
azurerm_role_assignmentkaynağıyla yönetiliyor,. Ayrı bir provider ya da kaynak tipi öğrenmek zorunda değilsiniz. IaC tarafında ciddi bir sadeleşme demek bu.Kaynaklar ve İleri Okuma
Resmî Duyuru: Private Preview of Cosmos DB Azure RBAC Integration (Microsoft DevBlogs)
Azure Cosmos DB Role-Based Access Control Dokümantasyonu
Azure RBAC Genel Bakış (Microsoft Learn)
Tuhaf ama, Managed Identities for Azure Resources
Bu yazı yapay zeka destekli araçlarla hazırlanmış ve editoryal incelemeden geçirilmiştir.Aşkın KILIÇYazar20+ 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.
AZ-305AZ-104AZ-500AZ-400DP-203AI-102İlgili Yazılar
İlginizi Çekebilir
Burak S.
Cosmos DB’de o ikili yapı gerçekten baş ağrısıydı, özellikle audit log tarafında her şeyi tek yerden görememek çok can sıkıcıydı. Integrated RBAC ile data plane tarafının da Azure RBAC’e girmesi büyük kolaylık olacak. Peki mevcut connection string tabanlı erişimleri geçişe zorlamak için bir yol var mı?
Cenk B.
Tam da bu sorunu yaşıyorduk, iki farklı izin modeli yönetmek özellikle büyük ekiplerde gerçekten baş ağrısına dönüşüyordu. Peki bu entegrasyon mevcut Cosmos DB kaynaklarına geçişte ne kadar sorunsuz oluyor, migration sırasında bir kesinti yaşanıyor mu?
Hakan G.
Tam da bu konuyla geçen ay uğraştım, farklı ekiplere data plane erişimi vermek için ne kadar dolambaçlı yollardan gitmek gerekiyordu. Bu birleşme özellikle büyük organizasyonlarda audit süreçlerini ciddi kolaylaştıracak gibi görünüyor, peki mevcut uygulamalarda geçiş nasıl işliyor, kırılma riski var mı?
Arda K.
Yıllardır Cosmos DB projelerinde ayrı ayrı izin yönetmek gerçekten baş ağrısıydı, sonunda bunu birleştirmeleri çok iyi oldu. Acaba mevcut uygulamaları geçirirken breaking change riski var mı, deneyimlerin nasıl oldu? Bu arada şu yazınız da güzeldi: Gateway API v1.5: Altı Özellik Stable Oldu, Ne Değişiyor? — https://www.askinkilic.com.tr/gateway-api-v15-alti-ozellik-stable-oldu-ne-degisiyor/
Yorumlar kapalı.
4 comments