Udostępnij za pośrednictwem

Używanie tożsamości zarządzanej w usłudze Azure Kubernetes Service (AKS)

  • Artykuł

Klastry usługi Azure Kubernetes Service (AKS) wymagają tożsamości firmy Microsoft Entra w celu uzyskania dostępu do zasobów platformy Azure, takich jak moduły równoważenia obciążenia i dyski zarządzane. Tożsamości zarządzane dla zasobów platformy Azure to zalecany sposób autoryzowania dostępu z klastra usługi AKS do innych usług platformy Azure.

Tożsamość zarządzana umożliwia autoryzowanie dostępu z klastra usługi AKS do dowolnej usługi obsługującej autoryzację firmy Microsoft Entra bez konieczności zarządzania poświadczeniami lub uwzględnienia ich w kodzie. Przypisujesz do tożsamości zarządzanej rolę kontroli dostępu na podstawie ról (RBAC) platformy Azure, aby przyznać jej uprawnienia do określonego zasobu na platformie Azure. Na przykład można udzielić uprawnień tożsamości zarządzanej w celu uzyskania dostępu do wpisów tajnych w magazynie kluczy platformy Azure do użycia przez klaster. Aby uzyskać więcej informacji na temat kontroli dostępu na podstawie ról platformy Azure, zobacz Co to jest kontrola dostępu oparta na rolach platformy Azure (Azure RBAC)?.

W tym artykule pokazano, jak włączyć następujące typy tożsamości zarządzanej w nowym lub istniejącym klastrze usługi AKS:

  • Tożsamość zarządzana przypisana przez system. Tożsamość zarządzana przypisana przez system jest skojarzona z pojedynczym zasobem platformy Azure, takim jak klaster usługi AKS. Istnieje tylko w cyklu życia klastra.
  • Tożsamość zarządzana przypisana przez użytkownika. Tożsamość zarządzana przypisana przez użytkownika to autonomiczny zasób platformy Azure, za pomocą którego klaster usługi AKS może autoryzować dostęp do innych usług platformy Azure. Jest on utrwalany oddzielnie od klastra usługi AKS i może być używany przez wiele zasobów platformy Azure.
  • Wstępnie utworzona tożsamość zarządzana kubelet. Wstępnie utworzona tożsamość zarządzana kubelet to opcjonalna tożsamość przypisana przez użytkownika, której usługa kubelet może używać do uzyskiwania dostępu do innych zasobów na platformie Azure. Jeśli nie określisz tożsamości zarządzanej przypisanej przez użytkownika dla rozwiązania kubelet, usługa AKS utworzy tożsamość kubelet przypisaną przez użytkownika w grupie zasobów węzła.

Aby dowiedzieć się więcej o tożsamościach zarządzanych, zobacz Tożsamości zarządzane dla zasobów platformy Azure.

Omówienie

Klaster usługi AKS używa tożsamości zarządzanej do żądania tokenów z firmy Microsoft Entra. Te tokeny są używane do autoryzowania dostępu do innych zasobów działających na platformie Azure. Rolę RBAC platformy Azure można przypisać do tożsamości zarządzanej, aby przyznać klastrowi uprawnienia dostępu do określonych zasobów. Jeśli na przykład klaster musi uzyskać dostęp do wpisów tajnych w magazynie kluczy platformy Azure, możesz przypisać do tożsamości zarządzanej klastra rolę RBAC platformy Azure, która przyznaje te uprawnienia.

Tożsamość zarządzana może być przypisana przez system lub przypisana przez użytkownika. Te dwa typy tożsamości zarządzanych są podobne, dlatego można użyć dowolnego typu, aby autoryzować dostęp do zasobów platformy Azure z klastra usługi AKS. Kluczową różnicą między nimi jest to, że tożsamość zarządzana przypisana przez system jest skojarzona z pojedynczym zasobem platformy Azure, takim jak klaster usługi AKS, podczas gdy tożsamość zarządzana przypisana przez użytkownika jest samym autonomicznym zasobem platformy Azure. Aby uzyskać więcej informacji na temat różnic między typami tożsamości zarządzanych, zobacz Typy tożsamości zarządzanych w temacie Tożsamości zarządzane dla zasobów platformy Azure.

Oba typy tożsamości zarządzanych są zarządzane przez platformę Azure, dzięki czemu można autoryzować dostęp z aplikacji bez konieczności aprowizowania ani rotacji wpisów tajnych. Platforma Azure zarządza poświadczeniami tożsamości.

Podczas wdrażania klastra usługi AKS tożsamość zarządzana przypisana przez system jest tworzona domyślnie. Klaster można również utworzyć przy użyciu tożsamości zarządzanej przypisanej przez użytkownika.

