Udostępnij za pośrednictwem

Opcje dostępu i tożsamości dla usługi AKS włączone przez usługę Azure Arc

  • Artykuł

Dotyczy: usługa AKS w usłudze Azure Local, wersja 23H2

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

Kontrola dostępu na podstawie ról platformy Kubernetes i kontrola dostępu oparta na rolach platformy Azure 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 przy użyciu kontroli dostępu opartej na rolach platformy Kubernetes należy zdefiniować uprawnienia użytkownika jako rolę. Udzielanie uprawnień w przestrzeni nazw kubernetes przy użyciu ról.

Role platformy Kubernetes udzielają uprawnień; nie odmawiają uprawnień. Aby udzielić uprawnień w całym klastrze lub zasobom klastra poza daną przestrzenią nazw, możesz 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 należy przypisać te uprawnienia RBAC platformy Kubernetes za pomocą funkcji 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 Kontrola dostępu przy użyciu identyfikatora Entra firmy Microsoft i kontroli dostępu opartej na rolach platformy Kubernetes

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, użyj właściwości 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.

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 oparta na rolach platformy 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 wymagane poziomy dostępu, aby w pełni obsługiwać klaster usługi AKS Arc:

  • Uzyskaj dostęp do zasobu usługi AKS w ramach subskrypcji platformy Azure.
    • Kontrolowanie skalowania lub uaktualniania klastra przy użyciu usługi AKS włączonej przez interfejsy API usługi Azure Arc.
    • Pull your admin, certificate-based kubeconfig.
    • Pobierz identyfikator entra z włączoną konfiguracją kubeconfig.
  • Dostęp do interfejsu API platformy Kubernetes. Ten dostęp jest kontrolowany przez:
    • Kontrola dostępu oparta na rolach platformy Kubernetes lub
    • 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. Dla tej akcji płaszczyzny sterowania są dostępne trzy role: rola administratora klastra usługi Azure Kubernetes Service Arc, rola użytkownika klastra usługi Azure Kubernetes Service Arc oraz rola współautora usługi Azure Kubernetes Service Arc. Każda rola ma inny zakres uprawnień zgodnie z opisem we wbudowanych rolach platformy Azure dla kontenerów. Na przykład możesz użyć roli Współautor usługi Azure Kubernetes Service Arc do tworzenia, skalowania i uaktualniania klastra. Tymczasem inny użytkownik z rolą administratora klastra usługi Azure Kubernetes Service Arc ma uprawnienia tylko do ściągania narzędzia kubeconfig administratora.

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

Dzięki integracji kontroli dostępu opartej na rolach platformy Azure usługa AKS używa serwera elementu 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.

Diagram przepływu autoryzacji.

Jak pokazano na tym diagramie, w przypadku korzystania z integracji kontroli dostępu opartej na rolach platformy Azure wszystkie żądania do interfejsu API Kubernetes są zgodne z tym samym przepływem uwierzytelniania, jak opisano w temacie Integracja z firmą Microsoft Entra.

Jeśli tożsamość wysyłająca żądanie istnieje w identyfikatorze Entra firmy Microsoft, zespoły platformy Azure z kontrolą dostępu opartą na rolach platformy Kubernetes w celu autoryzowania żądania. Jeśli tożsamość istnieje poza identyfikatorem Entra firmy Microsoft (na przykład kontem usługi Kubernetes), odchyli reguły autoryzacji do normalnej kontroli dostępu opartej na rolach 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. Dla tej akcji płaszczyzny danych są dostępne cztery wbudowane role, z których każda ma własny zakres uprawnień, zgodnie z opisem w sekcji ról wbudowanych .

Ważne

Przed przypisaniem roli 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, zobacz Use Azure RBAC for Kubernetes authorization (Używanie kontroli dostępu opartej na rolach platformy Azure na potrzeby autoryzacji na platformie Kubernetes).

Wbudowane role

Usługa AKS włączona przez usługę Arc udostępnia następujące pięć wbudowanych ról. 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
Użytkownik klastra Kubernetes z obsługą usługi Azure Arc Umożliwia pobranie pliku kubeconfig opartego na połączeniu klastra w celu zarządzania klastrami z dowolnego miejsca.
Podgląd platformy Kubernetes w usłudze Azure Arc Umożliwia dostęp tylko do odczytu, aby wyświetlić większość obiektów w przestrzeni nazw.
Nie zezwala na wyświetlanie wpisów tajnych, ponieważ uprawnienie do odczytu wpisów tajnych umożliwia dostęp do poświadczeń usługi ServiceAccount w przestrzeni nazw. Te poświadczenia z kolei umożliwiają dostęp do interfejsu API za pośrednictwem tej wartości usługi ServiceAccount (forma eskalacji uprawnień).
Składnik zapisywania platformy Kubernetes w usłudze Azure Arc 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. Jednak ta rola umożliwia uzyskiwanie dostępu do wpisów tajnych i uruchamianie zasobników jako dowolnej wartości usługi ServiceAccount w przestrzeni nazw, dzięki czemu może służyć do uzyskiwania poziomów dostępu interfejsu API dowolnej takiej wartości usługi ServiceAccount w przestrzeni nazw.
Administrator usługi Azure Arc Kubernetes Zezwala na dostęp administratora. Ma zostać udzielona w przestrzeni nazw za pomocą funkcji RoleBinding. Jeśli używasz go w funkcji RoleBinding, umożliwia dostęp do odczytu/zapisu do większości zasobów w przestrzeni nazw, w tym możliwość tworzenia ról i powiązań ról w przestrzeni nazw. Ta rola nie zezwala na dostęp do zapisu do limitu przydziału zasobów ani do samej przestrzeni nazw.
Administrator klastra Kubernetes w usłudze Azure Arc Umożliwia dostęp "superużytkownikowi" do wykonywania dowolnej akcji na dowolnym zasobie. Gdy używasz go w klastrze ClusterRoleBinding, zapewnia pełną kontrolę nad każdym zasobem w klastrze i we wszystkich przestrzeniach nazw. Gdy używasz go w usłudze RoleBinding, zapewnia pełną kontrolę nad każdym zasobem w przestrzeni nazw powiązania roli, w tym nad samą przestrzenią nazw.

