Omówienie tożsamości zarządzanych w usłudze Azure Kubernetes Service (AKS)

Ten artykuł zawiera omówienie tożsamości zarządzanych przypisanych przez system i przypisanych przez użytkownika w usłudze AKS, w tym sposobu ich działania, przypisań ról i funkcji tożsamości zarządzanej specyficznej dla usługi AKS.

Aby włączyć tożsamość zarządzaną w nowym lub istniejącym klastrze usługi AKS, zobacz Używanie tożsamości zarządzanej w usłudze Azure Kubernetes Service (AKS). Aby uzyskać więcej informacji na temat tożsamości zarządzanych na platformie Azure, zobacz dokumentację Tożsamości zarządzane dla zasobów platformy Azure.

Przepływ autoryzacji tożsamości zarządzanej usługi AKS

Klastry usługi AKS używają tożsamości zarządzanych przypisanych przez system lub użytkowników do żądania tokenów z firmy Microsoft Entra. Te tokeny pomagają autoryzować dostęp do innych zasobów działających na platformie Azure. Do tożsamości zarządzanej przypisujesz rolę kontroli dostępu opartej na rolach (RBAC) platformy Azure, aby przyznać jej uprawnienia do określonego zasobu platformy 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.

Zachowanie tożsamości zarządzanej w Azure Kubernetes Service (AKS)

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

Jeśli klaster już używa tożsamości zarządzanej i zmienia typ tożsamości (na przykład z przypisanego przez system do przypisanego przez użytkownika), występuje opóźnienie, gdy składniki płaszczyzny sterowania przełączają się na nową tożsamość. Składniki płaszczyzny sterowania nadal używają starej tożsamości do momentu wygaśnięcia tokenu. Po odświeżeniu tokenu przełączą się do nowej tożsamości. Ten proces może zająć kilka godzin.

Zarządzanie tożsamościami i poświadczeniami w usłudze AKS

Platforma Azure zarządza zarówno tożsamościami zarządzanymi przypisanymi przez system, jak i przypisanymi przez użytkownika oraz ich poświadczeniami, co pozwala na autoryzację dostępu z aplikacji bez konieczności tworzenia ani rotacji tajemnic.

Zarządzana tożsamość przypisana przez system

Poniższa tabela zawiera podsumowanie kluczowych cech tożsamości zarządzanej przypisanej przez system w usłudze AKS:

Tożsamość zarządzana przypisana użytkownikowi

W poniższej tabeli przedstawiono podsumowanie kluczowych cech tożsamości zarządzanej przypisanej przez użytkownika w usłudze AKS:

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. Ta funkcja umożliwia scenariusze, takie jak połączenie z usługą Azure Container Registry (ACR) podczas tworzenia klastra. Jeśli nie określisz przypisanej przez użytkownika tożsamości zarządzanej dla kubelet, AKS utworzy tożsamość kubelet przypisaną przez użytkownika w grupie zasobów węzła. 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.

Przypisania ról dla tożsamości zarządzanych w usłudze AKS

Rolę RBAC w platformie Azure można przypisać tożsamości zarządzanej, aby nadać klastrowi uprawnienia do innego zasobu na platformie Azure. Kontrola dostępu oparta na rolach (RBAC) w Azure obsługuje zarówno wbudowane, jak i niestandardowe definicje ról, które określają poziomy uprawnień. Aby przypisać rolę, 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 zakresu ról Azure RBAC, zobacz Zrozumienie zakresu dla Azure RBAC.

Przypisania ról dla tożsamości zarządzanej w płaszczyźnie sterowania

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, gdzie zasoby są poza grupą zasobów węzła roboczego, interfejs wiersza polecenia platformy Azure automatycznie dodaje przypisanie roli. Jeśli używasz szablonu ARM lub innej metody, użyj identyfikatora tożsamości zarządzanej, aby wykonać przypisanie roli.

Jeśli nie używasz Azure CLI, ale korzystasz z własnej sieci wirtualnej, dołączonych dysków Azure, statycznego adresu IP, tabeli tras lub tożsamości kubeleta przypisanej przez użytkownika, która znajduje się poza grupą 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 dopiero po utworzeniu klastra.

Podsumowanie tożsamości zarządzanych używanych przez AKS

Usługa AKS używa kilku tożsamości zarządzanych dla wbudowanych usług i dodatków. W poniższej tabeli przedstawiono podsumowanie tożsamości zarządzanych używanych przez usługę AKS, ich przypadków użycia, uprawnień domyślnych oraz tego, czy można wprowadzić własną tożsamość:

Następny krok: Włączanie tożsamości zarządzanych w usłudze AKS

Aby dowiedzieć się, jak włączyć tożsamości zarządzane w nowym lub istniejącym klastrze usługi AKS, zobacz Używanie tożsamości zarządzanej w usłudze Azure Kubernetes Service (AKS).