Istnieje również możliwość utworzenia klastra z jednostką usługi aplikacji, a nie tożsamością zarządzaną. Tożsamości zarządzane są zalecane w przypadku jednostek usługi w celu zapewnienia bezpieczeństwa i łatwości użycia. Aby uzyskać więcej informacji na temat tworzenia klastra za pomocą jednostki usługi, zobacz Używanie jednostki usługi z usługą Azure Kubernetes Service (AKS).

Istniejący klaster można zaktualizować tak, aby używał tożsamości zarządzanej z jednostki usługi aplikacji. Możesz również zaktualizować istniejący klaster do innego typu tożsamości zarządzanej. Jeśli klaster korzysta już z tożsamości zarządzanej i tożsamość została zmieniona, na przykład jeśli zaktualizowano typ tożsamości klastra z przypisanego przez system do przypisanego przez użytkownika, oznacza to opóźnienie, gdy składniki płaszczyzny sterowania przełączą się do nowej tożsamości. Składniki płaszczyzny sterowania nadal używają starej tożsamości do momentu wygaśnięcia tokenu. Po odświeżeniu tokenu przełączają się na nową tożsamość. Ten proces może potrwać kilka godzin.

Typy tożsamości przypisane przez system i przypisane przez użytkownika różnią się od tożsamości obciążenia entra firmy Microsoft, która jest przeznaczona do użycia przez aplikację działającą na zasobniku.

Zanim rozpoczniesz

  • Upewnij się, że masz zainstalowany interfejs wiersza polecenia platformy Azure w wersji 2.23.0 lub nowszej. Uruchom polecenie az --version, aby dowiedzieć się, jaka wersja jest używana. Jeśli konieczna będzie instalacja lub uaktualnienie, zobacz Instalowanie interfejsu wiersza polecenia platformy Azure.

  • Aby użyć wstępnie utworzonej tożsamości zarządzanej kubelet, musisz zainstalować interfejs wiersza polecenia platformy Azure w wersji 2.26.0 lub nowszej.

  • Aby zaktualizować istniejący klaster do używania tożsamości zarządzanej przypisanej przez system lub tożsamości zarządzanej przypisanej przez użytkownika, musisz zainstalować interfejs wiersza polecenia platformy Azure w wersji 2.49.0 lub nowszej.

Przed uruchomieniem przykładów w tym artykule ustaw subskrypcję jako bieżącą aktywną subskrypcję, wywołując polecenie az account set i przekazując identyfikator subskrypcji.

az account set --subscription <subscription-id>

Utwórz również grupę zasobów platformy Azure, jeśli jeszcze jej nie masz, wywołując az group create polecenie .

az group create \
    --name myResourceGroup \
    --location westus2

Włączanie tożsamości zarządzanej przypisanej przez system

Tożsamość zarządzana przypisana przez system to tożsamość skojarzona z klastrem usługi AKS lub innym zasobem platformy Azure. Tożsamość zarządzana przypisana przez system jest powiązana z cyklem życia klastra. Po usunięciu klastra tożsamość zarządzana przypisana przez system zostanie również usunięta.

Klaster usługi AKS może używać przypisanej przez system tożsamości zarządzanej do autoryzowania dostępu do innych zasobów uruchomionych na platformie Azure. Rolę RBAC platformy Azure można przypisać do tożsamości zarządzanej przypisanej przez system, aby przyznać klastrowi uprawnienia dostępu do określonych zasobów. Jeśli na przykład klaster musi uzyskać dostęp do wpisów tajnych w usłudze Azure Key Vault, możesz przypisać do tożsamości zarządzanej przypisanej przez system rolę RBAC platformy Azure, która przyznaje te uprawnienia.

Włączanie tożsamości zarządzanej przypisanej przez system w nowym klastrze usługi AKS

Aby włączyć tożsamość zarządzaną przypisaną przez system w nowym klastrze, wywołaj metodę az aks create. Tożsamość zarządzana przypisana przez system jest domyślnie włączona w nowym klastrze.

Utwórz klaster usługi AKS przy użyciu az aks create polecenia .

az aks create \
    --resource-group myResourceGroup \
    --name myManagedCluster \
    --generate-ssh-keys

Aby sprawdzić, czy tożsamość zarządzana przypisana przez system jest włączona dla klastra po jego utworzeniu, zobacz Określanie typu tożsamości zarządzanej używanej przez klaster.

Aktualizowanie istniejącego klastra usługi AKS w celu używania tożsamości zarządzanej przypisanej przez system

