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

Dostęp do klastrów Kubernetes można uwierzytelnić, autoryzować, zabezpieczyć 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 Azure Kubernetes Service (AKS) można dodatkowo zwiększyć strukturę zabezpieczeń i uprawnień przy użyciu usługi Azure Active Directory i kontroli dostępu opartej na rolach platformy Azure.

Usługa Kubernetes RBAC i AKS pomagają zabezpieczyć dostęp do klastra i zapewnić tylko minimalne wymagane uprawnienia dla deweloperów i operatorów.

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:

  • Przypisywanie uprawnień użytkowników lub grup użytkowników do tworzenia i modyfikowania zasobów lub wyświetlania dzienników z uruchamiania obciążeń aplikacji.
  • Możesz ograniczyć uprawnienia do jednej 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 w zasobach klastra poza daną przestrzenią nazw, możesz zamiast tego użyć klasterRoles.

KlasterRole

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 usługą Azure Active Directory (Azure AD), roleBindings przyznaj uprawnienia Azure AD użytkownikom 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 usługi Azure Active Directory.

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ć klastra ClusterRoleBindings.

ClusterRoleBinding

W przypadku klastra ClusterRoleBinding 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 wszystkie 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ługi są jednym z głównych typów użytkowników w usłudze 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 udostępnia rozwiązania do zarządzania tożsamościami do przechowywania zwykłych kont użytkowników i haseł, można zintegrować zewnętrzne rozwiązania tożsamości z platformą Kubernetes. W przypadku klastrów usługi AKS to zintegrowane rozwiązanie tożsamości jest Azure AD.

Aby uzyskać więcej informacji na temat opcji tożsamości w usłudze Kubernetes, zobacz Uwierzytelnianie 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 usługi AKS.
Kontrola dostępu na podstawie ról platformy Azure Zaprojektowana do pracy z zasobami w ramach subskrypcji platformy Azure.

W przypadku 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 (RBAC) platformy Azure?

Istnieją dwa poziomy dostępu potrzebne do pełnego działania klastra usługi AKS:

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. Możesz na przykład użyć roli współautora Azure Kubernetes Service do skalowania i uaktualniania klastra. Tymczasem inny użytkownik z rolą klastra Azure Kubernetes Service Administracja ma uprawnienia tylko do ściągania Administracja kubeconfig.

Alternatywnie możesz nadać użytkownikowi ogólną rolę Współautor . W przypadku ogólnej roli Współautor użytkownicy mogą wykonywać powyższe uprawnienia i każdą akcję możliwą w zasobie usługi AKS, z wyjątkiem zarządzania uprawnieniami.

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 platformy Kubernetes

Dzięki integracji kontroli dostępu opartej na rolach platformy Azure usługa AKS będzie używać serwera webhook autoryzacji Kubernetes, aby zarządzać Azure AD zintegrowane uprawnienia i przypisania zasobów klastra Kubernetes 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 interfejsu API kubernetes będą postępować zgodnie z tym samym przepływem uwierzytelniania, jak wyjaśniono w sekcji integracji usługi Azure Active Directory.

Jeśli tożsamość wysyłająca żądanie istnieje w Azure AD, platforma Azure będzie zespołem z kontrolą RBAC platformy Kubernetes w celu autoryzowania żądania. Jeśli tożsamość istnieje poza Azure AD (tj. konto 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, tak jak w przypadku ról platformy Kubernetes.

Dzięki tej funkcji nie tylko dajesz użytkownikom uprawnienia do zasobu usługi AKS w ramach subskrypcji, ale także konfigurujesz rolę i uprawnienia dla każdego z tych klastrów kontrolujących dostęp do interfejsu API Kubernetes. Możesz na przykład udzielić Azure Kubernetes Service RBAC Reader roli 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ółowych informacji i wskazówek krok po kroku, postępuj zgodnie z instrukcjami dotyczącymi korzystania z kontroli dostępu opartej na rolach platformy Azure dla autoryzacji platformy 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
Azure Kubernetes Service czytnik kontroli dostępu opartej na rolach 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 Secretspliku . Secrets Odczytywanie 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ń).
Azure Kubernetes Service zapisywania kontroli dostępu opartej na rolach 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 Secrets dostępu do zasobników i uruchamianie ich jako dowolnego konta usługi w przestrzeni nazw, dzięki czemu można użyć go do uzyskania poziomów dostępu do interfejsu API dowolnego konta usługi w przestrzeni nazw.
Administracja kontroli dostępu opartej na rolach Azure Kubernetes Service Zezwala na dostęp administratora, który ma zostać przyznany 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 przydziału zasobów ani do samej przestrzeni nazw.
Azure Kubernetes Service Administracja klastra RBAC Umożliwia dostęp superu użytkownika do wykonywania dowolnej akcji w dowolnym zasobie.
Zapewnia pełną kontrolę nad każdym zasobem w klastrze i we wszystkich przestrzeniach nazw.

integracja Azure AD

Zwiększ bezpieczeństwo klastra usługi AKS przy użyciu integracji Azure AD. Oparta na dziesięcioleciach zarządzania tożsamościami przedsiębiorstwa, Azure AD to wielodostępna, oparta na chmurze usługa do zarządzania katalogami i tożsamościami, która łączy podstawowe usługi katalogowe, zarządzanie dostępem do aplikacji i ochronę tożsamości. Dzięki Azure AD można zintegrować tożsamości lokalne z klastrami usługi AKS w celu zapewnienia jednego źródła do zarządzania kontami i zabezpieczeń.

