Azure Cosmos DB RBAC: Tek Kişilik Projede Gerekli mi?
Hesap sizin, uygulamayı siz yazdınız, bir şey bozulursa düzeltecek olan da yine sizsiniz. Böyle bir tabloda role-based access control (RBAC) sahip olmadığınız bir sorunun, yani başkalarının erişimini yönetmenin çözümü gibi görünebilir. Azure Cosmos DB ekibinden Sudhanshu Khera ve Iria Osara’nın yazısı tam da bu itiraza cevap veriyor. Yazıya göre RBAC’ın gerekçesi ekip büyüklüğünde değil, taşıdığınız gizli bilgi sayısını azaltmakta ve kodunuza yalnızca ihtiyacı olan yetkiyi vermekte.
Uygulamanızın çalışması için RBAC zorunlu değil, bunu baştan söylemek gerekiyor. Key tabanlı kimlik doğrulama açık olduğu sürece account key’ler çalışmaya devam eder. Yine de uzun ömürlü tutmayı planladığınız canlı bir Azure Cosmos DB for NoSQL projesinde, tek geliştirici siz olsanız bile kimlik tabanlı erişim daha iyi bir varsayılan.
Uygulamanızın sizin tüm yetkilerinize ihtiyacı yok
Siz hesabı yapılandırıyor, veriyi inceliyor, ara sıra bakım işleri yürütüyor olabilirsiniz. Deploy ettiğiniz uygulamanın işi ise çoğu zaman tek bir container içinde item okumak ve yazmak. Aynı kişi ikisini birden yapıyor olsa da bunlar farklı işler.
Aynı hesapta birden fazla projeniz olduğunu düşünün. Uygulamanın kimliğine yalnızca kendi database veya container’ıyla sınırlı bir data role verebilirsiniz. Her iki projenin de sahibi olmanız, uygulamanın diğer projenin verisine erişmesi için bir gerekçe sayılmaz. Bir hata yüzünden kod kendi kapsamı dışındaki veriyi istediğinde o izin sınırı devreye girer.
Tek kişilik bir projede erişimi ayırmanın özü bu: kodunuz, projeyi yönetmek için size gereken her izni miras almamalı.
Kimlik doğrulama ve yetki sınırı, iki ayrı kazanç
Mekanizmanın iki parçası var. Microsoft Entra ID, kodunuz bir account key sunmak yerine kimliği doğrular. Cosmos DB’nin data plane RBAC’ı ise o kimliğin ne yapabileceğini ve nerede yapabileceğini belirler.
Bu iki fayda birbirinden bağımsız. Anahtarı kaldırmak ayrı iş, izinleri daraltmak ayrı iş; gereğinden geniş yetkiye sahip bir kimlik kullandığınızda yalnızca ilki hallolur, ikincisi olduğu yerde kalır.
Anahtarla başlamak hızlıdır, ama bakımı size kalır
Anahtarı yerel bir .env dosyasında tutmak ve kaynak kontrolünün dışında bırakmak, onu yayımlamakla aynı şey değil; bu önlem gerçekten önemli. Ancak kullanıldığı her yerde anahtarı koruma ve değiştirme işini ortadan kaldırmaz.
Yazıda verilen örnek tanıdık. Uygulamanızın kullandığı anahtarı rotate ediyorsunuz, sonra bir ay önce son kez açtığınız bir notebook’u açıyorsunuz. Uygulama çalışıyor, ama notebook’ta hala eski kimlik bilgisi duruyor. Artık yalnızca kodunuzu değil, bu kopyalar arasındaki bağı da sürdürüyorsunuz. Bu zahmetin doğması için bir takım arkadaşına ihtiyaç olmadı.
Kimlik tabanlı erişim, account key’i bu kod yollarından çıkarır. Yerel araçlarınız geliştirici oturumunuzu kullanabilir; managed identity destekleyen bir Azure host’ta çalışan uygulama ise kendi managed identity’sini kullanabilir. SDK’daki credential yardımcıları access token almayı üstlenir, sizden account key beklemez.
Bunun bir başlangıç maliyeti var: oturum açmak, rol atamak, SDK yapılandırmasını güncellemek ve erişimi doğrulamak. Yerel geliştirme sırasında yeniden oturum açmanız gerekebilir, izinlerin doğru olması da hala şart. Yani “hiç kimlik doğrulama işi kalmıyor” diye bir vaat yok; takas, sürekli account key yönetimi yerine bir kerelik kimlik kurulumu.
Projenize uyan en küçük kurulum
Kurulumu, ileride kurabileceğiniz bir organizasyona göre değil, kodunuzun bugün çalıştığı yere göre seçin.
| Durumunuz | İhtiyacınız olan |
|---|---|
| Yalnızca local emulator kullanıyorsunuz | Emulator’ın geliştirme anahtarı; canlı hesap yapılandırmasından ayrı tutulmuş halde. |
| Kod yerelde çalışıyor ama canlı bir Cosmos DB hesabına bağlanıyor | Mevcut geliştirici kimliğiniz ve yapmanız gereken işle sınırlanmış bir data role. |
| Managed identity destekleyen bir Azure host’a deploy ediyorsunuz | Uygulamanın kendi managed identity’si ve uygun kapsamda data role; kişisel oturumunuzdan ayrı. |
Gerçekten aynı geliştirici erişimine ihtiyaç duyan yerel araçlar mevcut oturumunuzu kullanabilir. Her notebook için yeni bir kimlik, somut bir gereksinim ortaya çıkmadan custom role, pipeline’ınız yokken pipeline kimliği oluşturmanıza gerek yok.
Emulator’ın geliştirme anahtarı canlı hesabınız için bir kimlik bilgisi sayılmaz. Ortamını ayrı tutun, başka makinelere açılmış bir emulator’ı da otomatik olarak güvenli saymayın.
Hangi rolü seçmeliyim?
Rol, bir kimliğin ne yapabileceğini tanımlar. Rol ataması ise o rolü belirli bir scope‘ta verir: hesap, database ya da container.
| Kimliğin yapması gereken | Seçilecek Cosmos DB data role |
|---|---|
| Item okumak ve sorgu çalıştırmak, veriyi değiştirmeden | Cosmos DB Built-in Data Reader |
| Item okumak, oluşturmak, güncellemek ve silmek | Cosmos DB Built-in Data Contributor |
Örneğin sipariş okuyup yazan bir uygulama, tüm hesap yerine yalnızca orders container’ı kapsamında Data Contributor kullanabilir. Geliştirici kimliğiniz ise ayrı bir atamayla aynı rolü bir development database üzerinde kullanabilir. Aynı rol, farklı kimlikler, farklı kapsamlar.
Bunlar data role‘dür; kaynak yönetimi için kullanılan Azure Owner veya Contributor rolleriyle aynı şey değildir. Hesabın Owner’ı olmanız, içindeki item’lara otomatik erişim vermez.
RBAC’ın çözmediği şeyler
Yalnızca Data Reader rolüne sahip bir kimlik item değiştiremez. Data Contributor ise silme yetkisini de içerir. Uygulamanızın bir item’ı silme izni varsa ve bir hata ona bunu yaptırıyorsa, RBAC bunun yanlışlıkla olduğunu bilemez.
Dar bir scope, bir kimliğin hangi veriye ulaşabileceğini sınırlar, o scope içinde oluşan hasarı geri almaz. Geliştirici oturumunuzu korumaya, uygulama davranışını doğrulamaya ve uygun yedekleri sürdürmeye devam etmeniz gerekir. Kimlik tabanlı erişim account key yönetimini ortadan kaldırır, tüm güvenlik ve kurtarma sorumluluğunu değil.
Hala key kullanıyorsanız önce tek bir yolu değiştirin
Çalışan bir yan projeyi bir noktayı kanıtlamak uğruna kesintiye uğratmayın. Kademeli ilerleyin:
- Tek bir kod yolunu kimlik tabanlı erişime geçirin. İlgili kimliğe uygun data role ve scope’u verin, ardından gerçekten ihtiyaç duyduğu okuma ve yazma işlemlerini doğrulayın.
- Canlı hesaba bağlı diğer tüm bağımlılıkları kapsayın. Deploy edilmiş uygulama, notebook, zamanlanmış iş ve bakım script’leri dahil. Başarılı bir yerel test, bunların aynı kimliği veya aynı doğrulama yöntemini kullandığını kanıtlamaz.
- Doğrulamadan sonra anahtar yolunu kapatın. Her bağımlılık kimlik tabanlı erişimle çalıştığında key tabanlı kimlik doğrulamayı devre dışı bırakın ve kullanılmayan canlı hesap anahtarlarını yapılandırmadan kaldırın. Anahtarları devre dışı bırakmak hesabın tamamını etkiler.
Uygulama tarafı için Cosmos DB ekibinin rol seçimi ve geliştirici kimliğine veri erişimi verme rehberleri yol gösterici. Erişim başarısız olursa RBAC sorun giderme yazısı yaygın nedenleri ele alıyor.
Yeni bir canlı projede kimlik tabanlı erişimi baştan seçerseniz, anahtara bağımlı yolları sonradan taşıma işinden kurtulursunuz. Mevcut bir projede değişikliğin gerekçesini ikinci bir geliştiricinin katılıp katılmayacağında değil, halihazırda sahip olduğunuz veri ve bakım yükünde aramak gerekiyor. İzinleri gelecekteki bir organizasyon için tasarlamak zorunda değilsiniz; elinizdeki projeyi koruyun, canlı erişim için kimlik kullanın, her kimliğe yalnızca ihtiyacı olanı verin, ekip mekanizmalarını işin dışında bırakın.
Kaynaklar ve İleri Okuma
- I’m the Only Developer on This Project. Do I Really Need RBAC? — Azure Cosmos DB Blog
- Which Azure Cosmos DB Role Does My App Need?
- Microsoft Learn: Cosmos DB’de RBAC ile veri erişimi verme
- I Enabled RBAC and Everything Broke: sorun giderme
- Microsoft Learn: Azure Cosmos DB Emulator
- Cosmos DB Azure RBAC Entegrasyonu: İki Dünya Birleşiyor
- Azure Cosmos DB vNext Emulator: Yerelde Gerçek Gibi Test Etmek
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