Aby zaktualizować istniejący klaster usługi AKS używający jednostki usługi do używania tożsamości zarządzanej przypisanej przez system, uruchom az aks update polecenie z parametrem --enable-managed-identity .

az aks update \
    --resource-group myResourceGroup \
    --name myManagedCluster \
    --enable-managed-identity

Po zaktualizowaniu klastra do używania tożsamości zarządzanej przypisanej przez system zamiast jednostki usługi płaszczyzna sterowania i zasobniki używają przypisanej przez system tożsamości zarządzanej do autoryzacji podczas uzyskiwania dostępu do innych usług na platformie Azure. Rozwiązanie Kubelet kontynuuje korzystanie z jednostki usługi, dopóki nie uaktualnisz puli agentów. Aby zaktualizować tożsamość zarządzaną, możesz użyć az aks nodepool upgrade --resource-group myResourceGroup --cluster-name myAKSCluster --name mynodepool --node-image-only polecenia w węzłach. Uaktualnienie puli węzłów powoduje przestój klastra usługi AKS, ponieważ węzły w pulach węzłów są kordonowane, opróżniane i ponownie obrazowane.

Uwaga

Podczas aktualizowania klastra należy pamiętać o następujących informacjach:

  • Aktualizacja działa tylko wtedy, gdy istnieje aktualizacja dysku VHD do korzystania. Jeśli używasz najnowszego wirtualnego dysku twardego, musisz poczekać, aż następny wirtualny dysk twardy będzie dostępny w celu przeprowadzenia aktualizacji.

  • Interfejs wiersza polecenia platformy Azure zapewnia, że uprawnienie dodatku jest poprawnie ustawione po przeprowadzeniu migracji. Jeśli nie używasz interfejsu wiersza polecenia platformy Azure do przeprowadzenia operacji migracji, musisz samodzielnie obsłużyć uprawnienia tożsamości dodatku. Aby zapoznać się z przykładem użycia szablonu usługi Azure Resource Manager (ARM), zobacz Przypisywanie ról platformy Azure przy użyciu szablonów usługi ARM.

  • Jeśli klaster był używany --attach-acr do ściągania obrazów z usługi Azure Container Registry (ACR), należy uruchomić az aks update --resource-group myResourceGroup --name myAKSCluster --attach-acr <ACR resource ID> polecenie po zaktualizowaniu klastra, aby umożliwić nowo utworzonemu kubeletowi używanemu na potrzeby tożsamości zarządzanej uzyskanie uprawnień do ściągania z usługi ACR. W przeciwnym razie nie będzie można ściągnąć z usługi ACR po aktualizacji.

Dodawanie przypisania roli dla tożsamości zarządzanej przypisanej przez system

Rolę RBAC platformy Azure można przypisać do tożsamości zarządzanej przypisanej przez system w celu udzielenia uprawnień klastra w innym zasobie platformy Azure. Kontrola dostępu oparta na rolach platformy Azure obsługuje zarówno wbudowane, jak i niestandardowe definicje ról, które określają poziomy uprawnień. Aby uzyskać więcej informacji na temat przypisywania ról RBAC platformy Azure, zobacz Kroki przypisywania roli platformy Azure.

Po przypisaniu roli RBAC platformy Azure do tożsamości zarządzanej należy zdefiniować zakres roli. Ogólnie rzecz biorąc, najlepszym rozwiązaniem jest ograniczenie zakresu roli do minimalnych uprawnień wymaganych przez tożsamość zarządzaną. Aby uzyskać więcej informacji na temat określania zakresu ról RBAC platformy Azure, zobacz Omówienie zakresu kontroli dostępu opartej na rolach platformy Azure.

Podczas tworzenia i używania własnej sieci wirtualnej dołączonych dysków platformy Azure, statycznego adresu IP, tabeli tras lub tożsamości kubelet przypisanej przez użytkownika, w której zasoby znajdują się poza grupą zasobów węzła roboczego, interfejs wiersza polecenia platformy Azure automatycznie dodaje przypisanie roli. Jeśli używasz szablonu usługi ARM lub innej metody, użyj identyfikatora podmiotu zabezpieczeń tożsamości zarządzanej, aby wykonać przypisanie roli.

Jeśli nie używasz interfejsu wiersza polecenia platformy Azure, ale używasz własnej sieci wirtualnej, dołączonych dysków platformy Azure, statycznego adresu IP, tabeli tras lub tożsamości kubelet przypisanej przez użytkownika spoza grupy zasobów węzła roboczego, zalecamy użycie tożsamości zarządzanej przypisanej przez użytkownika dla płaszczyzny sterowania. Gdy płaszczyzna sterowania używa tożsamości zarządzanej przypisanej przez system, tożsamość jest tworzona w tym samym czasie co klaster, więc nie można wykonać przypisania roli do momentu utworzenia klastra.