Integracja z usługą Microsoft Entra

Zwiększ bezpieczeństwo klastra usługi AKS dzięki integracji z firmą Microsoft Entra. Bazując na środowisku zarządzania tożsamościami w przedsiębiorstwie, 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ń.

Schemat blokowy przedstawiający integrację entra.

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ć kontekst konfiguracji kubectl , uruchom polecenie az aksarc get-credentials .
  • Gdy użytkownik wchodzi w interakcję z klastrem usługi AKS przy użyciu narzędzia kubectl, 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 Kubernetes.

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.

Podsumowanie

Poniższa tabela zawiera podsumowanie sposobu uwierzytelniania użytkowników na platformie Kubernetes po włączeniu integracji z firmą Microsoft Entra. We wszystkich przypadkach sekwencja poleceń to:

  1. Uruchom polecenie az login , aby uwierzytelnić się na platformie Azure.
  2. Uruchom polecenie az aksarc get-credentials , aby pobrać poświadczenia dla klastra Kubernetes w systemie .kube/config.
  3. Uruchom kubectl polecenia.
    • Pierwsze polecenie może wyzwolić uwierzytelnianie oparte na przeglądarce, aby uwierzytelnić się w klastrze Kubernetes, zgodnie z opisem w poniższej tabeli.
opis Wymagane przyznanie roli Administratorzy klastra — grupy firmy Microsoft Kiedy używać
Logowanie administratora przy użyciu certyfikatu klienta Rola administratora klastra usługi Azure Kubernetes Service Arc. Ta rola umożliwia az aksarc get-credentials używanie z flagą --admin , która pobiera certyfikat administratora klastra entra firmy innej niż Microsoft do pliku .kube/config użytkownika. Jest to jedyny cel roli administratora usługi Azure Kubernetes. 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ęcznymi powiązaniami ról (klastra) Rola użytkownika klastra usługi Azure Kubernetes Service Arc. Rola Użytkownika umożliwia az aksarc get-credentials używanie jej bez flagi --admin . Jest to jedyny cel roli użytkownika klastra usługi Azure Kubernetes Service). Wynikiem w klastrze z obsługą identyfikatorów entra firmy Microsoft jest pobranie pustego wpisu do pliku .kube/config, który wyzwala uwierzytelnianie oparte na przeglądarce, gdy jest on używany po raz pierwszy przez narzędzie kubectl. Ponieważ użytkownik nie należy do żadnej grupy administracyjnej klastra, ich prawa są kontrolowane całkowicie przez wszystkie roleBindings lub ClusterRoleBindings skonfigurowane przez administratorów klastra. Grupa RoleBindings (Klaster) nominuje użytkowników firmy Microsoft Entra lub grup Microsoft Entra jako swoich tematów. Jeśli takie powiązania nie zostały skonfigurowane, użytkownik nie może wydać żadnych poleceń kubectl . 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ę przy użyciu jednej z innych metod wymienionych w tej tabeli.
Microsoft Entra ID by member of cluster admin Microsoft Entra group (ustaw przy użyciu --aad-admin-group-object-ids flagi w interfejsie wiersza polecenia platformy Azure) Tak samo jak poprzednio. 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 przyznać użytkownikom pełne prawa administratora i nie używasz kontroli dostępu opartej na rolach platformy Azure na potrzeby autoryzacji platformy Kubernetes.
Microsoft Entra ID with Azure RBAC for Kubernetes authorization (Identyfikator entra firmy Microsoft z kontrolą dostępu opartą na rolach platformy Azure dla autoryzacji na platformie Kubernetes) Dwie role:
Rola użytkownika klastra usługi Azure Kubernetes Service Arc (zgodnie z wcześniejszym opisem).
Jedną z opisanych wcześniej ról platformy Kubernetes w usłudze Azure Arc lub własnej alternatywy niestandardowej.		 Pole Role administratora na karcie Konfiguracja nie ma znaczenia, gdy włączono autoryzację RBAC platformy Azure dla platformy Kubernetes. Kontrola dostępu oparta na rolach platformy Azure jest używana na potrzeby autoryzacji platformy Kubernetes. Takie podejście zapewnia szczegółową kontrolę bez konieczności konfigurowania funkcji RoleBindings lub ClusterRoleBindings.

Następne kroki