Opcje dostępu i tożsamości dla usługi Azure Kubernetes Service (AKS)

Artykuł
08/02/2024

Dostęp do klastrów Kubernetes można uwierzytelniać, autoryzować, zabezpieczać i kontrolować na różne sposoby:

Za pomocą kontroli dostępu opartej na rolach (RBAC) platformy Kubernetes można udzielić użytkownikom, grupom i kontom usług dostępu tylko do potrzebnych zasobów.
Dzięki usłudze Azure Kubernetes Service (AKS) można jeszcze bardziej zwiększyć strukturę zabezpieczeń i uprawnień przy użyciu identyfikatora Entra firmy Microsoft i kontroli dostępu opartej na rolach platformy Azure.

Kontrola dostępu na podstawie ról platformy Kubernetes i usługa AKS pomagają zabezpieczyć dostęp do klastra i zapewnić tylko minimalne wymagane uprawnienia deweloperom i operatorom.

W tym artykule przedstawiono podstawowe pojęcia, które ułatwiają uwierzytelnianie i przypisywanie uprawnień w usłudze AKS.

Kontrola dostępu na podstawie ról na platformie Kubernetes

Kontrola dostępu oparta na rolach platformy Kubernetes zapewnia szczegółowe filtrowanie akcji użytkownika. Dzięki temu mechanizmowi sterowania:

Przypisujesz użytkownikom lub grupom użytkowników uprawnienia do tworzenia i modyfikowania zasobów lub wyświetlania dzienników z uruchomionych obciążeń aplikacji.
Można ograniczyć zakres uprawnień do pojedynczej przestrzeni nazw lub w całym klastrze usługi AKS.
Role można tworzyć w celu zdefiniowania uprawnień, a następnie przypisywać te role do użytkowników z powiązaniami ról.

Aby uzyskać więcej informacji, zobacz Using Kubernetes RBAC authorization (Używanie autoryzacji RBAC platformy Kubernetes).

Role i role klastra

Role

Przed przypisaniem uprawnień do użytkowników za pomocą kontroli dostępu opartej na rolach platformy Kubernetes zdefiniujesz uprawnienia użytkownika jako rolę. Udzielanie uprawnień w przestrzeni nazw przy użyciu ról.

Uwaga

Role platformy Kubernetes udzielają uprawnień; nie odmawiają uprawnień.

Aby udzielić uprawnień w całym klastrze lub zasobom klastra poza daną przestrzenią nazw, możesz zamiast tego użyć klasterRole.

ClusterRoles

KlasterRole przyznaje i stosuje uprawnienia do zasobów w całym klastrze, a nie do określonej przestrzeni nazw.

RoleBindings i ClusterRoleBindings

Po zdefiniowaniu ról w celu udzielenia uprawnień do zasobów przypiszesz te uprawnienia RBAC platformy Kubernetes z funkcją RoleBinding. Jeśli klaster usługi AKS integruje się z identyfikatorem Entra firmy Microsoft, funkcja RoleBindings udziela użytkownikom usługi Microsoft Entra uprawnień do wykonywania akcji w klastrze. Zobacz, jak kontrolować dostęp do zasobów klastra przy użyciu kontroli dostępu opartej na rolach platformy Kubernetes i tożsamości firmy Microsoft Entra.

Powiązania ról

Przypisz role do użytkowników dla danej przestrzeni nazw przy użyciu funkcji RoleBindings. Za pomocą funkcji RoleBindings można logicznie rozdzielić pojedynczy klaster usługi AKS, umożliwiając tylko użytkownikom dostęp do zasobów aplikacji w przypisanej przestrzeni nazw.

Aby powiązać role w całym klastrze lub z zasobami klastra poza daną przestrzenią nazw, zamiast tego należy użyć metody ClusterRoleBindings.

ClusterRoleBinding

W przypadku klastraRoleBinding należy powiązać role z użytkownikami i zastosować je do zasobów w całym klastrze, a nie do określonej przestrzeni nazw. Takie podejście umożliwia administratorom lub inżynierom pomocy technicznej dostęp do wszystkich zasobów w klastrze usługi AKS.

Uwaga