Pobieranie identyfikatora podmiotu zabezpieczeń tożsamości zarządzanej przypisanej przez system

Aby przypisać rolę RBAC platformy Azure do przypisanej przez system tożsamości zarządzanej klastra, musisz najpierw uzyskać identyfikator podmiotu zabezpieczeń dla tożsamości zarządzanej. Pobierz identyfikator podmiotu zabezpieczeń tożsamości zarządzanej przypisanej przez system klastra, wywołując az aks show polecenie .

# Get the principal ID for a system-assigned managed identity.
CLIENT_ID=$(az aks show \
    --name myAKSCluster \
    --resource-group myResourceGroup \
    --query identity.principalId \
    --output tsv)

Przypisywanie roli RBAC platformy Azure do przypisanej przez system tożsamości zarządzanej

Aby przyznać przypisane przez system uprawnienia tożsamości zarządzanej do zasobu na platformie Azure, wywołaj az role assignment create polecenie , aby przypisać rolę RBAC platformy Azure do tożsamości zarządzanej.

W przypadku sieci wirtualnej, dołączonego dysku platformy Azure, statycznego adresu IP lub tabeli tras poza domyślną grupą zasobów węzła procesu roboczego należy przypisać Network Contributor rolę w niestandardowej grupie zasobów.

Na przykład przypisz Network Contributor rolę w niestandardowej grupie zasobów przy użyciu az role assignment create polecenia . Dla parametru --scope podaj identyfikator zasobu dla grupy zasobów klastra.

az role assignment create \
    --assignee $CLIENT_ID \
    --role "Network Contributor" \
    --scope "<resource-group-id>"

Uwaga

Propagacja uprawnień udzielonych tożsamości zarządzanej klastra może potrwać do 60 minut.

Włączanie tożsamości zarządzanej przypisanej przez użytkownika

Tożsamość zarządzana przypisana przez użytkownika jest autonomicznym zasobem platformy Azure. Podczas tworzenia klastra z tożsamością zarządzaną przypisaną przez użytkownika dla płaszczyzny sterowania przed utworzeniem klastra musi istnieć zasób tożsamości zarządzanej przypisanej przez użytkownika. Ta funkcja umożliwia scenariusze, takie jak tworzenie klastra z niestandardową siecią wirtualną lub typ ruchu wychodzącego routingu zdefiniowanego przez użytkownika (UDR).

Tworzenie tożsamości zarządzanej przypisanej przez użytkownika

Jeśli nie masz jeszcze zasobu tożsamości zarządzanej przypisanej przez użytkownika, utwórz go przy użyciu az identity create polecenia .

az identity create \
    --name myIdentity \
    --resource-group myResourceGroup

Dane wyjściowe powinny przypominać następujące przykładowe dane wyjściowe:

{                                  
  "clientId": "<client-id>",
  "clientSecretUrl": "<clientSecretUrl>",
  "id": "/subscriptions/<subscriptionid>/resourcegroups/myResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myIdentity", 
  "location": "westus2",
  "name": "myIdentity",
  "principalId": "<principal-id>",
  "resourceGroup": "myResourceGroup",                       
  "tags": {},
  "tenantId": "<tenant-id>",
  "type": "Microsoft.ManagedIdentity/userAssignedIdentities"
}

Pobieranie identyfikatora podmiotu zabezpieczeń tożsamości zarządzanej przypisanej przez użytkownika

Aby uzyskać identyfikator podmiotu zabezpieczeń tożsamości zarządzanej przypisanej przez użytkownika, wywołaj metodę az identity show i wykonaj zapytanie dotyczące principalId właściwości:

CLIENT_ID=$(az identity show \
    --name myIdentity \
    --resource-group myResourceGroup \
    --query principalId \
    --output tsv)

Pobieranie identyfikatora zasobu tożsamości zarządzanej przypisanej przez użytkownika

Aby utworzyć klaster z tożsamością zarządzaną przypisaną przez użytkownika, potrzebny będzie identyfikator zasobu dla nowej tożsamości zarządzanej. Aby uzyskać identyfikator zasobu tożsamości zarządzanej przypisanej przez użytkownika, wywołaj polecenie az aks show i wykonaj zapytanie dotyczące id właściwości:

RESOURCE_ID=$(az identity show \
    --name myIdentity \
    --resource-group myResourceGroup \
    --query id \
    --output tsv)

