Cosmos DB’de RBAC Sonrası 403 Hatası: Nedenleri ve Çözümü
Azure Cosmos DB hesabınızda yönetilen kimliğe geçtiniz, veri rolünü atadınız, kodu DefaultAzureCredential ile güncellediniz ve anahtar tabanlı erişimi kapattınız. Dağıtımdan sonra her istekten aynı yanıt geliyor: Response status code does not indicate success: 403 (Forbidden). Bu yazıda, RBAC’e geçtikten sonra sık karşılaşılan 403 senaryolarına, hatanın nasıl doğru okunacağına ve uygulamanın en kısa sürede tekrar çalışır hale nasıl getirileceğine bakılıyor.
403 hatasını doğru okumak
RBAC geçişi sırasında alınan 403 çoğu zaman kimlik doğrulamanın başarılı olduğu anlamına gelir. Yani Cosmos DB, isteği yapan kimliği tanımıştır; sorun bu kimliğin ilgili işlemi gerçekleştirmek için yetkilendirilmemiş olmasıdır.
Bu ayrım aramaya nereden başlanacağını belirler. Bozuk bir kimlik bilgisi veya hatalı bir managed identity peşinde koşmak yerine eksik rol ataması, yanlış principal, dar kapsam ve benzeri yetkilendirme sorunlarına odaklanmak gerekir.
Yine de suçu doğrudan RBAC’e yüklemeden önce tam hata mesajını ve substatus kodunu okuyun. Cosmos DB, ağ kısıtlamaları ve diğer yapılandırma sorunları için de 403 döndürebilir; detaylar çoğu zaman yönü gösterir.
En sık karşılaşılan beş neden
1. Control plane rolü atayıp data plane erişimi beklemek
En yaygın hata bu ayrımı gözden kaçırmaktan doğar: control plane ve data plane iki ayrı sistemdir. Uygulamaya Contributor gibi bir Azure yönetim rolü vermek; hesabı yapılandırma, ağ ayarlarını yönetme veya hesap anahtarlarını okuma gibi işlemlere izin verir. Ama veri düzleminde okuma, yazma ya da sorgulama yetkisi vermez. Onun için ayrı bir Azure Cosmos DB veri düzlemi rolü ataması gerekir.
İlk adım, data plane üzerindeki mevcut atamaları listelemek:
az cosmosdb sql role assignment list \
--account-name "$ACCOUNT" \
--resource-group "$RESOURCE_GROUP"
Uygulamanın principalId değeri bu listede yoksa sorun ortaya çıkmıştır: yanlış türde bir rol atanmıştır. Doğrusunu az cosmosdb sql role assignment create komutuyla oluşturabilirsiniz.
2. Hiç veri rolü ataması yapılmamış olabilir
Bazen atama hiç yapılmamış ya da beklediğinizden farklı bir principal’a düşmüştür. Klasik senaryo şu: rolü kendi geliştirici kimliğinize verdiniz ama uygulamanın managed identity’sine hiç atamadınız. Sonuç: yerelde sorunsuz çalışan uygulama, Azure’da ilk çağrıda 403 döner.
Uygulamanın gerçekten hangi principalId ile çalıştığını doğrulayın, sonra bu ID’nin atamasının olup olmadığını kontrol edin:
# Uygulamanın kullandığı managed identity
az webapp identity show \
--name my-app \
--resource-group "$RESOURCE_GROUP" \
--query principalId -o tsv
Bu değeri önceki komutun çıktısıyla karşılaştırın. Listede yoksa çözüm nettir: doğru principal için atamayı oluşturun.
3. Kapsam (scope) çok dar
Her rol ataması bir kapsama bağlıdır. Atamayı tek bir container’a yaptıysanız ve uygulama farklı bir veritabanına ya da container’a erişmeye çalışıyorsa, tam da erişim vermediğiniz yolda 403 alırsınız. Rol vardır ama yeterince geniş değildir.
Atamanın scope değerine bakın. Belirli bir veritabanı veya container’ı işaret ediyorsa ve uygulama daha fazlasına dokunuyorsa kapsamı genişletin. Uygulamayı ilk kez çalıştırıyorsanız hesap kökü (/) düzeyinde başlamak, her şey yeşile döndükten sonra daraltmak pratik bir yaklaşımdır.
4. Atama henüz yayılıyor olabilir
Yeni oluşturulmuş bir rol ataması anında etkinleşmeyebilir. 403 hatası, atamayı oluşturduğunuz veya değiştirdiğiniz hemen ardından başladıysa kod ya da izinlerde değişiklik yapmadan önce yayılma için biraz zaman tanıyın ve tekrar deneyin.
5. DisableLocalAuth açık ama kod hala anahtar kullanıyor
disableLocalAuth: true ayarını yaptığınız anda Cosmos DB anahtar ve bağlantı dizesi kabul etmeyi bırakır; tüm istekler Entra ID üzerinden geçmek zorundadır. Uygulamanızın bir köşesinde, unutulmuş bir arka plan işinde, bir health check’te ya da eski bir yapılandırma değerinde hala anahtarla client oluşturuluyorsa o yol 403 dönerken diğer her şey sorunsuz çalışabilir.
Kodda ve yapılandırmada bağlantı dizelerini ve AccountKey kullanımlarını arayın. Tüm client’lar TokenCredential ile kurulmalıdır:
// disableLocalAuth açıkken bu satır 403 döner
var client = new CosmosClient(connectionString);
// Doğru kullanım
var client = new CosmosClient(
accountEndpoint: "https://my-cosmos-account.documents.azure.com:443/",
tokenCredential: new DefaultAzureCredential());
Hızlı tanı sırası
Bir 403 ile karşılaşıldığında aşağıdaki sırayı takip etmek işleri hızlandırır. Liste kabaca hangi nedenin ne sıklıkta çözüm olduğuna göre düzenlenmiştir:
- Yalnızca Azure RBAC değil, gerçek bir veri düzlemi rol atamanız var mı?
- Atama, uygulamanın gerçekten kullandığı principal üzerinde mi?
- Kapsam, uygulamanın eriştiği tüm veritabanı ve container’ları kapsıyor mu?
- Atama çok yeni mi? Bozulmuş olduğuna hükmetmeden önce birkaç dakika bekleyip tekrar deneyin.
- Herhangi bir kod yolu hala anahtar veya bağlantı dizesi kullanıyor mu?
Çoğu vakada çözüm ilk iki adımı geçmeden bulunur.
Güvenli geçiş için doğru sıra
403 uçurumundan kaçınmanın en iyi yolu tüm anahtarları aynı anda kapatmamak. Anahtarlar açıkken RBAC’i tam olarak çalışır hale getirin, sonra anahtarları devre dışı bırakın:
- Uygulamanın kimliğine veri düzlemi rolünü atayın.
- Kodu
DefaultAzureCredentialkullanacak şekilde güncelleyip dağıtın. - Uygulamanın bu kimlikle veriyi okuyup yazdığını doğrulayın; anahtarlar hala açık olsun.
- Ancak bu adımdan sonra
disableLocalAuth: trueolarak ayarlayın.
Dördüncü adımda bir şey bozulursa, kimlik yolunun saniyeler önce çalıştığını bildiğiniz için tüm rol yapılandırmasını sorgulamak yerine doğrudan beşinci şüpheliye, yani unutulmuş bir anahtar kullanımına odaklanabilirsiniz. Bu sıralama, kafa karıştırıcı bir hatayı belirgin bir hataya dönüştürür.
Toparlarken
Cosmos DB üzerinde şifresiz kimlik doğrulama ilk 403 hatasında ürkütücü görünse de hata modları sınırlıdır ve her biri kısa sürede çözülebilir. Kimlik doğrulama ile yetkilendirmenin farklı sorunlar, control plane ile data plane’in farklı sistemler olduğu içselleştirildiğinde hata bir gizem olmaktan çıkar, kontrol listesine dönüşür.
Pratik bir öneri: hala anahtar veya bağlantı dizesiyle çalışan bir uygulamayı seçip önce üretim dışı bir ortamda DefaultAzureCredential‘a taşıyın. Kimlik yolu kanıtlanana kadar anahtarları açık tutun, sonra disableLocalAuth: true ile kapıyı kapatın.
Kaynaklar ve İleri Okuma
- I Enabled RBAC and Everything Broke. What Did I Do Wrong? – Azure Cosmos DB Blog
- Which Azure Cosmos DB Role Does My App Need? – Azure Cosmos DB Blog
- Azure Cosmos DB Blog
- Cosmos DB Azure RBAC Entegrasyonu: İki Dünya Birleşiyor
- Azure Storage API’larında Entra ID ve RBAC Dönemi: Pratikte Ne Değişti?
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.
Yorum gönder