Usługa Microsoft/AKS wykonuje wszelkie akcje klastra z zgodą użytkownika w ramach wbudowanej roli aks-service Kubernetes i wbudowanego powiązania aks-service-rolebindingroli.

Ta rola umożliwia usłudze AKS rozwiązywanie i diagnozowanie problemów z klastrem, ale nie może modyfikować uprawnień ani tworzyć ról ani powiązań ról ani innych akcji o wysokim poziomie uprawnień. Dostęp do roli jest włączony tylko w ramach aktywnych biletów pomocy technicznej z dostępem just in time (JIT). Przeczytaj więcej na temat zasad pomocy technicznej usługi AKS.

Konta usługi Kubernetes

Konta usług są jednym z podstawowych typów użytkowników na platformie Kubernetes. Interfejs API platformy Kubernetes przechowuje konta usług i zarządza nimi. Poświadczenia konta usługi są przechowywane jako wpisy tajne platformy Kubernetes, dzięki czemu mogą być używane przez autoryzowane zasobniki do komunikowania się z serwerem interfejsu API. Większość żądań interfejsu API zapewnia token uwierzytelniania dla konta usługi lub normalnego konta użytkownika.

Normalne konta użytkowników umożliwiają bardziej tradycyjny dostęp dla administratorów lub deweloperów, a nie tylko usług i procesów. Chociaż platforma Kubernetes nie zapewnia rozwiązania do zarządzania tożsamościami do przechowywania zwykłych kont użytkowników i haseł, można zintegrować rozwiązania tożsamości zewnętrznej z platformą Kubernetes. W przypadku klastrów usługi AKS to zintegrowane rozwiązanie tożsamości to Microsoft Entra ID.

Aby uzyskać więcej informacji na temat opcji tożsamości w rozwiązaniu Kubernetes, zobacz Uwierzytelnianie na platformie Kubernetes.

Kontrola dostępu na podstawie ról na platformie Azure

Kontrola dostępu oparta na rolach (RBAC) platformy Azure to system autoryzacji oparty na usłudze Azure Resource Manager , który zapewnia szczegółowe zarządzanie dostępem do zasobów platformy Azure.

System kontroli dostępu opartej na rolach	opis
Kontrola dostępu na podstawie ról na platformie Kubernetes	Zaprojektowana do pracy z zasobami Kubernetes w klastrze AKS.
Kontrola dostępu na podstawie ról platformy Azure	Zaprojektowana do pracy z zasobami w ramach subskrypcji platformy Azure.

Za pomocą kontroli dostępu opartej na rolach platformy Azure utworzysz definicję roli, która zawiera opis uprawnień do zastosowania. Następnie przypiszesz użytkownikowi lub grupie tę definicję roli za pomocą przypisania roli dla określonego zakresu. Zakres może być pojedynczym zasobem, grupą zasobów lub w ramach subskrypcji.

Aby uzyskać więcej informacji, zobacz Co to jest kontrola dostępu oparta na rolach platformy Azure (Azure RBAC)?

Istnieją dwa poziomy dostępu potrzebne do pełnej obsługi klastra usługi AKS:

Uzyskaj dostęp do zasobu usługi AKS w ramach subskrypcji platformy Azure.
- Kontrolowanie skalowania lub uaktualniania klastra przy użyciu interfejsów API usługi AKS.
- Przeciągnij plik kubeconfig.
Dostęp do interfejsu API platformy Kubernetes. Ten dostęp jest kontrolowany przez:
- Kubernetes RBAC (tradycyjnie).
- Integrowanie kontroli dostępu opartej na rolach platformy Azure z usługą AKS na potrzeby autoryzacji platformy Kubernetes.

Kontrola dostępu oparta na rolach platformy Azure w celu autoryzowania dostępu do zasobu usługi AKS

Dzięki kontroli dostępu opartej na rolach platformy Azure możesz zapewnić użytkownikom (lub tożsamościom) szczegółowy dostęp do zasobów usługi AKS w ramach co najmniej jednej subskrypcji. Na przykład możesz użyć roli Współautor usługi Azure Kubernetes Service do skalowania i uaktualniania klastra. Tymczasem inny użytkownik z rolą administratora klastra usługi Azure Kubernetes Service ma uprawnienia tylko do ściągania administratora kubeconfig.