Przypisywanie roli RBAC platformy Azure do tożsamości zarządzanej przypisanej przez użytkownika

Przed utworzeniem klastra dodaj przypisanie roli dla tożsamości zarządzanej, wywołując az role assignment create polecenie .

W poniższym przykładzie rola Użytkownika wpisów tajnych usługi Key Vault jest przypisywana do tożsamości zarządzanej przypisanej przez użytkownika w celu udzielenia mu uprawnień dostępu do wpisów tajnych w magazynie kluczy. Przypisanie roli jest ograniczone do zasobu magazynu kluczy:

az role assignment create \
    --assignee $CLIENT_ID \
    --role "Key Vault Secrets User" \
    --scope "<keyvault-resource-id>"

Uwaga

Propagacja uprawnień udzielonych tożsamości zarządzanej klastra może potrwać do 60 minut.

Tworzenie klastra z tożsamością zarządzaną przypisaną przez użytkownika

Aby utworzyć klaster usługi AKS z tożsamością zarządzaną przypisaną przez użytkownika, wywołaj az aks create polecenie . Uwzględnij --assign-identity parametr i przekaż identyfikator zasobu dla tożsamości zarządzanej przypisanej przez użytkownika:

az aks create \
    --resource-group myResourceGroup \
    --name myManagedCluster \
    --network-plugin azure \
    --vnet-subnet-id <subnet-id> \
    --dns-service-ip 10.2.0.10 \
    --service-cidr 10.2.0.0/24 \
    --assign-identity $RESOURCE_ID \
    --generate-ssh-keys

Uwaga

Regiony USDOD Central, USDOD East i USGov Iowa w chmurze Azure US Government nie obsługują tworzenia klastra z tożsamością zarządzaną przypisaną przez użytkownika.

Aktualizowanie istniejącego klastra w celu używania tożsamości zarządzanej przypisanej przez użytkownika

Aby zaktualizować istniejący klaster do używania tożsamości zarządzanej przypisanej przez użytkownika, wywołaj az aks update polecenie . Uwzględnij --assign-identity parametr i przekaż identyfikator zasobu dla tożsamości zarządzanej przypisanej przez użytkownika:

az aks update \
    --resource-group myResourceGroup \
    --name myManagedCluster \
    --enable-managed-identity \
    --assign-identity $RESOURCE_ID

Dane wyjściowe pomyślnej aktualizacji klastra do korzystania z tożsamości zarządzanej przypisanej przez użytkownika powinny przypominać następujące przykładowe dane wyjściowe:

  "identity": {
    "principalId": null,
    "tenantId": null,
    "type": "UserAssigned",
    "userAssignedIdentities": {
      "/subscriptions/<subscriptionid>/resourcegroups/resourcegroups/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myIdentity": {
        "clientId": "<client-id>",
        "principalId": "<principal-id>"
      }
    }
  },

Uwaga

Migrowanie tożsamości zarządzanej dla płaszczyzny sterowania z przypisanej przez system do przypisanej przez użytkownika nie powoduje przestoju dla płaszczyzny sterowania i pul agentów. Składniki płaszczyzny sterowania nadal mają starą tożsamość przypisaną przez system przez maksymalnie kilka godzin, aż do następnego odświeżenia tokenu.

Określanie typu tożsamości zarządzanej używanej przez klaster

Aby określić, jakiego typu tożsamości zarządzanej używa istniejący klaster usługi AKS, wywołaj polecenie az aks show i wykonaj zapytanie dotyczące właściwości typu tożsamości.

az aks show \
    --name myAKSCluster \
    --resource-group myResourceGroup \
    --query identity.type \
    --output tsv

Jeśli klaster korzysta z tożsamości zarządzanej, wartość właściwości typu będzie mieć wartość SystemAssigned lub UserAssigned.

Jeśli klaster używa jednostki usługi, wartość właściwości typu będzie mieć wartość null. Rozważ uaktualnienie klastra w celu użycia tożsamości zarządzanej.

Używanie wstępnie utworzonej tożsamości zarządzanej kubelet

Wstępnie utworzona tożsamość kubelet to tożsamość zarządzana przypisana przez użytkownika, która istnieje przed utworzeniem klastra. Ta funkcja umożliwia scenariusze, takie jak połączenie z usługą Azure Container Registry (ACR) podczas tworzenia klastra.

Uwaga

Usługa AKS tworzy tożsamość kubelet przypisaną przez użytkownika w grupie zasobów węzła, jeśli nie określisz własnej tożsamości zarządzanej kubelet.

W przypadku tożsamości kubelet przypisanej przez użytkownika poza domyślną grupą zasobów węzła roboczego należy przypisać rolę Operator tożsamości zarządzanej w tożsamości kubelet dla tożsamości zarządzanej płaszczyzny sterowania.

tożsamość zarządzana kubelet

Jeśli nie masz tożsamości zarządzanej kubelet, utwórz je przy użyciu az identity create polecenia .

az identity create \
    --name myKubeletIdentity \
    --resource-group myResourceGroup

Dane wyjściowe powinny przypominać następujące przykładowe dane wyjściowe:

{
  "clientId": "<client-id>",
  "clientSecretUrl": "<clientSecretUrl>",
  "id": "/subscriptions/<subscriptionid>/resourcegroups/myResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myKubeletIdentity", 
  "location": "westus2",
  "name": "myKubeletIdentity",
  "principalId": "<principal-id>",
  "resourceGroup": "myResourceGroup",                       
  "tags": {},
  "tenantId": "<tenant-id>",
  "type": "Microsoft.ManagedIdentity/userAssignedIdentities"
}

Przypisywanie roli RBAC do tożsamości zarządzanej kubelet

ACRPull Przypisz rolę w tożsamości kubelet przy az role assignment create użyciu polecenia . Podaj identyfikator podmiotu zabezpieczeń tożsamości kubelet dla zmiennej $KUBELET_CLIENT_ID i podaj identyfikator rejestru ACR dla zmiennej $ACR_REGISTRY_ID.

az role assignment create \
    --assignee $KUBELET_CLIENT_ID \
    --role "acrpull" \
    --scope "$ACR_REGISTRY_ID"

Tworzenie klastra do korzystania z tożsamości kubelet

Teraz możesz utworzyć klaster usługi AKS przy użyciu istniejących tożsamości. Upewnij się, że podano identyfikator zasobu tożsamości zarządzanej dla płaszczyzny sterowania, dołączając assign-identity argument i tożsamość zarządzaną kubelet przy użyciu argumentu assign-kubelet-identity .

Utwórz klaster usługi AKS przy użyciu istniejących tożsamości przy użyciu az aks create polecenia .

az aks create \
    --resource-group myResourceGroup \
    --name myManagedCluster \
    --network-plugin azure \
    --vnet-subnet-id <subnet-id> \
    --dns-service-ip 10.2.0.10 \
    --service-cidr 10.2.0.0/24 \
    --assign-identity <identity-resource-id> \
    --assign-kubelet-identity <kubelet-identity-resource-id> \
    --generate-ssh-keys

Pomyślne utworzenie klastra usługi AKS przy użyciu tożsamości zarządzanej kubelet powinno spowodować wyświetlenie danych wyjściowych podobnych do następujących:

  "identity": {
    "principalId": null,
    "tenantId": null,
    "type": "UserAssigned",
    "userAssignedIdentities": {
      "/subscriptions/<subscriptionid>/resourcegroups/resourcegroups/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myIdentity": {
        "clientId": "<client-id>",
        "principalId": "<principal-id>"
      }
    }
  },
  "identityProfile": {
    "kubeletidentity": {
      "clientId": "<client-id>",
      "objectId": "<object-id>",
      "resourceId": "/subscriptions/<subscriptionid>/resourcegroups/resourcegroups/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myKubeletIdentity"
    }
  },

Aktualizowanie istniejącego klastra w celu użycia tożsamości kubelet

Aby zaktualizować istniejący klaster do używania tożsamości zarządzanej kubelet, najpierw uzyskaj bieżącą tożsamość zarządzaną płaszczyzny sterowania dla klastra usługi AKS.

Ostrzeżenie

Aktualizacja tożsamości zarządzanej kubelet uaktualnia pule węzłów klastra usługi AKS, co powoduje przestój klastra, ponieważ węzły w pulach węzłów są cordoned/opróżniane i odtwarzane.

  1. Upewnij się, że klaster usługi AKS używa tożsamości zarządzanej przypisanej przez użytkownika przy użyciu az aks show polecenia .

    az aks show \
    --resource-group <RGName> \
    --name <ClusterName> \
    --query "servicePrincipalProfile"

    Jeśli klaster korzysta z tożsamości zarządzanej, dane wyjściowe będą wyświetlane clientId z wartością msi. Klaster używający jednostki usługi pokazuje identyfikator obiektu. Na przykład:

    # The cluster is using a managed identity.
{
  "clientId": "msi"
}

  2. Po potwierdzeniu, że klaster korzysta z tożsamości zarządzanej, znajdź identyfikator zasobu tożsamości zarządzanej az aks show przy użyciu polecenia .

    az aks show --resource-group <RGName> \
    --name <ClusterName> \
    --query "identity"

    W przypadku tożsamości zarządzanej przypisanej przez użytkownika dane wyjściowe powinny wyglądać podobnie do następujących przykładowych danych wyjściowych:

    {
  "principalId": null,
  "tenantId": null,
  "type": "UserAssigned",
  "userAssignedIdentities": <identity-resource-id>
      "clientId": "<client-id>",
      "principalId": "<principal-id>"
},

  3. Zaktualizuj klaster przy użyciu istniejących tożsamości przy użyciu az aks update polecenia . Podaj identyfikator zasobu tożsamości zarządzanej przypisanej przez użytkownika dla płaszczyzny sterowania dla argumentu assign-identity . Podaj identyfikator zasobu tożsamości zarządzanej kubelet dla argumentu assign-kubelet-identity .

    az aks update \
    --resource-group myResourceGroup \
    --name myManagedCluster \
    --enable-managed-identity \
    --assign-identity <identity-resource-id> \
    --assign-kubelet-identity <kubelet-identity-resource-id>

Dane wyjściowe pomyślnej aktualizacji klastra przy użyciu własnej tożsamości zarządzanej kubelet powinny przypominać następujące przykładowe dane wyjściowe:

  "identity": {
    "principalId": null,
    "tenantId": null,
    "type": "UserAssigned",
    "userAssignedIdentities": {
      "/subscriptions/<subscriptionid>/resourcegroups/resourcegroups/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myIdentity": {
        "clientId": "<client-id>",
        "principalId": "<principal-id>"
      }
    }
  },
  "identityProfile": {
    "kubeletidentity": {
      "clientId": "<client-id>",
      "objectId": "<object-id>",
      "resourceId": "/subscriptions/<subscriptionid>/resourcegroups/resourcegroups/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myKubeletIdentity"
    }
  },

Uwaga

Jeśli klaster był używany --attach-acr do ściągania obrazów z usługi Azure Container Registry, uruchom az aks update --resource-group myResourceGroup --name myAKSCluster --attach-acr <ACR Resource ID> polecenie po zaktualizowaniu klastra, aby umożliwić nowo utworzonemu kubeletowi używanemu na potrzeby tożsamości zarządzanej uzyskanie uprawnień do ściągania z usługi ACR. W przeciwnym razie nie będzie można ściągnąć z usługi ACR po uaktualnieniu.

Pobieranie właściwości tożsamości kubelet

Aby uzyskać właściwości tożsamości kubelet, wywołaj polecenie az aks show i zapytanie dotyczące identityProfile.kubeletidentity właściwości .

az aks show \
    --name myAKSCluster \
    --resource-group myResourceGroup \
    --query "identityProfile.kubeletidentity"

Wstępnie utworzone ograniczenia tożsamości kubelet

Zwróć uwagę na następujące ograniczenia dotyczące wstępnie utworzonej tożsamości kubelet:

  • Wstępnie utworzona tożsamość kubelet musi być tożsamością zarządzaną przypisaną przez użytkownika.
  • Regiony Chiny Wschodnie i Chiny Północne na platformie Microsoft Azure obsługiwane przez firmę 21Vianet nie są obsługiwane.

Podsumowanie tożsamości zarządzanych używanych przez usługę AKS

Usługa AKS używa kilku tożsamości zarządzanych dla wbudowanych usług i dodatków.

