Azure Ad Pod Identity AKS üzerinde bulunan pod’ların Azure üzerindeki kaynaklara erişip belli processleri gerçekleştirmesi için gerekli yetkileri sağlar. Şimdi adım adım pod identity kavramını ele alalım.
Önce managed identity kavramını ele alalım.
Cloud üzerinde yapılandırılan yada barındırılan uygulamalar için en önemli durumlardan bir tanesi uygulamanın cloud üzerinde bulunan servislere erişmesi için gerekli olan kimlik bilgilerinin code düzeyinde nasıl yönetileceğidir. Tabiki uygulama için kullanılacak kimlik bilgilerinin,secret’ların yada sertifikaların Azure Key Vault üzerinde tutulması bir çözümdür. Ancak böyle bir durumda da uygulamanın Key Vault’a erişebilmesi için bir kimlik doğrulama sürecinden geçmesi gerekir.
Tam bu noktada Managed Service Identity özelliği ile yukarıdaki sorun çözümlenir. Platform servislerine erişmek için gerekli olan identity’ler Azure Active Directory tarafından yönetilir. Burada platform üzerinde erişilecek servisin Azure AD kimlik doğrulama metodunu desteklemesi gerekir. Bunun sonucunda uygulamanıza ait kod hiç bir şekilde platforma bağlanmayı sağlayan kimlik doğrulama bilgilerini içermez ve kimlik bilgileri güvenli bir biçimde platform üzerinde saklanmış olur.
Managed Service Identity platform üzerindeki bir servisin (örn vm) platform üzerinde bir identity’e sahip olmasına izin verir. Bu VM üzerinde çalışan uygulama erişim için gerekli olan token’ı direct olarak VM’in kendisinden alır. Böylece credential’lar hiç bir şekilde bilinmez ve ele geçirilmez. Ayrıca credential’ların belirli aralıklar ile yenilenmesi tamamen platform tarafından kontrol edilir.
Peki MIS ve Pod Identity farklı şeyler mi?
Aslında yukarıda bahsettiğim durum ile aynı şey söz konusudur. Tek fark burada MIS’i kullanacak birim Vm yerine AKS mimarisindeki pod birimidir. Azure Ad Pod Identity sayesinde AKS üzerinde oluşturulan objeler ile pod’lar Azure platformu üzerindeki MIS’leri kullanabilir hale gelirler. Bu mekanizmada kullanıcılar tarafından Azure üzerinde managed service identity’ler oluşturulur. Bu identity’lere yetki atanır ve ardından direct olarak pod’a bind edilir. Böylece pod erişim için gerekli olan token’ı authentication süreci olmadan direkt olarak elde eder. Pod’lara bind işlemi yapabilmek için de MIS için AKS cluster içerisinde Azure Identity objeleri oluşturulur. Binding bu objeler kullanılarak yapılır.
Bahsedilen iki mimari için de erişim için gerekli olan token Azure Instance Metadata Service Identity Endpoint üzerinden get edilir. http://169.254.169.254/metadata/identity/oauth2/token bu endpoint sadece oluşturulan managed identity’leri kullanma yetkisi olan uygulamalar tarafından erişilebilir.
Azure Pod Identity mimarisinde iki adet pod görev yapar. Bunlardan bir tanesi NodeManagedIdentity(NMI), diğeri ise Managed Identity Controller (MIC)’tir.
NMI daemon set olarak tüm node’lar üzerinde çalışır. Instance metadata Service Endpoint’ine yapılacak olan token istekleri pod’lar üzerinden öncelikle node üzerinde daemon set olarak çalışan NMI’a gelir. Sonra NMI pod’lar adına Instance Metadata Service Endpoint’inden token ister.
Deployment olarak deploy edilen MIC ise controller olarak görev yapar. Görevi Identity yetkisi olan pod’ları kontrol etmek ve Kube API server’ı izleyip yeni oluşturulan pod’ların identity ilişkilerini yönetmektir.
Deployment sonrasında AKS üzerinde ne gibi bileşenler oluşur?
AAD Pod identity ile AKS üzerinde 3 adet custom resource oluşur.
- AzureIdentity
- AzureIdentityBinding
- AzureAssignedIdentity
İlk iki custom bileşen pod’lar tarafından kullanılırken, 3. bileşen ise MIC tarafından kullanılır.
Aadpodidbinding label’ı kullanılarak pod’lar Azure identity’e bind edilirler.
Azure üzerinden Identity oluşturulduğunda bu identity bind edilmediği sürece kullanılmaz. Bu sebeple AzureIdentityBinding objesinin oluşturulması gerekir. Bu obje ile AzureIdentity objesi pod’lar ile eşleştirilir. Bu eşleşmeyi sağlayan şey pod üzerindeki “Aadpodidbinding” label’ıdır. MIC pod’ları bu label’lar vasıtasıyla bulur, ardından bu pod’lar için oluşturulmuş olan routing table’ı kullanarak instance metadata service endpoint’i için yapılan istekleri NMI’a yönlendirir. Aryrıca API server’ı izleyerek yeni oluşturulan pod’ların ilgili label’ı taşıyıp taşımadıklarını kontrol eder.
Birazda temel mimariye göz atalım
Bu işlemleri biraz daha açacak olursak, yukarıdaki örnek mimari için süreç şu şekilde işler.
- Cluster içerisindeki bir pod Azure üzerinde bir resource’a erişmek istediğinde token’a ihtiyaç duyar. Bu sebeple network kuralları trafiği NMI’a yönlendirir.
- NMI remote adrese bakarak pod’un erişmek istediği resource’u belirler. Bu işlemin ardından MIC’e Azure üzerindeki resource’a erişim yetkisi olup olmadığını öğrenmek için sorguda bulunur.
- MIC cluster üzerindeki Azure Identity Binding’i controller eder.
- NMI server bu mapping’e bağlı olarak instance metadata service endpoint üzerinden erişim için gerekli olan token’ı Azure Managed Service Identity’den ister.
- Ardından pod alınan token’ı kullanarak Azure üzerindeki ilgili resource’a erişim sağlar.
AKS Cluster zaten Azure platformu üzerinde yetkili değil mi?
AKS cluster kendi service principal’ını kullanarak Azure platformu üzerinde beli işler yapar. Örneğin load balancer tipinde service oluşturulduğunda, buna karşılık platform üzerinde load balancer oluşturur. Yada persistent volume gerekli olduğunda platform üzerinde managed disk yada file storage oluşturabilir. Cluster kurulduktan sonra kullanılan service principal default olarak AKS node’larına ait vm’leri barındıran resource group üzerinde contributor yetkisine sahiptir. Bu sebeple bu resource’ları yetki sahibi olduğu MC_ uzantılı resource group altında oluşturur.
Azure ad pod identity konfigürasyonu yapılırken, cluster için kullanılan bu service principal’a bir de pod’lar için token isteme yetkisi atanır. Bu yetki için bu principal’a Managed Identity Operator yetkisi verilir.
Managed Identity Operator rolünün yapabileceği actionları görüntülemek için aşağıdaki komutu çalıştırmanız yeterlidir.
az role definition list — query “[?roleName == ‘Managed Identity Operator’]” -o jsonc
NOT: Eğer oluşturmuş olduğunuz managed service identity objesi Azure platformu üzerinde AKS’ye ait node vm’lerini barındıran MC_ prefix’e sahip resource group içerisinde ise, cluster’a ait olan service principal’a bu yetkiyi atamanız gerekmez. Çünkü belirtilen resource group üzerinde ilgili service principal hali hazırda contributor yetkisine sahiptir. Bu da managed service identity’den token isteyebilir anlamına gelir.
Biraz teknik bir makale oldu. Bir kaç örnek ile bir sonraki makalede işi daha anlaşılır hale getireceğim 🙂
Görüşmek üzere.