Użyj kontroli dostępu opartej na rolach platformy Azure, aby zdefiniować dostęp do pliku konfiguracji platformy Kubernetes w usłudze AKS.

Kontrola dostępu oparta na rolach platformy Azure dla autoryzacji na platformie Kubernetes

Dzięki integracji kontroli dostępu opartej na rolach platformy Azure usługa AKS będzie używać serwera webhook autoryzacji Kubernetes, dzięki czemu można zarządzać zintegrowanymi uprawnieniami i przypisaniami klastra Kubernetes firmy Microsoft przy użyciu definicji ról i przypisań ról platformy Azure.

Kontrola dostępu oparta na rolach platformy Azure dla przepływu autoryzacji platformy Kubernetes

Jak pokazano na powyższym diagramie, w przypadku korzystania z integracji kontroli dostępu opartej na rolach platformy Azure wszystkie żądania do interfejsu API kubernetes będą postępować zgodnie z tym samym przepływem uwierzytelniania, jak wyjaśniono w sekcji integracji firmy Microsoft Entra.

Jeśli tożsamość wysyłająca żądanie istnieje w identyfikatorze Entra firmy Microsoft, platforma Azure będzie zespołem z kontrolą dostępu opartą na rolach platformy Kubernetes w celu autoryzowania żądania. Jeśli tożsamość istnieje poza identyfikatorem Entra firmy Microsoft (tj. kontem usługi Kubernetes), autoryzacja zostanie odroczenie normalnego RBAC platformy Kubernetes.

W tym scenariuszu używasz mechanizmów i interfejsów API RBAC platformy Azure do przypisywania wbudowanych ról użytkowników lub tworzenia ról niestandardowych, podobnie jak w przypadku ról platformy Kubernetes.

Dzięki tej funkcji nie tylko można przyznać użytkownikom uprawnienia do zasobu usługi AKS w ramach subskrypcji, ale także skonfigurować rolę i uprawnienia wewnątrz każdego z tych klastrów kontrolujących dostęp do interfejsu API kubernetes. Na przykład możesz przyznać Azure Kubernetes Service RBAC Reader rolę w zakresie subskrypcji. Odbiorca roli będzie mógł wyświetlić listę i pobrać wszystkie obiekty Kubernetes ze wszystkich klastrów bez ich modyfikowania.

Ważne

Przed użyciem tej funkcji należy włączyć kontrolę dostępu opartą na rolach platformy Azure dla autoryzacji platformy Kubernetes. Aby uzyskać więcej szczegółów i wskazówek krok po kroku, postępuj zgodnie z instrukcjami korzystanie z kontroli dostępu opartej na rolach platformy Azure dla autoryzacji kubernetes.

Wbudowane role

Usługa AKS udostępnia następujące cztery wbudowane role. Są one podobne do wbudowanych ról platformy Kubernetes z kilkoma różnicami, takimi jak obsługa identyfikatorów CRD. Zobacz pełną listę akcji dozwolonych przez każdą wbudowaną rolę platformy Azure.

Rola	opis
Czytelnik kontroli dostępu opartej na rolach usługi Azure Kubernetes Service	Umożliwia dostęp tylko do odczytu, aby wyświetlić większość obiektów w przestrzeni nazw. Nie zezwala na wyświetlanie ról ani powiązań ról. Nie zezwala na wyświetlanie `Secrets`pliku . Odczytywanie `Secrets` zawartości umożliwia dostęp do `ServiceAccount` poświadczeń w przestrzeni nazw, co umożliwi dostęp do interfejsu API jako dowolny `ServiceAccount` w przestrzeni nazw (forma eskalacji uprawnień).
Składnik zapisywania kontroli dostępu opartej na rolach usługi Azure Kubernetes Service	Umożliwia dostęp do odczytu/zapisu do większości obiektów w przestrzeni nazw. Nie zezwala na wyświetlanie ani modyfikowanie ról ani powiązań ról. Umożliwia uzyskiwanie dostępu do `Secrets` zasobników i uruchamianie ich jako dowolnego konta usługi w przestrzeni nazw, dzięki czemu może służyć do uzyskiwania poziomów dostępu do interfejsu API dowolnego konta usługi w przestrzeni nazw.
Administrator kontroli dostępu opartej na rolach usługi Azure Kubernetes Service	Zezwala na dostęp administratora, który ma być udzielany w przestrzeni nazw. Umożliwia dostęp do odczytu/zapisu do większości zasobów w przestrzeni nazw (lub zakresie klastra), w tym możliwość tworzenia ról i powiązań ról w przestrzeni nazw. Nie zezwala na dostęp do zapisu do limitu przydziału zasobów ani do samej przestrzeni nazw.
Administrator klastra RBAC usługi Azure Kubernetes Service	Umożliwia dostęp administratora do wykonywania dowolnej akcji na dowolnym zasobie. Zapewnia pełną kontrolę nad każdym zasobem w klastrze i we wszystkich przestrzeniach nazw.