Integracja usługi Azure Active Directory z klastrami usługi AKS

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

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

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

Azure AD uwierzytelnianie 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ę open ID 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 jako część 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:

  1. kubectlużywa aplikacji klienckiej Azure AD do logowania użytkowników przy użyciu przepływu udzielania autoryzacji urządzenia OAuth 2.0.
  2. Azure AD zapewnia access_token, id_token i refresh_token.
  3. Użytkownik wysyła żądanie z kubectl access_token z kubeconfig.
  4. kubectl wysyła access_token do serwera API Server.
  5. Serwer interfejsu API jest skonfigurowany z serwerem webhook Auth w celu przeprowadzenia walidacji.
  6. Serwer uwierzytelniania elementu webhook potwierdza, że podpis tokenu internetowego JSON jest prawidłowy, sprawdzając klucz podpisywania publicznego Azure AD.
  7. Aplikacja serwera używa poświadczeń podanych przez użytkownika do wykonywania zapytań dotyczących członkostwa w grupie zalogowanego użytkownika z interfejs Graph API MS.
  8. 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.
  9. Interfejs API podejmuje decyzję o autoryzacji na podstawie roli/roli/powiązania ról platformy Kubernetes.
  10. Po autoryzacji serwer interfejsu API zwraca odpowiedź na kubectladres .
  11. kubectl przekazuje użytkownikowi opinię.

Dowiedz się, jak zintegrować usługę AKS z Azure AD z naszym przewodnikiem dotyczącym integracji Azure AD zarządzanym 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 odczytania identyfikatora zestawu szyfrowania dysku.
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 publicznych adresów IP ruchu wychodzącego 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 opartych na protokole IP Load Balancer.

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 dysków 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 plików 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 usłudze 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 usłudze 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 usłudze 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 programie 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 dysku 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 do 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 nazwa_sieci_domeny_strefa_domeny.

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 dostępu usługi ZARZĄDZANEj 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 w usłudze Kubernetes po włączeniu integracji Azure AD. We wszystkich przypadkach sekwencja poleceń użytkownika to:

  1. Uruchom polecenie az login , aby uwierzytelnić się na platformie Azure.

  2. Uruchom polecenie , az aks get-credentials aby pobrać poświadczenia dla klastra do .kube/configpliku .

  3. 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 Azure Portal można znaleźć:

  • Na karcie Access Control jest wyświetlany udzielenie roli (udzielanie ról RBAC platformy Azure) określone w drugiej kolumnie.
  • Grupa Administracja Azure AD klastra 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 Grupy Azure AD administratora klastra Kiedy stosować
Logowanie starszego administratora przy użyciu certyfikatu klienta Rola Administracja platformy Azure Kubernetes. Ta rola umożliwia az aks get-credentials użycie flagi--admin, która pobiera starszy (nie Azure AD) certyfikat administratora klastra do konta użytkownika .kube/config. Jest to jedyny cel roli "Azure Kubernetes Administracja Role". n/d Jeśli trwale zablokowano dostęp do prawidłowej grupy Azure AD z dostępem do klastra.
Azure AD za pomocą ręcznych (Cluster)RoleBindings Rola użytkownika usługi Azure Kubernetes. Rola "Użytkownik" umożliwia az aks get-credentials korzystanie bez flagi --admin . (Jest to jedyny cel "Rola użytkownika platformy Azure Kubernetes"). Wynikiem, w klastrze z obsługą Azure AD, jest pobranie pustego wpisu w .kube/configprogramie , który wyzwala uwierzytelnianie oparte na przeglądarce, gdy jest używany jako pierwszy przez kubectlprogram . Użytkownik nie znajduje się w żadnej z tych grup. Ponieważ użytkownik nie znajduje się w żadnej grupie Administracja klastra, ich prawa będą całkowicie kontrolowane przez wszystkie roleBindings lub ClusterRoleBindings, które zostały skonfigurowane przez administratorów klastra. (Cluster)RoleBindings nominuje użytkowników Azure AD lub grup Azure AD jako grupsubjects. Jeśli nie skonfigurowano żadnych takich powiązań, użytkownik nie będzie mógł wydać żadnych kubectl poleceń. Jeśli chcesz uzyskać szczegółową kontrolę dostępu i nie używasz kontroli dostępu opartej na rolach 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.
Azure AD przez 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 przyznać użytkownikom pełne prawa administratora i nie używasz kontroli dostępu opartej na rolach platformy Azure na potrzeby autoryzacji platformy Kubernetes.
Azure AD za pomocą kontroli dostępu opartej na rolach platformy Azure na potrzeby autoryzacji platformy Kubernetes Dwie role:
Najpierw rola użytkownika usługi Azure Kubernetes (jak powyżej).
Po drugie, jeden z "Azure Kubernetes Service kontroli dostępu opartej na rolach..." role wymienione powyżej lub własną alternatywę niestandardową.
Pole Role administratora na karcie Konfiguracja nie ma znaczenia, gdy jest włączona kontrola dostępu oparta 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 uzyskać więcej informacji na temat podstawowych pojęć związanych z platformą Kubernetes i usługą AKS, zobacz następujące artykuły: