Azure Kubernetes Service'te Microsoft Entra ID ile Kubernetes rol tabanlı erişim denetimini kullanma

Azure Kubernetes Service (AKS), kullanıcı kimlik doğrulaması için Microsoft Entra Id kullanacak şekilde yapılandırılabilir. Bu yapılandırmada, Microsoft Entra kimlik doğrulama belirtecini kullanarak aks kümesinde oturum açarsınız. Kimlik doğrulamasından sonra, kullanıcının kimliğine veya grup üyeliğine göre ad alanlarına ve küme kaynaklarına erişimi yönetmek için yerleşik Kubernetes rol tabanlı erişim denetimini (Kubernetes RBAC) kullanabilirsiniz.

Bu makalede aşağıdaki işlemler hakkında bilgi edinirsiniz:

• Microsoft Entra grup üyeliğini temel alan bir AKS kümesinde Kubernetes RBAC kullanarak erişimi denetleme.
• Microsoft Entra Id'de örnek gruplar ve kullanıcılar oluşturun.
• Kaynak oluşturmak ve görüntülemek için uygun izinleri vermek için AKS kümesinde Roller ve RoleBindings oluşturun.

Başlamadan önce

• Microsoft Entra tümleştirmesi etkin bir AKS kümeniz var. Bu yapılandırmaya sahip bir AKS kümesine ihtiyacınız varsa bkz . Microsoft Entra ID'yi AKS ile tümleştirme.
• Aks kümesi oluşturma sırasında Kubernetes RBAC varsayılan olarak etkinleştirilir. Mevcut bir kümeyi Microsoft Entra tümleştirmesi ve Kubernetes RBAC ile yükseltmek için mevcut AKS kümenizde Microsoft Entra tümleştirmesini etkinleştirin.
• Azure CLI 2.0.61 veya sonraki bir sürümün yüklü ve yapılandırılmış olduğundan emin olun. Sürümü bulmak için az --version komutunu çalıştırın. Yüklemek veya yükseltmek için bkz . Azure CLI'yı yükleme.
• Terraform kullanıyorsanız Terraform sürüm 2.99.0 veya üzerini yükleyin.

Kubernetes RBAC ile Microsoft Entra tümleştirmesinin etkinleştirildiğini doğrulamak için Azure portalını veya Azure CLI'yi kullanın.

Azure portalı

Azure portalını kullanarak doğrulamak için:

1. Azure portalında oturum açın ve AKS küme kaynağınıza gidin.
2. Hizmet menüsünde, Ayarlar'ın altında Güvenlik yapılandırması'nı seçin.
3. Kimlik Doğrulaması ve Yetkilendirme bölümünde Kubernetes RBAC ile Microsoft Entra kimlik doğrulaması seçeneğinin belirlenip belirlenmedığını doğrulayın.

Azure CLI

Azure CLI az aks show komutunu kullanarak doğrulayabilirsiniz. myResourceGroup değerini AKS küme kaynağınızı barındıran kaynak grubu adıyla, myAKSCluster değerini ise AKS kümenizin gerçek adıyla değiştirin.

az aks show --resource-group myResourceGroup --name myAKSCluster

Etkinleştirildiğinde, çıktıda enableAzureRbac için false değeri gösterilir.

Microsoft Entra Id'de tanıtım grupları oluşturma

Bu makalede, Kubernetes RBAC ve Microsoft Entra Id'nin küme kaynaklarına erişimi nasıl denetleyeceğini göstermek için iki kullanıcı rolü oluşturacaksınız. Aşağıdaki iki örnek rol kullanılır:

• Uygulama geliştirici
  • appdev grubunun parçası olan aksdev adlı bir kullanıcı.
• Site güvenilirlik mühendisi
  • opssre grubunun bir parçası olan akssre adlı bir kullanıcı.

Üretim ortamlarında, bir Microsoft Entra kiracısı içindeki mevcut kullanıcıları ve grupları kullanabilirsiniz.

1. İlk olarak, komutunu kullanarak az aks show AKS kümenizin kaynak kimliğini alın. Ardından kaynak kimliğini diğer komutlarda başvurulabilmesi için AKS_ID adlı bir değişkene atayın.

   AKS_ID=$(az aks show \
       --resource-group myResourceGroup \
       --name myAKSCluster \
       --query id -o tsv)
   

2. komutunu kullanarak az ad group create uygulama geliştiricileri için Microsoft Entra Id'de ilk örnek grubu oluşturun. Aşağıdaki örnek appdev adlı bir grup oluşturur:

   APPDEV_ID=$(az ad group create --display-name appdev --mail-nickname appdev --query id -o tsv)
   

3. komutunu kullanarak appdev grubu için bir Azure rol ataması az role assignment create oluşturun. Bu atama, grubun kubectl herhangi bir üyesine Azure Kubernetes Service Kümesi Kullanıcı Rolü vererek aks kümesiyle etkileşimde bulunma izni verir.

   az role assignment create \
     --assignee $APPDEV_ID \
     --role "Azure Kubernetes Service Cluster User Role" \
     --scope $AKS_ID
   

   İpucu

   gibi Principal 35bfec9328bd4d8d9b54dea6dac57b82 doesn't exist in the directory a5443dcd-cd0e-494d-a387-3039b419f0d5.bir hata alırsanız, Microsoft Entra grubu nesne kimliğinin dizine yayılması için birkaç saniye bekleyin ve komutu yeniden deneyin az role assignment create .

4. opssre adlı SRE'ler için ikinci bir örnek grup oluşturun.

   OPSSRE_ID=$(az ad group create --display-name opssre --mail-nickname opssre --query id -o tsv)
   

5. Grubun üyelerine Azure Kubernetes Service Kümesi Kullanıcı Rolü vermek için bir Azure rol ataması oluşturun.

   az role assignment create \
     --assignee $OPSSRE_ID \
     --role "Azure Kubernetes Service Cluster User Role" \
     --scope $AKS_ID
   

Microsoft Entra Id'de tanıtım kullanıcıları oluşturma

Uygulama geliştiricilerimiz ve SRE'lerimiz için Microsoft Entra ID'de oluşturulmuş iki örnek grubumuz olduğuna göre, iki örnek kullanıcı oluşturursunuz. Makalenin sonunda Kubernetes RBAC tümleştirmesini test etmek için aks kümesinde bu hesaplarla oturum açarsınız.

Uygulama geliştiricileri için kullanıcı asıl adını ve parolasını ayarlama

Uygulama geliştiricileri için kullanıcı asıl adını (UPN) ve parolayı ayarlayın. UPN, kiracınızın doğrulanmış etki alanı adını içermelidir, örneğin aksdev@contoso.com. Kiracınızdaki doğrulanmış etki alanı adlarını bulmak (veya ayarlamak) için bkz. Microsoft Entra Kimliğinizde özel etki alanı adlarını yönetme.

Aşağıdaki komut sizden UPN'yi ister ve sonraki bir komutta kullanılabilmesi için AAD_DEV_UPN olarak ayarlar:

echo "Please enter the UPN for application developers: " && read AAD_DEV_UPN

Aşağıdaki komut sizden parolayı ister ve sonraki bir komutta kullanmak üzere AAD_DEV_PW olarak ayarlar:

echo "Please enter the secure password for application developers: " && read AAD_DEV_PW

Kullanıcı hesaplarını oluşturma

1. komutunu kullanarak az ad user create Microsoft Entra Id'de ilk kullanıcı hesabını oluşturun. Aşağıdaki örnek, AAD_DEV_UPN ve AAD_DEV_PWdeğerlerini kullanarak AKS Geliştirme ve UPN ve güvenli parola görünen adıyla bir kullanıcı oluşturur:

   AKSDEV_ID=$(az ad user create \
     --display-name "AKS Dev" \
     --user-principal-name $AAD_DEV_UPN \
     --password $AAD_DEV_PW \
     --query id -o tsv)
   

2. komutunu kullanarak kullanıcıyı önceki bölümde oluşturulan appdev grubuna az ad group member add ekleyin.

   az ad group member add --group appdev --member-id $AKSDEV_ID
   

3. SHRE'ler için UPN ve parolayı ayarlayın. UPN, kiracınızın doğrulanmış etki alanı adını içermelidir, örneğin akssre@contoso.com. Aşağıdaki komut sizden UPN ister ve sonraki bir komutta kullanmak üzere AAD_SRE_UPN olarak ayarlar:

   echo "Please enter the UPN for SREs: " && read AAD_SRE_UPN
   

4. Aşağıdaki komut sizden parolayı ister ve sonraki bir komutta kullanmak üzere AAD_SRE_PW olarak ayarlar:

   echo "Please enter the secure password for SREs: " && read AAD_SRE_PW
   

5. İkinci bir kullanıcı hesabı oluşturun. Aşağıdaki örnek, AAD_SRE_UPN ve AAD_SRE_PW değerlerini kullanarak AKS SRE görünen adıyla UPN ve güvenli parolaya sahip bir kullanıcı oluşturur:

   # Create a user for the SRE role
   AKSSRE_ID=$(az ad user create \
     --display-name "AKS SRE" \
     --user-principal-name $AAD_SRE_UPN \
     --password $AAD_SRE_PW \
     --query id -o tsv)
   
   # Add the user to the opssre Entra ID group
   az ad group member add --group opssre --member-id $AKSSRE_ID
   

Uygulama geliştirmeleri için AKS kümesi kaynakları oluşturma

Microsoft Entra gruplarımız, kullanıcılarımız ve Azure rol atamalarımız oluşturuldu. Şimdi AKS kümesini bu farklı grupların belirli kaynaklara erişmesine izin verecek şekilde yapılandıracaksınız.

1. komutunu kullanarak az aks get-credentials küme yöneticisi kimlik bilgilerini alın. Aşağıdaki bölümlerden birinde, Microsoft Entra kimlik doğrulama akışının çalıştığını görmek için normal kullanıcı kümesi kimlik bilgilerini alırsınız.

   az aks get-credentials --resource-group myResourceGroup --name myAKSCluster --admin
   

2. komutunu kullanarak kubectl create namespace AKS kümesinde bir ad alanı oluşturun. Aşağıdaki örnek, bir ad alanı adı dev oluşturur:

   kubectl create namespace dev
   

   Not

   Kubernetes'te Roller, verilmesi gereken izinleri tanımlar ve RoleBinding'ler bunları istenen kullanıcılara veya gruplara uygular. Bu atamalar belirli bir ad alanına veya kümenin tamamına uygulanabilir. Daha fazla bilgi için bkz . Kubernetes RBAC yetkilendirmesini kullanma.

   Kubernetes RBAC bağlamasını sağladığınız kullanıcı aynı Microsoft Entra kiracısındaysa, userPrincipalName (UPN) temelinde izinler atayın. Kullanıcı farklı bir Microsoft Entra kiracısındaysa, bunun yerine objectId özelliğini sorgulayıp kullanın.

3. Geliştirme ad alanı için ad alanına tam izinler veren bir Rol oluşturun. Üretim ortamlarında, farklı kullanıcılar veya gruplar için daha ayrıntılı izinler belirtebilirsiniz. adlı role-dev-namespace.yaml bir dosya oluşturun ve aşağıdaki YAML bildirimini yapıştırın:

   kind: Role
   apiVersion: rbac.authorization.k8s.io/v1
   metadata:
     name: dev-user-full-access
     namespace: dev
   rules:
   - apiGroups: ["", "extensions", "apps"]
     resources: ["*"]
     verbs: ["*"]
   - apiGroups: ["batch"]
     resources:
     - jobs
     - cronjobs
     verbs: ["*"]
   

4. komutunu kullanarak kubectl apply Rolü oluşturun ve YAML bildiriminizin dosya adını belirtin.

   kubectl apply -f role-dev-namespace.yaml
   

5. komutunu kullanarak appdevaz ad group showalın. Bu grup, bir sonraki adımda RoleBinding'in konusu olarak ayarlanır.

   az ad group show --group appdev --query id -o tsv
   

6. Ad alanı erişimi için önceden oluşturulmuş Rolü kullanmak üzere appdev grubu için bir RoleBinding oluşturun. adlı rolebinding-dev-namespace.yaml bir dosya oluşturun ve aşağıdaki YAML bildirimini yapıştırın. Son satırda groupObjectId değerini önceki komutun grup nesnesi kimliği çıkışıyla değiştirin.

   kind: RoleBinding
   apiVersion: rbac.authorization.k8s.io/v1
   metadata:
     name: dev-user-access
     namespace: dev
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: Role
     name: dev-user-full-access
   subjects:
   - kind: Group
     namespace: dev
     name: groupObjectId
   

   İpucu

   Tek bir kullanıcı için RoleBinding oluşturmak istiyorsanız, kind: User değerini belirtin ve groupObjectId değerini önceki örnekteki kullanıcı asıl adıyla (UPN) değiştirin.

7. komutunu kullanarak RoleBinding'i kubectl apply oluşturun ve YAML bildiriminizin dosya adını belirtin:

   kubectl apply -f rolebinding-dev-namespace.yaml
   