Integracja z usługą Microsoft Entra

Zwiększ bezpieczeństwo klastra usługi AKS dzięki integracji z firmą Microsoft Entra. Zbudowany na dziesięcioleciach zarządzania tożsamościami przedsiębiorstwa, Microsoft Entra ID to wielodostępna, oparta na chmurze usługa katalogów i zarządzania tożsamościami, która łączy podstawowe usługi katalogowe, zarządzanie dostępem do aplikacji i ochronę tożsamości. Dzięki identyfikatorowi Entra firmy Microsoft można zintegrować tożsamości lokalne z klastrami usługi AKS, aby zapewnić jedno źródło do zarządzania kontami i zabezpieczeń.

Integracja firmy Microsoft Entra z klastrami usługi AKS

Dzięki zintegrowanym klastrom usługi AKS firmy Microsoft można udzielić użytkownikom lub grupom dostępu do zasobów Kubernetes w przestrzeni nazw lub w klastrze.

Aby uzyskać kubectl kontekst konfiguracji, użytkownik uruchamia polecenie az aks get-credentials .
Gdy użytkownik wchodzi w interakcję z klastrem usługi AKS przy kubectlużyciu polecenia , zostanie wyświetlony monit o zalogowanie się przy użyciu poświadczeń usługi Microsoft Entra.

Takie podejście zapewnia pojedyncze źródło do zarządzania kontami użytkowników i poświadczeń haseł. Użytkownik może uzyskać dostęp tylko do zasobów zdefiniowanych przez administratora klastra.

Uwierzytelnianie entra firmy Microsoft jest udostępniane klastrom usługi AKS za pomocą protokołu OpenID Connect. OpenID Connect to warstwa tożsamości oparta na protokole OAuth 2.0. Aby uzyskać więcej informacji na temat programu OpenID Connect, zobacz dokumentację programu OpenID Connect. Z poziomu klastra Kubernetes uwierzytelnianie tokenu elementu webhook służy do weryfikowania tokenów uwierzytelniania. Uwierzytelnianie tokenu elementu webhook jest konfigurowane i zarządzane w ramach klastra usługi AKS.

Element webhook i serwer interfejsu API

Przepływ uwierzytelniania elementu webhook i serwera interfejsu API

Jak pokazano na powyższej ilustracji, serwer interfejsu API wywołuje serwer elementu webhook usługi AKS i wykonuje następujące czynności:

kubectl używa aplikacji klienckiej Microsoft Entra do logowania użytkowników przy użyciu przepływu udzielania autoryzacji urządzeń OAuth 2.0.
Identyfikator entra firmy Microsoft udostępnia access_token, id_token i refresh_token.
Użytkownik wysyła żądanie z kubectl access_token z kubeconfig.
kubectl wysyła access_token do serwera INTERFEJSu API.
Serwer interfejsu API jest skonfigurowany z serwerem webhook uwierzytelniania w celu przeprowadzenia walidacji.
Serwer elementu webhook uwierzytelniania potwierdza, że podpis tokenu internetowego JSON jest prawidłowy, sprawdzając publiczny klucz podpisywania firmy Microsoft.
Aplikacja serwera używa poświadczeń podanych przez użytkownika do wykonywania zapytań dotyczących członkostwa w grupach zalogowanego użytkownika z interfejsu API programu MS Graph.
Odpowiedź jest wysyłana do serwera interfejsu API z informacjami o użytkowniku, takimi jak oświadczenie głównej nazwy użytkownika (UPN) tokenu dostępu oraz członkostwo w grupie użytkownika na podstawie identyfikatora obiektu.
Interfejs API wykonuje decyzję o autoryzacji na podstawie roli/powiązania ról platformy Kubernetes.
Po autoryzacji serwer interfejsu API zwraca odpowiedź na kubectl.
kubectl przekazuje użytkownikowi opinię.

