Notatka
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
W tym artykule opisano sposób, w jaki usługa Azure Kubernetes Service (AKS) decyduje, co może zrobić uwierzytelniony użytkownik w stosunku do interfejsu API Kubernetes. Obejmuje dwa modele autoryzacji, które obsługuje AKS oraz szczegółowe sterowanie zasobami niestandardowymi przy użyciu warunków Azure ABAC.
Aby dowiedzieć się, jak usługa AKS uwierzytelnia osoby wywołujące w pierwszej kolejności, zobacz Pojęcia dotyczące uwierzytelniania klastra.
Aby uzyskać orientację we wszystkich czterech scenariuszach tożsamości usługi AKS, zobacz Opcje dostępu i tożsamości dla usługi AKS.
Autoryzowanie interfejsu API platformy Kubernetes
Po uwierzytelnieniu podmiotu wywołującego, usługa AKS ocenia, czy podmiot wywołujący ma autoryzację do wykonania żądanej akcji. Usługa AKS obsługuje dwa modele autoryzacji dla interfejsu API Kubernetes:
- Kontrola dostępu oparta na rolach (RBAC) platformy Kubernetes. Natywny model autoryzacji Kubernetes. Uprawnienia są definiowane jako obiekty
RoleiClusterRoleoraz przyznawane podmiotom za pośrednictwem obiektówRoleBindingiClusterRoleBindingprzechowywanych w każdym klastrze. - Autoryzacja identyfikatora Entra firmy Microsoft. Webhook autoryzacyjny AKS, który deleguje decyzje dotyczące autoryzacji do Microsoft Entra ID. Uprawnienia są przyznawane jako przypisania ról platformy Azure do tożsamości Entra ID i mogą być opcjonalnie uściślane za pomocą warunków usługi Azure ABAC.
Oba modele można używać w tym samym klastrze. Zalecamy autoryzację Microsoft Entra ID jako domyślną, a Kubernetes RBAC do precyzyjnych uprawnień wewnątrz klastra. W pozostałej części tej sekcji wyjaśniono, dlaczego i kiedy należy z nich korzystać.
RBAC Kubernetes
Kontrola dostępu oparta na rolach platformy Kubernetes to nadrzędny model autoryzacji kubernetes.
Role Tworzysz lub ClusterRole obiekty, które udzielają czasowników (takich jak get, list, create) w zasobach (takich jak pods, deployments) i wiążą je z podmiotami (użytkownikami, grupami lub kontami usług) przy użyciu RoleBinding lub ClusterRoleBinding obiektów. Wbudowany autoryzator RBAC serwera interfejsu API Kubernetes ocenia te powiązania na każdym żądaniu.
Użyj Kubernetes RBAC, jeśli chcesz:
- Szczegółowa, wewnątrzklastrowa kontrola dostępu na poziomie przestrzeni nazw tworzona jako manifesty Kubernetes towarzyszące chronionym obciążeniom.
- Autoryzacja zarządzana przez usługę GitOps, która znajduje się w tym samym źródle prawdy co konfiguracja aplikacji.
- Uprawnienia do kont usług w klastrze używanych przez obciążenia do wywoływania interfejsu API Kubernetes.
Uprawnienia RBAC platformy Kubernetes są ograniczone do jednego klastra. Aby zastosować te same zasady do wielu klastrów, należy zastosować manifesty do każdego klastra (zazwyczaj za pomocą metodyki GitOps). Użyj użytkowników i grup Microsoft Entra jako podmiotów w obiektach Kubernetes RoleBinding i ClusterRoleBinding, aby tożsamości użytkowników nadal pochodziły z centralnego katalogu.
Aby uzyskać informacje na temat modelu RBAC platformy Kubernetes, zobacz dokumentację RBAC głównej wersji Kubernetes. Aby skonfigurować AKS, zapoznaj się z Use Kubernetes RBAC with Microsoft Entra integration.
Autoryzacja identyfikatora Entra firmy Microsoft dla interfejsu API platformy Kubernetes
Usługa AKS wdraża webhook autoryzacji, który deleguje decyzje dotyczące autoryzacji interfejsu API Kubernetes do Microsoft Entra ID. Gdy żądanie dociera do serwera API, webhook wywołuje API Entra ID checkaccess w celu oceny przypisań ról platformy Azure obiektu wywołującego (i wszelkich dołączonych warunków ABAC) i zwraca decyzję dotyczącą zezwolenia lub odmowy.
Autoryzacja Entra ID zapewnia następujące korzyści w porównaniu z zarządzaniem manifestami RBAC Kubernetes na każdym klastrze:
- Pojedyncza płaszczyzna tożsamości. Ci sami użytkownicy, grupy i jednostki usługi firmy Microsoft, które zarządzają dostępem do zasobów platformy Azure, również zarządzają dostępem do interfejsu API kubernetes. Nie ma oddzielnego katalogu użytkowników do przydzielania ani rotowania.
- Przypisz raz, zarządzaj wieloma klastrami. Przypisania ról platformy Azure można wykonywać w zakresie subskrypcji, grupy zarządzania lub grupy zasobów. Pojedyncze przypisanie roli na poziomie grupy zasobów przyznaje dostęp do każdego bieżącego i przyszłego klastra AKS w tej grupie zasobów. W przypadku Kubernetes RBAC należy zastosować manifesty do każdego klastra indywidualnie.
- Dostęp warunkowy i usługa Privileged Identity Management (PIM). Dostęp do klastra automatycznie dziedziczy istniejące zasady dostępu warunkowego Entra ID (takie jak uwierzytelnianie wieloskładnikowe lub ograniczenia oparte na lokalizacji) i może być podwyższony na czas za pośrednictwem usługi PIM (Zarządzanie Tożsamościami Prywatnymi).
- Scentralizowana inspekcja. Każda zmiana przypisania roli jest rejestrowana w dzienniku aktywności platformy Azure wraz z innymi zmianami zasobów platformy Azure, dlatego istnieje jeden dziennik inspekcji na potrzeby zarządzania dostępem do klastra.
- Szczegółowe, precyzyjne ograniczenia zasobów niestandardowych. W przypadku warunków ABAC można ograniczyć dostęp do określonych grup zasobów niestandardowych (CRD) i rodzajów bez konieczności pisania manifestów RBAC dla klastra Kubernetes.
Usługa AKS udostępnia następujące wbudowane role autoryzacji Entra ID:
| roli | Description |
|---|---|
| przeglądający RBAC w Azure Kubernetes Service | Dostęp tylko do odczytu do większości obiektów w przestrzeni nazw. Nie zezwala na wyświetlanie ról, powiązań ról ani Secrets. |
| Autor RBAC usługi Azure Kubernetes Service | 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. |
| Administrator Azure Kubernetes Service RBAC | Dostęp do odczytu/zapisu do większości zasobów w przestrzeni nazw oraz możliwość tworzenia ról i powiązań ról w przestrzeni nazw. |
| Administrator klastra RBAC dla usługi Azure Kubernetes Service | Pełna kontrola nad każdym zasobem w klastrze we wszystkich przestrzeniach nazw. |
W przypadku niestandardowych schematów uprawnień można tworzyć niestandardowe definicje ról przeznaczone dla określonych grup Kubernetes API, wykorzystując akcje danych dostawcy zasobów Microsoft.ContainerService. Aby uzyskać szczegółowe przykłady konfiguracji i ról niestandardowych, zobacz Use Microsoft Entra ID authorization for the Kubernetes API (Używanie autoryzacji identyfikatora Entra firmy Microsoft dla interfejsu API kubernetes).
Comparison
| Zdolność | RBAC Kubernetes | Autoryzacja Entra ID |
|---|---|---|
| Źródło tożsamości | Użytkownicy, grupy, konta usług platformy Kubernetes | Tożsamości Microsoft Entra ID |
| Zakres pojedynczego udzielenia | Jeden klaster | Zasób, grupa zasobów, subskrypcja lub grupa zarządzania |
| Zarządzanie wieloma klastrami | Stosowanie manifestów do każdego klastra (zazwyczaj GitOps) | Jedno przypisanie roli na wyższym poziomie zarządza wieloma klastrami |
| Dostęp warunkowy /PIM | Niewspierane | Dziedziczone z Entra ID |
| Dziennik inspekcji | Dziennik inspekcji klastra | Dziennik aktywności platformy Azure |
| Filtruj dostęp według grupy lub rodzaju CRD | Autoryzowanie per-CRD Role obiektów |
Używanie atrybutów warunku ABAC w przypisaniu roli |
Ograniczanie dostępu do zasobów niestandardowych przy użyciu warunków ABAC
W przypadku udzielenia szerokiego dostępu do odczytu za pośrednictwem autoryzacji Microsoft Entra ID, ale chcesz ograniczyć zasoby niestandardowe (CRD), które mogą być odczytane przez przypisanego użytkownika, dołącz warunek ABAC platformy Azure do przypisania roli.
Bez warunków ABAC, przyznanie odczytu zasobom niestandardowym wymaga użycia symbolu wieloznacznego, takiego jak Microsoft.ContainerService/managedClusters/*/read, który obejmuje każdy CRD na każdym klastrze w zakresie. Przy użyciu ABAC można dołączyć warunek, który ogranicza dostęp do określonych grup i rodzajów CRD — na przykład zezwalaj na templates.gatekeeper.sh, blokując kyverno.io — bez potrzeby pisania manifestów RBAC dla każdego klastra Kubernetes.
W przypadku autoryzacji interfejsu API w Kubernetes można filtrować dostęp do zasobów niestandardowych według ich grupy API oraz typu, korzystając z następujących atrybutów:
Microsoft.ContainerService/managedClusters/customResources:groupMicrosoft.ContainerService/managedClusters/customResources:kind
Aby zapoznać się z omówieniem usługi Azure ABAC, zobacz Co to są warunki przypisywania ról platformy Azure?. Aby uzyskać instrukcje krok po kroku, zobacz Ograniczanie dostępu do zasobów niestandardowych przy użyciu warunków ABAC.