SRE'ler için AKS küme kaynaklarını oluşturma

Şimdi, ÖNCEKI adımları tekrarlayarak SRE'ler için bir ad alanı, Rol ve RoleBinding oluşturun.

1. komutunu kullanarak srekubectl create namespacebir ad alanı oluşturun.

   kubectl create namespace sre
   

2. adlı role-sre-namespace.yaml bir dosya oluşturun ve aşağıdaki YAML bildirimini yapıştırın:

   kind: Role
   apiVersion: rbac.authorization.k8s.io/v1
   metadata:
     name: sre-user-full-access
     namespace: sre
   rules:
   - apiGroups: ["", "extensions", "apps"]
     resources: ["*"]
     verbs: ["*"]
   - apiGroups: ["batch"]
     resources:
     - jobs
     - cronjobs
     verbs: ["*"]
   

3. komutunu kullanarak kubectl apply Rolü oluşturun ve YAML bildiriminizin dosya adını belirtin.

   kubectl apply -f role-sre-namespace.yaml
   

4. az ad group show komutunu kullanarak opssre grubunun kaynak kimliğini alın.

   az ad group show --group opssre --query id -o tsv
   

5. Ad alanı erişimi için daha önce oluşturulmuş Rolü kullanmak üzere opssre grubu için bir RoleBinding oluşturun. adlı rolebinding-sre-namespace.yaml bir dosya oluşturun ve aşağıdaki YAML bildirimini yapıştırın. Son satırda groupObjectId değerini önceki komutun grup nesnesi kimliği çıkışıyla değiştirin.

   kind: RoleBinding
   apiVersion: rbac.authorization.k8s.io/v1
   metadata:
     name: sre-user-access
     namespace: sre
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: Role
     name: sre-user-full-access
   subjects:
   - kind: Group
     namespace: sre
     name: groupObjectId
   

6. komutunu kullanarak RoleBinding'i kubectl apply oluşturun ve YAML bildiriminizin dosya adını belirtin.

   kubectl apply -f rolebinding-sre-namespace.yaml
   

Microsoft Entra kimliklerini kullanarak küme kaynaklarıyla etkileşim kurma

Şimdi AKS kümesinde kaynak oluşturup yönetirken beklenen izinlerin çalışıp çalışmadığını test edin. Bu örneklerde, kullanıcının atanan ad alanında podları zamanlayıp görüntüler ve atanan ad alanının dışındaki podları zamanlayıp görüntülemeyi denersiniz.

1. komutunu kullanarak kubeconfig bağlamını sıfırlayınaz aks get-credentials. Önceki bir bölümde küme yöneticisi kimlik bilgilerini kullanarak bağlamı ayarlamıştınız. Yönetici kullanıcı Microsoft Entra oturum açma istemlerini atlar. --admin parametresi olmadan, tüm isteklerin Microsoft Entra Kimliği kullanılarak kimliğinin doğrulanması gereken kullanıcı bağlamı uygulanır.

   az aks get-credentials --resource-group myResourceGroup --name myAKSCluster --overwrite-existing
   

2. Geliştirme ad alanında komutunu kullanarak kubectl run temel bir NGINX pod zamanlayın.

   kubectl run nginx-dev --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace dev
   

3. Makalenin başında oluşturulan kendi appdev@contoso.com hesabınızın kimlik bilgilerini oturum açma istemi olarak girin. Başarıyla oturum açtıktan sonra hesap belirteci gelecekteki kubectl komutlar için önbelleğe alınır. Aşağıdaki örnek çıktıda gösterildiği gibi NGINX başarıyla zamanlanır:

   $ kubectl run nginx-dev --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace dev
   
   To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code B24ZD6FP8 to authenticate.
   
   pod/nginx-dev created
   

4. kubectl get pods Geliştirme ad alanında podları görüntülemek için komutunu kullanın.

   kubectl get pods --namespace dev
   

5. NGINX podunun durumunun Çalışıyor olduğundan emin olun. Çıktı, aşağıdaki gibi görünmektedir:

   $ kubectl get pods --namespace dev
   
   NAME        READY   STATUS    RESTARTS   AGE
   nginx-dev   1/1     Running   0          4m
   

Atanan ad alanının dışında küme kaynakları oluşturma ve görüntüleme

Geliştirme ad alanının dışındaki podları görüntülemeyi deneyin. kubectl get pods komutunu bu kez görmek --all-namespacesiçin komutunu yeniden kullanın.

kubectl get pods --all-namespaces

Kullanıcının grup üyeliği, aşağıdaki örnek çıktıda gösterildiği gibi bu eyleme izin veren bir Kubernetes Rolüne sahip değildir:

Error from server (Forbidden): pods is forbidden: User "aksdev@contoso.com" cannot list resource "pods" in API group "" at the cluster scope

Aynı şekilde, sre ad alanı gibi farklı bir ad alanında pod zamanlamayı deneyin. Kullanıcının grup üyeliği, aşağıdaki örnek çıktıda gösterildiği gibi bu izinleri vermek için Kubernetes Rolü ve RoleBinding ile uyumlu değildir:

$ kubectl run nginx-dev --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace sre

Error from server (Forbidden): pods is forbidden: User "aksdev@contoso.com" cannot create resource "pods" in API group "" in the namespace "sre"

AKS kümesi kaynaklarına SRE erişimini test etme

Microsoft Entra grup üyeliğimizin ve Kubernetes RBAC'nin farklı kullanıcılar ve gruplar arasında düzgün çalıştığını onaylamak için opssre kullanıcısı olarak oturum açtığınızda önceki komutları deneyin.

1. aksdevaz aks get-credentials bağlamını sıfırlayın.

   az aks get-credentials --resource-group myResourceGroup --name myAKSCluster --overwrite-existing
   

2. Atanan sre ad alanında podları zamanlamayı ve görüntülemeyi deneyin. İstendiğinde, makalenin başında oluşturulan kendi opssre@contoso.com kimlik bilgilerinizle oturum açın.

   kubectl run nginx-sre --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace sre
   kubectl get pods --namespace sre
   

   Aşağıdaki örnek çıktıda gösterildiği gibi podları başarıyla oluşturabilir ve görüntüleyebilirsiniz:

   $ kubectl run nginx-sre --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace sre
   

3. Oturum açmak için bir web tarayıcısı kullanarak sayfayı https://microsoft.com/devicelogin açın ve kimlik doğrulaması için BM4RHP3FD kodu girin.

   pod/nginx-sre created
   
   $ kubectl get pods --namespace sre
   
   NAME        READY   STATUS    RESTARTS   AGE
   nginx-sre   1/1     Running   0
   

4. Atanan SRE ad alanının dışındaki podları görüntülemeyi veya zamanlamayı deneyin.

   kubectl get pods --all-namespaces
   kubectl run nginx-sre --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace dev
   

   Aşağıdaki kubectl örnek çıktıda gösterildiği gibi bu komutlar başarısız olur. Kullanıcının grup üyeliği ve Kubernetes Rolü ve RoleBindings, diğer ad alanlarına kaynak oluşturma veya kaynak yöneticisi izni vermez.

   $ kubectl get pods --all-namespaces
   Error from server (Forbidden): pods is forbidden: User "akssre@contoso.com" cannot list pods at the cluster scope
   
   $ kubectl run nginx-sre --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace dev
   Error from server (Forbidden): pods is forbidden: User "akssre@contoso.com" cannot create pods in the namespace "dev"
   

Kaynakları temizleme

Bu makalede AKS kümesinde kaynaklar ve Microsoft Entra Id'de kullanıcılar ve gruplar oluşturdunuz. Tüm kaynakları temizlemek için aşağıdaki komutları çalıştırın:

# Get the admin kubeconfig context to delete the necessary cluster resources.

az aks get-credentials --resource-group myResourceGroup --name myAKSCluster --admin

# Delete the dev and sre namespaces. This also deletes the pods, Roles, and RoleBindings.

kubectl delete namespace dev
kubectl delete namespace sre

# Delete the Azure AD user accounts for aksdev and akssre.

az ad user delete --upn-or-object-id $AKSDEV_ID
az ad user delete --upn-or-object-id $AKSSRE_ID

# Delete the Azure AD groups for appdev and opssre. This also deletes the Azure role assignments.

az ad group delete --group appdev
az ad group delete --group opssre

Sonraki adımlar

• Kubernetes kümelerinin güvenliğini sağlama hakkında daha fazla bilgi için bkz . AKS için erişim ve kimlik seçenekleri.
• Kimlik ve kaynak denetimiyle ilgili en iyi yöntemler için bkz . AKS'de kimlik doğrulaması ve yetkilendirme için en iyi yöntemler.