Dowiedz się, jak zintegrować usługę AKS z usługą Microsoft Entra ID z naszym przewodnikiem z instrukcjami dotyczącymi integracji z usługą Microsoft Entra zarządzaną przez usługę AKS.

Uprawnienia usługi AKS

Podczas tworzenia klastra usługa AKS generuje lub modyfikuje potrzebne zasoby (takie jak maszyny wirtualne i karty sieciowe), aby utworzyć i uruchomić klaster w imieniu użytkownika. Ta tożsamość różni się od uprawnień tożsamości klastra, które jest tworzone podczas tworzenia klastra.

Tożsamość tworząca i obsługując uprawnienia klastra

Następujące uprawnienia są wymagane przez tożsamość tworzącą i działającą w klastrze.

Uprawnienie	Przyczyna
`Microsoft.Compute/diskEncryptionSets/read`	Wymagane do odczytu identyfikatora zestawu szyfrowania dysków.
`Microsoft.Compute/proximityPlacementGroups/write`	Wymagane do aktualizowania grup umieszczania w pobliżu.
`Microsoft.Network/applicationGateways/read` `Microsoft.Network/applicationGateways/write` `Microsoft.Network/virtualNetworks/subnets/join/action`	Wymagane do skonfigurowania bram aplikacji i dołączenia do podsieci.
`Microsoft.Network/virtualNetworks/subnets/join/action`	Wymagane do skonfigurowania sieciowej grupy zabezpieczeń dla podsieci podczas korzystania z niestandardowej sieci wirtualnej.
`Microsoft.Network/publicIPAddresses/join/action` `Microsoft.Network/publicIPPrefixes/join/action`	Wymagane do skonfigurowania wychodzących publicznych adresów IP na usługa Load Balancer w warstwie Standardowa.
`Microsoft.OperationalInsights/workspaces/sharedkeys/read` `Microsoft.OperationalInsights/workspaces/read` `Microsoft.OperationsManagement/solutions/write` `Microsoft.OperationsManagement/solutions/read` `Microsoft.ManagedIdentity/userAssignedIdentities/assign/action`	Wymagane do tworzenia i aktualizowania obszarów roboczych usługi Log Analytics oraz monitorowania platformy Azure dla kontenerów.
`Microsoft.Network/virtualNetworks/joinLoadBalancer/action`	Wymagane do skonfigurowania pul zaplecza modułu równoważenia obciążenia opartego na adresach IP.

Uprawnienia tożsamości klastra usługi AKS

Następujące uprawnienia są używane przez tożsamość klastra usługi AKS, która jest tworzona i skojarzona z klastrem usługi AKS. Każde uprawnienie jest używane z poniższych powodów:

