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. Kümenizi 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üklemeniz veya yükseltmeniz gerekirse, bkz. Azure CLI 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ını kullanarak doğrulamak için:

  • Tarayıcınızdan Azure portalında oturum açın.
  • Kubernetes hizmetlerine gidin ve sol bölmeden Küme yapılandırması'nı seçin.
  • 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.

Example of AKS Authentication and Authorization page in Azure portal.

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şturacağı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
    

Bahşiş

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 .

  1. 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)
    
  2. 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şturacağız. Makalenin sonunda Kubernetes RBAC tümleştirmesini test etmek için aks kümesinde bu hesaplarla oturum açacaksı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.

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)
  1. 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
  1. 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
  1. 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
  1. İ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 Azure AD 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ıracağı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
  1. 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

Dekont

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.

  1. 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: ["*"]
  1. komutunu kullanarak kubectl apply Rolü oluşturun ve YAML bildiriminizin dosya adını belirtin.
kubectl apply -f role-dev-namespace.yaml
  1. komutunu kullanarak az ad group show appdev grubunun kaynak kimliğini alın. Bu grup, bir sonraki adımda RoleBinding'in konusu olarak ayarlanır.
az ad group show --group appdev --query id -o tsv
  1. 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

Bahşiş

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

  1. 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ı, Role ve RoleBinding oluşturacağız.

  1. komutunu kullanarak kubectl create namespace sre için bir ad alanı oluşturun.
kubectl create namespace sre
  1. 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: ["*"]
  1. komutunu kullanarak kubectl apply Rolü oluşturun ve YAML bildiriminizin dosya adını belirtin.
kubectl apply -f role-sre-namespace.yaml
  1. az ad group show komutunu kullanarak opssre grubunun kaynak kimliğini alın.
az ad group show --group opssre --query id -o tsv
  1. 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
  1. 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 edeceğiz. Bu örneklerde, kullanıcının atanan ad alanında podları zamanlayıp görüntüleyip, atanan ad alanının dışındaki podları zamanlayıp görüntülemeyi deneyeceğiz.

  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
  1. 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
  1. 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
  1. kubectl get pods Geliştirme ad alanında podları görüntülemek için komutunu kullanın.
kubectl get pods --namespace dev
  1. NGINX podunun durumunun Çalışıyor olduğundan emin olun. Çıkış aşağıdaki çıkışa benzer olacaktır:
$ 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. aksdev kullanıcısı için önceden önbelleğe alınmış kimlik doğrulama belirtecini temizleyen komutunu kullanarak az aks get-credentials kubeconfig bağlamını sıfırlayın.
az aks get-credentials --resource-group myResourceGroup --name myAKSCluster --overwrite-existing
  1. 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. To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code BM4RHP3FD to authenticate.

pod/nginx-sre created

$ kubectl get pods --namespace sre

NAME        READY   STATUS    RESTARTS   AGE
nginx-sre   1/1     Running   0
  1. 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.