Tożsamość Nazwisko Przypadek użycia Uprawnienia domyślne Przynieś własną tożsamość
Płaszczyzna sterowania Nazwa klastra usługi AKS Używane przez składniki płaszczyzny sterowania usługi AKS do zarządzania zasobami klastra, w tym modułami równoważenia obciążenia ruchu przychodzącego i publicznymi adresami IP zarządzanymi przez usługę AKS, modułem skalowania automatycznego klastra, dyskiem platformy Azure, plikiem, sterownikami CSI obiektów blob. Rola współautora dla grupy zasobów node Obsługiwane
Kubelet Pula nazwa-agenta klastra usługi AKS Uwierzytelnianie za pomocą usługi Azure Container Registry (ACR). N/A (dla platformy Kubernetes w wersji 1.15 lub nowszej) Obsługiwane
Dodatek AzureNPM Nie jest wymagana żadna tożsamość. Nie dotyczy Nie.
Dodatek Monitorowanie sieci w usłudze AzureCNI Nie jest wymagana żadna tożsamość. Nie dotyczy Nie.
Dodatek azure-policy (gatekeeper) Nie jest wymagana żadna tożsamość. Nie dotyczy Nie.
Dodatek azure-policy Nie jest wymagana żadna tożsamość. Nie dotyczy Nie.
Dodatek Perkal Nie jest wymagana żadna tożsamość. Nie dotyczy Nie.
Dodatek routing aplikacji Zarządza certyfikatami usług Azure DNS i Azure Key Vault Rola użytkownika wpisów tajnych usługi Key Vault dla usługi Key Vault, rola Współautor strefy DNZ dla stref DNS, rola współautora strefy Prywatna strefa DNS dla prywatnych stref DNS Nie.
Dodatek HTTPApplicationRouting Zarządza wymaganymi zasobami sieciowymi. Rola czytelnika dla grupy zasobów węzła, rola współautora dla strefy DNS Nie.
Dodatek Brama aplikacji ruchu przychodzącego Zarządza wymaganymi zasobami sieciowymi. Rola współautora dla grupy zasobów węzła Nie.
Dodatek omsagent Służy do wysyłania metryk usługi AKS do usługi Azure Monitor. Rola wydawcy metryk monitorowania Nie.
Dodatek Węzeł wirtualny (ACIConnector) Zarządza wymaganymi zasobami sieciowymi dla usługi Azure Container Instances (ACI). Rola współautora dla grupy zasobów węzła Nie.
Dodatek Analiza kosztów Służy do zbierania danych alokacji kosztów
Tożsamość obciążenia Identyfikator obciążenia Firmy Microsoft Entra Umożliwia aplikacjom bezpieczny dostęp do zasobów w chmurze za pomocą identyfikatora obciążenia Entra firmy Microsoft. Nie dotyczy Nie.

Ważne

Tożsamość zarządzana typu open source firmy Microsoft Entra (wersja zapoznawcza) w usłudze Azure Kubernetes Service została uznana za przestarzałą w dniu 24.01.2022 r. i zarchiwizowana projekt we wrześniu 2023 r. Aby uzyskać więcej informacji, zobacz powiadomienie o wycofaniu. Dodatek zarządzany przez usługę AKS rozpoczyna wycofywanie we wrześniu 2024 r.

Zalecamy przejrzenie Tożsamość obciążeń Microsoft Entra. Entra Tożsamość obciążeń uwierzytelnianie zastępuje przestarzałą funkcję tożsamości zarządzanej zasobnika (wersja zapoznawcza). Entra Tożsamość obciążeń to zalecana metoda umożliwiająca aplikacji działającej na zasobniku uwierzytelnianie się względem innych usług platformy Azure, które ją obsługują.

Ograniczenia

  • Przenoszenie lub migrowanie klastra z obsługą tożsamości zarządzanej do innej dzierżawy nie jest obsługiwane.

  • Jeśli klaster ma włączoną tożsamość zarządzaną zasobnika firmy Microsoft (aad-pod-identity), zasobniki tożsamości zarządzanej węzła (NMI) modyfikują tabele ip węzłów, aby przechwycić wywołania punktu końcowego usługi Azure Instance Metadata (IMDS). Ta konfiguracja oznacza, że każde żądanie skierowane do punktu końcowego USŁUGI IMDS jest przechwytywane przez NMI, nawet jeśli określony zasobnik nie używa elementu aad-pod-identity.

    Można skonfigurować niestandardową definicję zasobu azurePodIdentityException (CRD), aby określić, że żądania do punktu końcowego IMDS pochodzące z etykiet pasujących zasobników zdefiniowanych w crD powinny być proxied bez żadnego przetwarzania w NMI. Wyklucz zasobniki systemowe z etykietą kubernetes.azure.com/managedby: aks w przestrzeni nazw kube-system w programie aad-pod-identity , konfigurując element CRD azurePodIdentityException. Aby uzyskać więcej informacji, zobacz Use Microsoft Entra pod-managed identities in Azure Kubernetes Service (Używanie tożsamości zarządzanych przez zasobniki firmy Microsoft w usłudze Azure Kubernetes Service).

    Aby skonfigurować wyjątek, zainstaluj kod YAML wyjątku mikrofonu.

  • Usługa AKS nie obsługuje korzystania z tożsamości zarządzanej przypisanej przez system w przypadku korzystania z niestandardowej prywatnej strefy DNS.

Następne kroki

  • Użyj szablonów usługi Azure Resource Manager, aby utworzyć klaster z obsługą tożsamości zarządzanej.
  • Dowiedz się, jak używać narzędzia kubelogin dla wszystkich obsługiwanych metod uwierzytelniania firmy Microsoft Entra w usłudze AKS.