Uprawnienie	Przyczyna
`Microsoft.ContainerService/managedClusters/*`	Wymagane do tworzenia użytkowników i obsługi klastra
`Microsoft.Network/loadBalancers/delete` `Microsoft.Network/loadBalancers/read` `Microsoft.Network/loadBalancers/write`	Wymagane do skonfigurowania modułu równoważenia obciążenia dla usługi LoadBalancer.
`Microsoft.Network/publicIPAddresses/delete` `Microsoft.Network/publicIPAddresses/read` `Microsoft.Network/publicIPAddresses/write`	Wymagane do znalezienia i skonfigurowania publicznych adresów IP dla usługi LoadBalancer.
`Microsoft.Network/publicIPAddresses/join/action`	Wymagane do skonfigurowania publicznych adresów IP dla usługi LoadBalancer.
`Microsoft.Network/networkSecurityGroups/read` `Microsoft.Network/networkSecurityGroups/write`	Wymagane do utworzenia lub usunięcia reguł zabezpieczeń dla usługi LoadBalancer.
`Microsoft.Compute/disks/delete` `Microsoft.Compute/disks/read` `Microsoft.Compute/disks/write` `Microsoft.Compute/locations/DiskOperations/read`	Wymagane do skonfigurowania usługi AzureDisks.
`Microsoft.Storage/storageAccounts/delete` `Microsoft.Storage/storageAccounts/listKeys/action` `Microsoft.Storage/storageAccounts/read` `Microsoft.Storage/storageAccounts/write` `Microsoft.Storage/operations/read`	Wymagane do skonfigurowania kont magazynu dla usługi AzureFile lub AzureDisk.
`Microsoft.Network/routeTables/read` `Microsoft.Network/routeTables/routes/delete` `Microsoft.Network/routeTables/routes/read` `Microsoft.Network/routeTables/routes/write` `Microsoft.Network/routeTables/write`	Wymagane do skonfigurowania tabel tras i tras dla węzłów.
`Microsoft.Compute/virtualMachines/read`	Wymagane do znalezienia informacji dotyczących maszyn wirtualnych w programie VMAS, takich jak strefy, domena błędów, rozmiar i dyski danych.
`Microsoft.Compute/virtualMachines/write`	Wymagane do dołączenia dysków AzureDisks do maszyny wirtualnej w programie VMAS.
`Microsoft.Compute/virtualMachineScaleSets/read` `Microsoft.Compute/virtualMachineScaleSets/virtualMachines/read` `Microsoft.Compute/virtualMachineScaleSets/virtualmachines/instanceView/read`	Wymagane do znalezienia informacji dotyczących maszyn wirtualnych w zestawie skalowania maszyn wirtualnych, takich jak strefy, domena błędów, rozmiar i dyski danych.
`Microsoft.Network/networkInterfaces/write`	Wymagane do dodania maszyny wirtualnej w programie VMAS do puli adresów zaplecza modułu równoważenia obciążenia.
`Microsoft.Compute/virtualMachineScaleSets/write`	Wymagane do dodania zestawu skalowania maszyn wirtualnych do pul adresów zaplecza modułu równoważenia obciążenia i skalowania węzłów w poziomie w zestawie skalowania maszyn wirtualnych.
`Microsoft.Compute/virtualMachineScaleSets/delete`	Wymagane do usunięcia zestawu skalowania maszyn wirtualnych do pul adresów zaplecza modułu równoważenia obciążenia i skalowania węzłów w dół w zestawie skalowania maszyn wirtualnych.
`Microsoft.Compute/virtualMachineScaleSets/virtualmachines/write`	Wymagane do dołączenia dysków AzureDisks i dodania maszyny wirtualnej z zestawu skalowania maszyn wirtualnych do modułu równoważenia obciążenia.
`Microsoft.Network/networkInterfaces/read`	Wymagane do wyszukiwania wewnętrznych adresów IP i pul adresów zaplecza modułu równoważenia obciążenia dla maszyn wirtualnych w usłudze VMAS.
`Microsoft.Compute/virtualMachineScaleSets/virtualMachines/networkInterfaces/read`	Wymagane do wyszukiwania wewnętrznych adresów IP i pul adresów zaplecza modułu równoważenia obciążenia dla maszyny wirtualnej w zestawie skalowania maszyn wirtualnych.
`Microsoft.Compute/virtualMachineScaleSets/virtualMachines/networkInterfaces/ipconfigurations/publicipaddresses/read`	Wymagane do znalezienia publicznych adresów IP maszyny wirtualnej w zestawie skalowania maszyn wirtualnych.
`Microsoft.Network/virtualNetworks/read` `Microsoft.Network/virtualNetworks/subnets/read`	Wymagane do sprawdzenia, czy podsieć istnieje dla wewnętrznego modułu równoważenia obciążenia w innej grupie zasobów.
`Microsoft.Compute/snapshots/delete` `Microsoft.Compute/snapshots/read` `Microsoft.Compute/snapshots/write`	Wymagane do skonfigurowania migawek dla narzędzia AzureDisk.
`Microsoft.Compute/locations/vmSizes/read` `Microsoft.Compute/locations/operations/read`	Wymagane do znalezienia rozmiarów maszyn wirtualnych na potrzeby znajdowania limitów woluminów AzureDisk.

Dodatkowe uprawnienia tożsamości klastra

