{"id":202,"date":"2023-01-22T19:18:00","date_gmt":"2023-01-22T19:18:00","guid":{"rendered":"http:\/\/blog.firatyasar.com\/?p=202"},"modified":"2023-03-19T19:25:29","modified_gmt":"2023-03-19T19:25:29","slug":"aks-mimarisinde-pod-identity-kavrami","status":"publish","type":"post","link":"https:\/\/blog.firatyasar.com\/?p=202","title":{"rendered":"AKS mimarisinde Pod Identity kavram\u0131"},"content":{"rendered":"\n

Azure Ad Pod Identity<\/strong>\u00a0AKS \u00fczerinde bulunan pod’lar\u0131n Azure \u00fczerindeki kaynaklara eri\u015fip belli processleri ger\u00e7ekle\u015ftirmesi i\u00e7in gerekli yetkileri sa\u011flar. \u015eimdi ad\u0131m ad\u0131m pod identity kavram\u0131n\u0131 ele alal\u0131m.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

\u00d6nce managed identity kavram\u0131n\u0131 ele alal\u0131m.<\/strong><\/p>\n\n\n\n

Cloud \u00fczerinde yap\u0131land\u0131r\u0131lan yada bar\u0131nd\u0131r\u0131lan uygulamalar i\u00e7in en \u00f6nemli durumlardan bir tanesi uygulaman\u0131n cloud \u00fczerinde bulunan servislere eri\u015fmesi i\u00e7in gerekli olan kimlik bilgilerinin code d\u00fczeyinde nas\u0131l y\u00f6netilece\u011fidir. Tabiki uygulama i\u00e7in kullan\u0131lacak kimlik bilgilerinin,secret\u2019lar\u0131n yada sertifikalar\u0131n Azure Key Vault \u00fczerinde tutulmas\u0131 bir \u00e7\u00f6z\u00fcmd\u00fcr. Ancak b\u00f6yle bir durumda da uygulaman\u0131n Key Vault\u2019a eri\u015febilmesi i\u00e7in bir kimlik do\u011frulama s\u00fcrecinden ge\u00e7mesi gerekir.<\/p>\n\n\n\n

Tam bu noktada Managed Service Identity \u00f6zelli\u011fi ile yukar\u0131daki sorun \u00e7\u00f6z\u00fcmlenir. Platform servislerine eri\u015fmek i\u00e7in gerekli olan identity\u2019ler Azure Active Directory taraf\u0131ndan y\u00f6netilir. Burada platform \u00fczerinde eri\u015filecek servisin Azure AD kimlik do\u011frulama metodunu desteklemesi gerekir. Bunun sonucunda uygulaman\u0131za ait kod hi\u00e7 bir \u015fekilde platforma ba\u011flanmay\u0131 sa\u011flayan kimlik do\u011frulama bilgilerini i\u00e7ermez ve kimlik bilgileri g\u00fcvenli bir bi\u00e7imde platform \u00fczerinde saklanm\u0131\u015f olur.<\/p>\n\n\n\n

Managed Service Identity platform \u00fczerindeki bir servisin (\u00f6rn vm) platform \u00fczerinde bir identity\u2019e sahip olmas\u0131na izin verir. Bu VM \u00fczerinde \u00e7al\u0131\u015fan uygulama eri\u015fim i\u00e7in gerekli olan token\u2019\u0131 direct olarak VM\u2019in kendisinden al\u0131r. B\u00f6ylece credential\u2019lar hi\u00e7 bir \u015fekilde bilinmez ve ele ge\u00e7irilmez. Ayr\u0131ca credential\u2019lar\u0131n belirli aral\u0131klar ile yenilenmesi tamamen platform taraf\u0131ndan kontrol edilir.<\/p>\n\n\n\n

Peki MIS ve Pod Identity farkl\u0131 \u015feyler mi?<\/strong><\/p>\n\n\n\n

Asl\u0131nda yukar\u0131da bahsetti\u011fim durum ile ayn\u0131 \u015fey s\u00f6z konusudur. Tek fark burada MIS\u2019i kullanacak birim Vm yerine AKS mimarisindeki pod birimidir. Azure Ad Pod Identity sayesinde AKS \u00fczerinde olu\u015fturulan objeler ile pod\u2019lar Azure platformu \u00fczerindeki MIS\u2019leri kullanabilir hale gelirler. Bu mekanizmada kullan\u0131c\u0131lar taraf\u0131ndan Azure \u00fczerinde managed service identity\u2019ler olu\u015fturulur. Bu identity\u2019lere yetki atan\u0131r ve ard\u0131ndan direct olarak pod\u2019a bind edilir. B\u00f6ylece pod eri\u015fim i\u00e7in gerekli olan token\u2019\u0131 authentication s\u00fcreci olmadan direkt olarak elde eder. Pod\u2019lara bind i\u015flemi yapabilmek i\u00e7in de MIS i\u00e7in AKS cluster i\u00e7erisinde Azure Identity objeleri olu\u015fturulur. Binding bu objeler kullan\u0131larak yap\u0131l\u0131r.<\/p>\n\n\n\n

Bahsedilen iki mimari i\u00e7in de eri\u015fim i\u00e7in gerekli olan token Azure Instance Metadata Service Identity Endpoint<\/strong> \u00fczerinden get edilir. http:\/\/169.254.169.254\/metadata\/identity\/oauth2\/token<\/a> bu endpoint sadece olu\u015fturulan managed identity\u2019leri kullanma yetkisi olan uygulamalar taraf\u0131ndan eri\u015filebilir.<\/p>\n\n\n\n

Azure Pod Identity mimarisinde iki adet pod g\u00f6rev yapar. Bunlardan bir tanesi NodeManagedIdentity(NMI),<\/strong> di\u011feri ise Managed Identity Controller (MIC)\u2019<\/strong>tir.<\/p>\n\n\n\n

NMI<\/strong> daemon set olarak t\u00fcm node\u2019lar \u00fczerinde \u00e7al\u0131\u015f\u0131r. Instance metadata Service Endpoint\u2019ine yap\u0131lacak olan token istekleri pod\u2019lar \u00fczerinden \u00f6ncelikle node \u00fczerinde daemon set olarak \u00e7al\u0131\u015fan NMI\u2019a gelir. Sonra NMI pod\u2019lar ad\u0131na Instance Metadata Service Endpoint\u2019inden token ister.<\/p>\n\n\n\n

Deployment olarak deploy edilen MIC ise controller olarak g\u00f6rev yapar. G\u00f6revi Identity yetkisi olan pod\u2019lar\u0131 kontrol etmek ve Kube API server\u2019\u0131 izleyip yeni olu\u015fturulan pod\u2019lar\u0131n identity ili\u015fkilerini y\u00f6netmektir.<\/p>\n\n\n\n

Deployment sonras\u0131nda AKS \u00fczerinde ne gibi bile\u015fenler olu\u015fur?<\/strong><\/p>\n\n\n\n

AAD Pod identity ile AKS \u00fczerinde 3 adet custom resource olu\u015fur.<\/p>\n\n\n\n

  1. AzureIdentity<\/li>
  2. AzureIdentityBinding<\/li>
  3. AzureAssignedIdentity<\/li><\/ol>\n\n\n\n

    \u0130lk iki custom bile\u015fen pod\u2019lar taraf\u0131ndan kullan\u0131l\u0131rken, 3. bile\u015fen ise MIC taraf\u0131ndan kullan\u0131l\u0131r.<\/p>\n\n\n\n

    Aadpodidbinding<\/strong> label\u2019\u0131 kullan\u0131larak pod\u2019lar Azure identity\u2019e bind edilirler.<\/p>\n\n\n\n

    Azure \u00fczerinden Identity olu\u015fturuldu\u011funda bu identity bind edilmedi\u011fi s\u00fcrece kullan\u0131lmaz. Bu sebeple AzureIdentityBinding objesinin olu\u015fturulmas\u0131 gerekir. Bu obje ile AzureIdentity objesi pod\u2019lar ile e\u015fle\u015ftirilir. Bu e\u015fle\u015fmeyi sa\u011flayan \u015fey pod \u00fczerindeki \u201cAadpodidbinding<\/strong>\u201d label\u2019\u0131d\u0131r. MIC pod\u2019lar\u0131 bu label\u2019lar vas\u0131tas\u0131yla bulur, ard\u0131ndan bu pod\u2019lar i\u00e7in olu\u015fturulmu\u015f olan routing table\u2019\u0131 kullanarak instance metadata service endpoint\u2019i i\u00e7in yap\u0131lan istekleri NMI\u2019a y\u00f6nlendirir. Aryr\u0131ca API server\u2019\u0131 izleyerek yeni olu\u015fturulan pod\u2019lar\u0131n ilgili label\u2019\u0131 ta\u015f\u0131y\u0131p ta\u015f\u0131mad\u0131klar\u0131n\u0131 kontrol eder.<\/p>\n\n\n\n

    Birazda temel mimariye g\u00f6z atal\u0131m<\/strong><\/p>\n\n\n\n

    \"\"\/<\/figure>\n\n\n\n

    Bu i\u015flemleri biraz daha a\u00e7acak olursak, yukar\u0131daki \u00f6rnek mimari i\u00e7in s\u00fcre\u00e7 \u015fu \u015fekilde i\u015fler.<\/p>\n\n\n\n

    1. Cluster i\u00e7erisindeki bir pod Azure \u00fczerinde bir resource\u2019a eri\u015fmek istedi\u011finde token\u2019a ihtiya\u00e7 duyar. Bu sebeple network kurallar\u0131 trafi\u011fi NMI\u2019a y\u00f6nlendirir.<\/li>
    2. NMI remote adrese bakarak pod\u2019un eri\u015fmek istedi\u011fi resource\u2019u belirler. Bu i\u015flemin ard\u0131ndan MIC\u2019e Azure \u00fczerindeki resource\u2019a eri\u015fim yetkisi olup olmad\u0131\u011f\u0131n\u0131 \u00f6\u011frenmek i\u00e7in sorguda bulunur.<\/li>
    3. MIC cluster \u00fczerindeki Azure Identity Binding\u2019i controller eder.<\/li>
    4. NMI server bu mapping\u2019e ba\u011fl\u0131 olarak instance metadata service endpoint \u00fczerinden eri\u015fim i\u00e7in gerekli olan token\u2019\u0131 Azure Managed Service Identity\u2019den ister.<\/li>
    5. Ard\u0131ndan pod al\u0131nan token\u2019\u0131 kullanarak Azure \u00fczerindeki ilgili resource\u2019a eri\u015fim sa\u011flar.<\/li><\/ol>\n\n\n\n

      AKS Cluster zaten Azure platformu \u00fczerinde yetkili de\u011fil mi?<\/strong><\/p>\n\n\n\n

      AKS cluster kendi service principal\u2019\u0131n\u0131 kullanarak Azure platformu \u00fczerinde beli i\u015fler yapar. \u00d6rne\u011fin load balancer tipinde service olu\u015fturuldu\u011funda, buna kar\u015f\u0131l\u0131k platform \u00fczerinde load balancer olu\u015fturur. Yada persistent volume gerekli oldu\u011funda platform \u00fczerinde managed disk yada file storage olu\u015fturabilir. Cluster kurulduktan sonra kullan\u0131lan service principal default olarak AKS node\u2019lar\u0131na ait vm\u2019leri bar\u0131nd\u0131ran resource group \u00fczerinde contributor yetkisine sahiptir. Bu sebeple bu resource\u2019lar\u0131 yetki sahibi oldu\u011fu MC_ uzant\u0131l\u0131 resource group alt\u0131nda olu\u015fturur.<\/p>\n\n\n\n

      Azure ad pod identity konfig\u00fcrasyonu yap\u0131l\u0131rken, cluster i\u00e7in kullan\u0131lan bu service principal\u2019a bir de pod\u2019lar i\u00e7in token isteme yetkisi atan\u0131r. Bu yetki i\u00e7in bu principal\u2019a Managed Identity Operator yetkisi verilir.<\/p>\n\n\n\n

      Managed Identity Operator rol\u00fcn\u00fcn yapabilece\u011fi actionlar\u0131 g\u00f6r\u00fcnt\u00fclemek i\u00e7in a\u015fa\u011f\u0131daki komutu \u00e7al\u0131\u015ft\u0131rman\u0131z yeterlidir.<\/p>\n\n\n\n

      az role definition list \u2014 query \u201c[?roleName == \u2018Managed Identity Operator\u2019]\u201d -o jsonc<\/strong><\/p>\n\n\n\n

      NOT:<\/strong>\u00a0E\u011fer olu\u015fturmu\u015f oldu\u011funuz managed service identity objesi Azure platformu \u00fczerinde AKS\u2019ye ait node vm\u2019lerini bar\u0131nd\u0131ran MC_ prefix\u2019e sahip resource group i\u00e7erisinde ise, cluster\u2019a ait olan service principal\u2019a bu yetkiyi ataman\u0131z gerekmez. \u00c7\u00fcnk\u00fc belirtilen resource group \u00fczerinde ilgili service principal hali haz\u0131rda contributor yetkisine sahiptir. Bu da managed service identity\u2019den token isteyebilir anlam\u0131na gelir.<\/p>\n\n\n\n

      Biraz teknik bir makale oldu. Bir ka\u00e7 \u00f6rnek ile bir sonraki makalede i\u015fi daha anla\u015f\u0131l\u0131r hale getirece\u011fim \ud83d\ude42<\/p>\n\n\n\n

      G\u00f6r\u00fc\u015fmek \u00fczere.<\/p>\n","protected":false},"excerpt":{"rendered":"

      Azure Ad Pod Identity\u00a0AKS \u00fczerinde bulunan pod’lar\u0131n Azure \u00fczerindeki kaynaklara eri\u015fip belli processleri ger\u00e7ekle\u015ftirmesi i\u00e7in gerekli yetkileri sa\u011flar. \u015eimdi ad\u0131m ad\u0131m pod identity kavram\u0131n\u0131 ele alal\u0131m. \u00d6nce managed identity kavram\u0131n\u0131 ele alal\u0131m. Cloud \u00fczerinde yap\u0131land\u0131r\u0131lan yada bar\u0131nd\u0131r\u0131lan uygulamalar i\u00e7in en \u00f6nemli durumlardan bir tanesi uygulaman\u0131n cloud \u00fczerinde bulunan servislere eri\u015fmesi i\u00e7in gerekli olan kimlik bilgilerinin\u2026 Read More »<\/a><\/span><\/p>\n","protected":false},"author":1,"featured_media":203,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[1],"tags":[],"_links":{"self":[{"href":"https:\/\/blog.firatyasar.com\/index.php?rest_route=\/wp\/v2\/posts\/202"}],"collection":[{"href":"https:\/\/blog.firatyasar.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.firatyasar.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.firatyasar.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.firatyasar.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=202"}],"version-history":[{"count":1,"href":"https:\/\/blog.firatyasar.com\/index.php?rest_route=\/wp\/v2\/posts\/202\/revisions"}],"predecessor-version":[{"id":204,"href":"https:\/\/blog.firatyasar.com\/index.php?rest_route=\/wp\/v2\/posts\/202\/revisions\/204"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog.firatyasar.com\/index.php?rest_route=\/wp\/v2\/media\/203"}],"wp:attachment":[{"href":"https:\/\/blog.firatyasar.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=202"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.firatyasar.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=202"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.firatyasar.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=202"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}