Açık konuşayım: Cosmos DB tarafında yıllardır en sevmediğim şeylerden biri, izin işinin iki ayrı kafadan yürümesiydi. Bir yanda Azure RBAC var, control plane’i yönetiyorsun; öbür yanda Cosmos DB’nın kendi data plane RBAC’ı var, hesap üstüne ayrı rol tanımı, ayrı assignment, ayrı script… İki farklı dünya gıbı.
Araya gireyim: Geçen hafta Microsoft’tan gelen duyuru tam da bu yarayı kapatıyor. Cosmos DB’nın data plane yetkilendirmesi artık doğrudan Azure RBAC’ın içine giriyor. Private preview aşamasında, evet; ama yön belli. Ben bu yazıda hem ne değiştiğini hem de bunun Türkiye’deki kurumsal müşterilerimde ne işe yarayacağını anlatacağım.
Önce derdi anlayalım: İki ayrı izin modeli neden problemdi?
Bakın şimdi. Klasik senaryo şöyleydi: Müşteri bir Cosmos DB hesabı açıyor. Diyelim ki bir backend uygulaması var ve bu uygulama bir container’a yazacak. Sen ne yapıyordun?
- Önce Azure tarafında Managed Identity oluşturuyordun. (bence en önemlisi)
- Sonra Cosmos DB hesabına gidip
az cosmosdb sql role definitionverole assignmentkomutlarıyla data plane rolü atıyordun. - Bu sırada GUID’lerle, role definition ID’leriyle uğraşıyordun.
- Portal’dan IAM ekranına bakıyordun — orada Cosmos DB Data Reader yoktu, “Cosmos DB Account Reader Role” vardı ama o sadece metadata okutuyordu, asıl veriyi okutmuyordu.
Doğrusu, İşte tam burada birçok ekip takılıyordu. Bir bankacılık projesinde — 2023 sonuydu sanırım — junior bir geliştirici “Cosmos DB Account Reader Role” verince “neden veriyi okuyamıyorum?” diye iki gün kaybetmişti. Çünkü işim aldatıcıydı. Account Reader, hesabı yönetme izni; veriyi okuma değil. Bu kafa karışıklığı yüzünden bazı ekipler “boşver, connection string ile geçelim” diyordu. Ki bu da güvenlik açısından pek hoş olmayan bir tercih.
“Cosmos DB Account Reader Role” ile “Cosmos DB Data Reader” arasındaki fark, bir apartmanın yöneticisiyle dairenin sahibi arasındaki fark gıbı. Birinçisi binayı yönetir, ikincisi içeri girer. Yıllardır bu ikisi karıştırıldığı için ne kadar yanlış izin verildi, sayamam.
Bi saniye — Evet.
Şimdi gelelim işin can alıcı noktasına.
Yeni modelde ne değişiyor?
Peki neden? Çünkü entegrasyon sonrası tablo baya netleşiyor. Artık Azure portal’da IAM sekmesine girdiğinizde, Cosmos DB’nın data plane rolleri de aynı listede görünüyor. Üç yeni built-in rol geliyor:
- Cosmos DB Data Reader — veriyi okutur, yazdırmaz.
- Cosmos DB Data Contributor — okuma + yazma + silme.
- Üçüncü bir owner-tier rolü de yolda (preview dokümanında detaylar biraz daha olgunlaşacak).
Bence can alıcı nokta şu: Bunlar artık Azure RBAC role‘leri. Yanı az role assignment create ile atayabiliyorsunuz, Bicep/Terraform’da Microsoft.Authorization/roleAssignments ile tanımlıyorsunuz. Cosmos DB’nın kendi özel API’si değil bu. DevOps tarafında iş baya sadeleşiyor; hatta ilk bakışta “bu kadar mı?” dedirtiyor insana.
Hangı terminoloji nerede oturuyor?
| Eski Yöntem | Yeni Yöntem (Integrated RBAC) |
|---|---|
az cosmosdb sql role definition list |
Standart Azure built-in roller |
az cosmosdb sql role assignment create |
az role assignment create |
| Cosmos DB hesabı bazlı scope | Subscription / RG / Account / DB / Container scope |
| Ayrı custom role JSON dosyası | Sadece built-in (custom yol üstünde) |
| Ayrı audit log yaklaşımı | Activity Log + Entra ID üzerinden tek pencere |
Size bir şey söyleyeyim, Kısacası tablo daha okunur hâle geliyor. Ama dür bir saniye — burada sihir yok; sadece parçalanmış yetkilendirme yapısı toparlanıyor (yanlış duymadınız)
Peki pratikte nasıl görünüyor? Küçük bir örnek verelim.
Neyse, diyelim ki bir Function App’ınız var ve Managed Identity ile Cosmos DB’ye yazacak. Eski dünyada buna benzer bir şey yapıyordunuz:
# ESKI DUNYA
PRINCIPAL_ID=$(az functionapp identity show -n myfunc -g myrg --query principalId -o tsv)
ROLE_ID=$(az cosmosdb sql role definition list --account-name mycosmos -g myrg --query "[?roleName=='Cosmos DB Built-in Data Contributor'].id" -o tsv)
az cosmosdb sql role assignment create \
--account-name mycosmos -g myrg \
--scope "/" \
--principal-id $PRINCIPAL_ID \
--role-definition-id $ROLE_ID
Düzgün çalışıyor mu? Çalışıyor. Ama biraz dolaştırıyor insanı işte. Yeni dünyada işe feature flag açıldığında iş şu kadar sadeleşiyor: Bu konuyla ilgili Teams Agent Kurulumu: Prompt’tan Production’a Sade Yol yazımıza da göz atmanızı tavsiye ederim.
# YENI DUNYA
az role assignment create \
--assignee $PRINCIPAL_ID \
--role "Cosmos DB Data Contributor" \
--scope $(az cosmosdb show -n mycosmos -g myrg --query id -o tsv)
Ne yalan söyleyeyim, Bence burada olay netleşiyor: iki tane az‘lı akış yerine tek bir standart akış geliyor. Ekibimdeki bir DevOps mühendisi bunu görünce “bu ne kadar mantıklı yaa” demişti. Haklıydı aslında; yıllardır olması gereken şey buydu.
Türkiye’deki kurumsal yapıda ne anlama geliyor?
Neyse, asıl önemli yere gelelim. Türkiye’de — özellikle bankacılık, sigorta ve telco gıbı regülasyon baskısı yüksek sektörlerde — izin yönetimi sadece “kim neyi okuyabilir?” sorusu değil. BDDK ve KVKK denetimlerinde “kim, ne zaman, nereye erişti?” sorusuna cevap vermek zorundasınız (ki bu çoğu kişinin gözünden kaçıyor) Daha fazla bilgi için Copilot Code Review Faturalandırması: Actions Dakikası Devri yazımıza bakabilirsiniz.
Bir dakika — bununla bitmedi.
Bunu Logosoft tarafında bir finans müşterisinde çok net gördüm: Denetçi geliyor ve “Cosmos DB’deki müşteri tablosuna kimlerin yazma yetkisi var?” diye soruyor. Eski modelde iki ayrı rapor çekmen gerekiyordu — biri Azure RBAC’tan, diğeri Cosmos DB’nın kendi role assignment’larından — sonra bunları elle birleştirip denetçiye sunuyordun (evet, doğru duydunuz) Bu konuyla ilgili Copilot Cloud Agent %20 Daha Hızlı: Custom Image Etkisi yazımıza da göz atmanızı tavsiye ederim.
Küçük not:Evet kulağa basit geliyor ama pratikte epey yorucu ölüyordu; hele ortam büyüdüyse raporlar birbirine giriyordu.
Şimdi tek Activity Log + Entra ID Sign-in Logs üzerinden hikâyeyi toparlayabiliyorsun ve bu işin audit kısmını ciddi biçimde rahatlatıyor.
Bir tahminimi söyleyeyim: Tek başına bu özellik bile compliance ekiplerinin haftalık iş yükünü %30-40 azaltır.
Abartmıyorum.
Tam da öyle.
Açıkçası şaşırmam.
Bir dakika — bununla bitmedi.
Küçük ekip mi büyük yapı mı?
Burada da ayrım var, söylemeden geçmeyeyim: Daha fazla bilgi için CVE-2026-3854: git push Üzerinden GitHub’da RCE Vakası yazımıza bakabilirsiniz.
- Küçük ekipseniz / startup’sanız: Bence private preview’a hemen başvurun. Production’a koymayın ama dev/test ortamınızda deneyin. Kazanacağınız sadeliği görünce eski modele dönmek istemeyeceksiniz gıbı duruyor; hem feedback verirseniz GA olduğunda sizin ihtiyaçlarınıza göre şekillenir.
- Büyük kurumsal yapıdaysanız: Acele etmeyin derim ben de. Önce iç policy ekibinizle konuşun; çünkü mevcut SOC ve SIEM entegrasyonlarınız muhtemelen eski Cosmos DB RBAC API’sine göre yazılmış durumda olabilir. Geçiş planını uzun vadeye yayın. Microsoft “incremental adoption” diyor ya, önü ciddiye alın — aynı hesapta her iki model bir süre yan yana çalışabiliyor.
Ha bu arada, maliyet iyileştirmeu da gündeminizdeyse, daha önce yazdığım
Cosmos DB Maliyet Optimizasyonu: AI Yüklerinde 7 Taktık
yazısına da göz atın.
RBAC ile maliyet direkt bağlı değil ama yanlış izinlendirilmiş bir uygulama yanlış sorgu atıp RU faturanızı uçurabiliyor — bunu da unutmayın.
Peki neden?
Çünkü yetki gevşek olunca sorgu deseni de dağılıyor biraz.
Kısıtlamalar — preview olduğunu unutmayın
Bak şimdi, Açık olalım.
Bu kabiliyetin şu an private preview.
Yanı:
- Erişim için başvurmanız gerekiyor; feature flag arkasında çalışıyor.
- Daha şimdilik dediğimiz custom role desteği yok.
Sadece built-in roller var.
Bu da “bizim ekibe sadece belli container’lara yazma yetkisi lazım” gıbı granular isteklerde şimdilik sıkıntı çıkarıyor. - Production workload için önermiyorum ben de.
Microsoft bunu açıkça söylüyor zaten; altını çizmek lazım. - Role definition ve UX değişebilir.
GA’ye giderken birkaç kez şekil değiştireceğine neredeyse eminim.
Emin değilim ama sanırım böyle olacak. - Birden fazla scope senaryosunda test şart.
Yoksa küçük görünen şey sonra can sıkabiliyor.
“ - Denetim zincirini baştan düşünün;
log formatı ufak farklarla gelebilir.”
Kurumsal müşterilerin çoğu custom role kullanıyor çünkü built-in roller nadiren tam karşılıyor ihtiyacı.
Microsoft tarafı buna roadmap’te yer açmış ama “ne zaman?” sorusunun cevabı şimdilik muğlak kalıyor.
Umarım GA’den önce gelir,
bak şimdi,
asıl mesele de bu zaten.
Tam da öyle.
Maalesef.
Evet.
Hangı CosmosDB hesaplarınız var,hanglelerinde data planeRBAC kullanıyorsunuz,hangilerinde hâlâ key-based authvar?
Bunu bilmeden hareket etme.
Lafı gevelemeden söyleyeyim:
önce tabloyu çıkarın,
sonra karar verin.
Test ortamınızda preview’a alın.Mevcutrole assignment’ları bozmadan, paralel olarak yeni modellebirManagedIdentity’yeDataReaderverin, çalışıyor mu görün.
Burası kısa;
ama etkisi büyük.
Bicepy a daTerraform kullanıyorsanız,roleassignment kısmını yeni modele göre paramatrik hâle getirin.Aynı modülün hem eskihem yenistilidestekleyenbir wrapper ‘ıb olsun ki geçiş kademeli olsun.
Şey,
burada biraz temizlik gerekiyor.
Splunk,Sentinelya dahangiSIEM’i kullanıyorsanız,
yenimodeldekilogformatını ingestedebiliyor mu?
Bunu önceden doğrulayın.
Yoksa sonra koşar durursunuz.
GAolana kadar kritik yüklerde kullanmayın.
Aceleyegerek yok;
özellikle canlı sistemde hiç yok.
“
Bu arada bir bağlantı daha: EğerCosmosDB tarafındaki yenilikleri kaçırdığınızı düşünüyorsanız,
Azure CosmosDB Conf2026 : Notlarım, İzlenimlerim ve yazımda bu yıl konuşulan başlıkların özetini bulabilirsiniz. EntraID entegrasyonu konferansta d a gündemdeydi. Bu konuyla ilgili Azure Cosmos DB Conf 2026: Notlarım, İzlenimlerim ve yazımıza da göz atmanızı tavsiye ederim.
Benim çıkarımım
Açık söyleyeyim:
bu,
son birkaç yılın en mantıklı CosmosDB güncellemelerinden biri.
Yıllardır iki ayrı izin modeliyle uğraşıyorduk,
sonunda Microsoft
“tamam bu saçma”
dedi ve toparladı.
Geç de olsa.
Garip gelecek ama,
Hâlâ pişmesi gereken yerler var —
customrol e meselesi mesela.
Ama yön doğru.
EntraID merkezliyetkilendirme dünyasında CosmosDB’nın de bu standarda gelmesi şarttı.
Şimdi bütün Azure servislerinde aynı pattern’i kullanabileceğiz:
Storage’a,
KeyVault’a nasıl erişim veriyorsanız,
CosmosDB’ye de aşağı yukarı aynı şekilde vereceksiniz.
Bu mental yük açısından büyük rahatlık.
Denemek istiyorsanız ilk iş,
Microsoft’un private preview formuna başvurmak.
Onaylanırsa feature flag’ınız aktifleşiyor.
Sonra dev/testbir hesapta yukarıdaki adımları tek tek uygulayın.
Bana sorarsanız,
6-9 ay içinde GA ölür diye tahmin ediyorum —
ama bu sadece tahmin,
resmî roadmap değil tabi.
Sıkça Sorulan Sorular
Mevcut Cosmos DB data plane RBAC role assignment’larım bozulur mu?
Hayır, bozulmuyor. Microsoft eski mekanizmanın çalışmaya devam edeceğini açıkça söylüyor (inanın bana). Yanı yeni model paralel çalışıyor, geçişi kademeli yapabilirsiniz. Aynı hesapta hem eski hem yeni stil assignment yan yana durabilir, bence bu çok rahatlatıcı bir detay.
Connection string ile yetkilendirme hâlâ çalışıyor mu?
Evet, çalışıyor. Master key ve connection string tabanlı erişim hâlâ aktif. Ama açıkçası güvenlik açısından bunları (belki yanılıyorum ama) artık bayağı kapatmanızı (disableLocalAuth) ve Entra ID + RBAC’a geçmenizi şiddetle öneririm. Neden önemli bu? Hani sızdırılmış bir connection string bütün veritabanınızı açıyor, düşünsenize.
Custom role lazım, ne yapayım?
Şu an private preview’da custom role desteklenmiyor. Granular yetkilendirme şartsa mevcut Cosmos DB data plane RBAC API’sını kullanmaya devam edin. Aslında custom role roadmap’te var, ama tarih henüz net değil.
Bu özellik pek çok Cosmos DB API’leri için geçerli mi?
Şu anki preview ağırlıklı olarak Cosmos DB for NoSQL üzerine yoğunlaşıyor. MongoDB, Cassandra, Gremlin gıbı diğer API’ler için durum henüz netleşmedi; mesela MongoDB tarafı için Microsoft’tan gelecek güncellemeleri takıp etmek gerekiyor (şaşırtıcı ama gerçek)
Private preview’a nasıl başvurabilirim?
Şahsen, Microsoft DevBlog’taki orijinal duyuru sayfasında bir başvuru formu linki var. Formu doldurup gönderiyorsunuz, ekip uygunluğunuzu değerlendirip feature flag’i açıyor. Tecrübeme göre genellikle birkaç iş günü sürüyor.
Kaynaklar ve İleri Okuma
İtiraf edeyim, Announcing the Private Preview of Cosmos DB Azure RBAC Integration (Microsoft DevBlogs)
Configure role-based access control with Microsoft Entra ID — Azure Cosmos DB Resmî Dokümantasyonu
Kendi deneyimimden konuşuyorum, Azure RBAC Genel Bakış — Microsoft Learn (bizzat test ettim)
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.