Podczas tworzenia klastra z określonymi atrybutami potrzebne będą następujące dodatkowe uprawnienia dla tożsamości klastra. Ponieważ te uprawnienia nie są przypisywane automatycznie, należy dodać je do tożsamości klastra po jej utworzeniu.

Uprawnienie	Przyczyna
`Microsoft.Network/networkSecurityGroups/write` `Microsoft.Network/networkSecurityGroups/read`	Wymagane w przypadku korzystania z sieciowej grupy zabezpieczeń w innej grupie zasobów. Wymagane do skonfigurowania reguł zabezpieczeń dla usługi LoadBalancer.
`Microsoft.Network/virtualNetworks/subnets/read` `Microsoft.Network/virtualNetworks/subnets/join/action`	Wymagane w przypadku korzystania z podsieci w innej grupie zasobów, takiej jak niestandardowa sieć wirtualna.
`Microsoft.Network/routeTables/routes/read` `Microsoft.Network/routeTables/routes/write`	Wymagane w przypadku używania podsieci skojarzonej z tabelą tras w innej grupie zasobów, takiej jak niestandardowa sieć wirtualna z niestandardową tabelą tras. Wymagane do sprawdzenia, czy podsieć już istnieje dla podsieci w innej grupie zasobów.
`Microsoft.Network/virtualNetworks/subnets/read`	Wymagane w przypadku korzystania z wewnętrznego modułu równoważenia obciążenia w innej grupie zasobów. Wymagane do sprawdzenia, czy podsieć już istnieje dla wewnętrznego modułu równoważenia obciążenia w grupie zasobów.
`Microsoft.Network/privatednszones/*`	Wymagane w przypadku korzystania z prywatnej strefy DNS w innej grupie zasobów, takiej jak niestandardowa prywatna strefaDNSZone.

Dostęp do węzła usługi AKS

Domyślnie program Node Access nie jest wymagany dla usługi AKS. W przypadku użycia określonego składnika wymagany jest następujący dostęp do węzła.

Access	Przyczyna
`kubelet`	Wymagane do udzielenia tożsamości usługi zarządzanej dostępu do usługi ACR.
`http app routing`	Wymagane do zapisu uprawnienia do "losowej nazwy". aksapp.io.
`container insights`	Wymagane do udzielenia uprawnień do obszaru roboczego usługi Log Analytics.

Podsumowanie

Wyświetl tabelę, aby uzyskać krótkie podsumowanie sposobu uwierzytelniania użytkowników na platformie Kubernetes po włączeniu integracji z firmą Microsoft Entra. We wszystkich przypadkach sekwencja poleceń użytkownika to:

Uruchom polecenie az login , aby uwierzytelnić się na platformie Azure.
Uruchom polecenie az aks get-credentials , aby pobrać poświadczenia dla klastra do programu .kube/config.
Uruchom kubectl polecenia.
- Pierwsze polecenie może wyzwolić uwierzytelnianie oparte na przeglądarce w celu uwierzytelnienia w klastrze, zgodnie z opisem w poniższej tabeli.

W witrynie Azure Portal można znaleźć:

Przyznanie roli (przyznanie roli RBAC platformy Azure) określone w drugiej kolumnie jest wyświetlane na karcie Kontrola dostępu.
Grupa Administrator klastra firmy Microsoft Entra jest wyświetlana na karcie Konfiguracja .
- Znaleziono również nazwę --aad-admin-group-object-ids parametru w interfejsie wiersza polecenia platformy Azure.

opis	Wymagane przyznanie roli	Administratorzy klastra — grupy firmy Microsoft	Kiedy używać
Starsze logowanie administratora przy użyciu certyfikatu klienta	Rola administratora klastra usługi Azure Kubernetes Service. Ta rola umożliwia `az aks get-credentials` używanie z flagą `--admin` , która pobiera starszy certyfikat administratora klastra (innego niż Microsoft Entra) do użytkownika `.kube/config`. Jest to jedyny cel roli administratora klastra usługi Azure Kubernetes Service.	nie dotyczy	Jeśli użytkownik zostanie trwale zablokowany, nie mając dostępu do prawidłowej grupy microsoft Entra z dostępem do klastra.
Identyfikator entra firmy Microsoft z ręcznym (Cluster)RoleBindings	Rola użytkownika klastra usługi Azure Kubernetes Service. Rola "Użytkownik" umożliwia `az aks get-credentials` używanie jej bez flagi `--admin` . (Jest to jedyny cel "Rola użytkownika klastra usługi Azure Kubernetes Service"). Wynikiem, w klastrze z obsługą identyfikatorów Entra firmy Microsoft, jest pobranie pustego wpisu do `.kube/config`programu , który wyzwala uwierzytelnianie oparte na przeglądarce, gdy jest on używany jako pierwszy przez `kubectl`program .	Użytkownik nie należy do żadnej z tych grup. Ponieważ użytkownik nie należy do żadnych grup administratorów klastra, ich prawa będą całkowicie kontrolowane przez wszystkie roleBindings lub ClusterRoleBindings, które zostały skonfigurowane przez administratorów klastra. Grupa RoleBindings (Cluster)RoleBindings nominuje użytkowników firmy Microsoft entra lub grupy Microsoft Entra jako grupy `subjects`. Jeśli takie powiązania nie zostały skonfigurowane, użytkownik nie będzie mógł wykonać żadnych `kubectl` poleceń.	Jeśli chcesz uzyskać szczegółową kontrolę dostępu i nie używasz kontroli dostępu na podstawie ról platformy Azure dla autoryzacji kubernetes. Należy pamiętać, że użytkownik, który konfiguruje powiązania, musi zalogować się za pomocą jednej z innych metod wymienionych w tej tabeli.
Microsoft Entra ID by member of admin group (Identyfikator entra firmy Microsoft według członka grupy administracyjnej)	Jak wyżej	Użytkownik jest członkiem jednej z wymienionych tutaj grup. Usługa AKS automatycznie generuje klasterRoleBinding, który wiąże wszystkie wymienione grupy z rolą `cluster-admin` Kubernetes. Dlatego użytkownicy w tych grupach mogą uruchamiać wszystkie `kubectl` polecenia jako `cluster-admin`.	Jeśli chcesz wygodnie udzielić użytkownikom pełnych praw administratora i nie używasz kontroli dostępu opartej na rolach platformy Azure na potrzeby autoryzacji na platformie Kubernetes.
Microsoft Entra ID with Azure RBAC for Kubernetes Authorization	Dwie role: Najpierw rola użytkownika klastra usługi Azure Kubernetes Service (jak pokazano powyżej). Po drugie, jeden z "RBAC usługi Azure Kubernetes Service..." role wymienione powyżej lub własną alternatywę niestandardową.	Pole Role administratora na karcie Konfiguracja nie ma znaczenia, gdy włączono kontrolę dostępu opartą na rolach platformy Azure dla autoryzacji platformy Kubernetes.	Używasz kontroli dostępu opartej na rolach platformy Azure na potrzeby autoryzacji platformy Kubernetes. Takie podejście zapewnia szczegółową kontrolę bez konieczności konfigurowania funkcji RoleBindings lub ClusterRoleBindings.

Następne kroki

Aby rozpocząć pracę z identyfikatorem Entra firmy Microsoft i kontrolą dostępu na podstawie ról platformy Kubernetes, zobacz Integrowanie identyfikatora Entra firmy Microsoft z usługą AKS.
Aby uzyskać informacje o skojarzonych najlepszych rozwiązaniach, zobacz Najlepsze rozwiązania dotyczące uwierzytelniania i autoryzacji w usłudze AKS.
Aby rozpocząć pracę z kontrolą dostępu opartą na rolach platformy Azure dla autoryzacji na platformie Kubernetes, zobacz Używanie kontroli dostępu opartej na rolach platformy Azure w klastrze usługi Azure Kubernetes Service (AKS).
Aby rozpocząć zabezpieczanie kubeconfig pliku, zobacz Ograniczanie dostępu do pliku konfiguracji klastra.
Aby rozpocząć pracę z tożsamościami zarządzanymi w usłudze AKS, zobacz Używanie tożsamości zarządzanej w usłudze AKS.

Aby uzyskać więcej informacji na temat podstawowych pojęć związanych z platformą Kubernetes i usługą AKS, zobacz następujące artykuły:

Udostępnij za pośrednictwem