Najlepsze rozwiązania dotyczące uwierzytelniania i autoryzacji w usłudze Azure Kubernetes Service (AKS)

Artykuł
02/16/2024

Podczas wdrażania i konserwacji klastrów w usłudze Azure Kubernetes Service (AKS) implementujesz sposoby zarządzania dostępem do zasobów i usług. Bez tych kontrolek:

Konta mogą mieć dostęp do niepotrzebnych zasobów i usług.
Śledzenie poświadczeń używanych do wprowadzania zmian może być trudne.

W tym artykule omówiono zalecane rozwiązania, które operator klastra może stosować w celu zarządzania dostępem i tożsamością klastrów usługi AKS. Dowiesz się, jak:

Uwierzytelnianie użytkowników klastra usługi AKS przy użyciu identyfikatora Entra firmy Microsoft.
Kontrolowanie dostępu do zasobów przy użyciu kontroli dostępu opartej na rolach (RBAC) platformy Kubernetes.
Kontrola dostępu oparta na rolach platformy Azure umożliwia szczegółową kontrolę dostępu do zasobu usługi AKS, interfejsu API Kubernetes na dużą skalę i .kubeconfig
Użyj tożsamości obciążenia, aby uzyskać dostęp do zasobów platformy Azure z zasobników.

Ostrzeżenie

Tożsamość zarządzana typu open source firmy Microsoft Entra (wersja zapoznawcza) w usłudze Azure Kubernetes Service została uznana za przestarzałą od 24.01.2022 r.

Jeśli masz włączoną tożsamość zarządzaną zasobnika firmy Microsoft w klastrze usługi AKS lub rozważasz jej wdrożenie, zalecamy zapoznanie się z artykułem Omówienie tożsamości obciążenia, aby zapoznać się z naszymi zaleceniami i opcjami konfigurowania klastra w celu korzystania z Tożsamość obciążeń Microsoft Entra (wersja zapoznawcza). Ta metoda uwierzytelniania zastępuje tożsamość zarządzaną zasobnika (wersja zapoznawcza), która integruje się z natywnymi możliwościami platformy Kubernetes w celu federacji z dowolnymi zewnętrznymi dostawcami tożsamości.

Korzystanie z identyfikatora Entra firmy Microsoft

Wskazówki dotyczące najlepszych rozwiązań

Wdrażanie klastrów usługi AKS za pomocą integracji firmy Microsoft Entra. Korzystanie z usługi Microsoft Entra ID centralizuje warstwę zarządzania tożsamościami. Każda zmiana stanu konta użytkownika lub grupy jest automatycznie aktualizowana w dostępie do klastra usługi AKS. Określanie zakresu użytkowników lub grup na minimalną liczbę uprawnień przy użyciu ról, ról, ról klastra lub powiązań.

Deweloperzy klastra Kubernetes i właściciele aplikacji muszą mieć dostęp do różnych zasobów. Platforma Kubernetes nie ma rozwiązania do zarządzania tożsamościami w celu kontrolowania zasobów, z którymi użytkownicy mogą korzystać. Zamiast tego możesz zintegrować klaster z istniejącym rozwiązaniem tożsamości, na przykład Microsoft Entra ID, rozwiązaniem do zarządzania tożsamościami gotowymi do użycia w przedsiębiorstwie.

W przypadku klastrów zintegrowanych firmy Microsoft w usłudze AKS można tworzyć role lub role klastra definiujące uprawnienia dostępu do zasobów. Następnie należy powiązać role z użytkownikami lub grupami z identyfikatora Entra firmy Microsoft. Dowiedz się więcej o tej kontroli dostępu opartej na rolach platformy Kubernetes w następnej sekcji. Integracja firmy Microsoft Entra i sposób kontrolowania dostępu do zasobów można zobaczyć na poniższym diagramie:

Cluster-level authentication for Microsoft Entra integration with AKS

Deweloper uwierzytelnia się za pomocą identyfikatora Entra firmy Microsoft.
Punkt końcowy wystawiania tokenu firmy Microsoft entra wystawia token dostępu.
Deweloper wykonuje akcję przy użyciu tokenu Microsoft Entra, takiego jak kubectl create pod.
Platforma Kubernetes weryfikuje token przy użyciu identyfikatora Entra firmy Microsoft i pobiera członkostwa w grupach dewelopera.
Są stosowane zasady kontroli dostępu opartej na rolach platformy Kubernetes i klastra.
Żądanie dewelopera zakończyło się pomyślnie na podstawie poprzedniej weryfikacji członkostwa w grupie Microsoft Entra i kontroli dostępu opartej na rolach platformy Kubernetes oraz zasad.

Aby utworzyć klaster usługi AKS używający identyfikatora Entra firmy Microsoft, zobacz Integrowanie identyfikatora Entra firmy Microsoft z usługą AKS.

Korzystanie z kontroli dostępu opartej na rolach platformy Kubernetes (RBAC) platformy Kubernetes

Wskazówki dotyczące najlepszych rozwiązań

Zdefiniuj uprawnienia użytkownika lub grupy do zasobów klastra przy użyciu kontroli dostępu opartej na rolach platformy Kubernetes. Utwórz role i powiązania, które przypisują najmniejszą wymaganą ilość uprawnień. Integracja z identyfikatorem Entra firmy Microsoft w celu automatycznej aktualizacji stanu użytkownika lub zmiany członkostwa w grupie i utrzymania dostępu do zasobów klastra.

Na platformie Kubernetes zapewniasz szczegółową kontrolę dostępu do zasobów klastra. Uprawnienia są definiowane na poziomie klastra lub w określonych przestrzeniach nazw. Określasz, jakie zasoby mogą być zarządzane i jakie uprawnienia. Następnie zastosujesz te role do użytkowników lub grup z powiązaniem. Aby uzyskać więcej informacji o rolach, rolach klastra i powiązaniach, zobacz Opcje dostępu i tożsamości dla usługi Azure Kubernetes Service (AKS).

Na przykład tworzysz rolę z pełnym dostępem do zasobów w przestrzeni nazw o nazwie finance-app, jak pokazano w poniższym przykładowym manifeście YAML:

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: finance-app-full-access-role
  namespace: finance-app
rules:
- apiGroups: [""]
  resources: ["*"]
  verbs: ["*"]

Następnie utworzysz element RoleBinding i powiążesz z nim użytkownika developer1@contoso.com Microsoft Entra, jak pokazano w następującym manifeście YAML:

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: finance-app-full-access-role-binding
  namespace: finance-app
subjects:
- kind: User
  name: developer1@contoso.com
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: finance-app-full-access-role
  apiGroup: rbac.authorization.k8s.io

Po developer1@contoso.com uwierzytelnieniu w klastrze usługi AKS mają pełne uprawnienia do zasobów w przestrzeni nazw aplikacji finansowej. W ten sposób logicznie oddzielasz i kontrolujesz dostęp do zasobów. Użyj kontroli dostępu opartej na rolach platformy Kubernetes z integracją identyfikatorów entra firmy Microsoft.

Aby dowiedzieć się, jak kontrolować dostęp do zasobów Platformy Kubernetes przy użyciu kontroli dostępu opartej na rolach w grupach firmy Microsoft przy użyciu kontroli dostępu opartej na rolach, zobacz Kontrola dostępu do zasobów klastra przy użyciu kontroli dostępu opartej na rolach i tożsamości firmy Microsoft w usłudze AKS.

Korzystanie z kontroli dostępu opartej na rolach platformy Azure

Wskazówki dotyczące najlepszych rozwiązań

Użyj kontroli dostępu opartej na rolach platformy Azure, aby zdefiniować minimalne wymagane uprawnienia użytkownika i grupy do zasobów usługi AKS w co najmniej jednej subskrypcji.

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.

Ten poziom dostępu umożliwia:
- Kontrolowanie skalowania lub uaktualniania klastra przy użyciu interfejsów API usługi AKS
- Przeciągnij plik kubeconfig.
Aby dowiedzieć się, jak kontrolować dostęp do zasobu usługi AKS i kubeconfigprogramu , zobacz Ograniczanie dostępu do pliku konfiguracji klastra.
Dostęp do interfejsu API platformy Kubernetes.

Ten poziom dostępu jest kontrolowany przez:
- Kontrola dostępu oparta na rolach platformy Kubernetes (tradycyjnie) lub
- Dzięki integracji kontroli dostępu opartej na rolach platformy Azure z usługą AKS na potrzeby autoryzacji kubernetes.
Aby dowiedzieć się, jak szczegółowo udzielać uprawnień do interfejsu API Kubernetes przy użyciu kontroli dostępu opartej na rolach platformy Azure, zobacz Używanie kontroli dostępu opartej na rolach platformy Azure na potrzeby autoryzacji na platformie Kubernetes.

Korzystanie z tożsamości zarządzanych przez zasobniki

Ostrzeżenie

Tożsamość zarządzana typu open source firmy Microsoft Entra (wersja zapoznawcza) w usłudze Azure Kubernetes Service została uznana za przestarzałą od 24.01.2022 r.

Nie używaj stałych poświadczeń w zasobnikach lub obrazach kontenerów, ponieważ są one narażone na narażenie lub nadużycie. Zamiast tego użyj tożsamości zasobników , aby automatycznie zażądać dostępu przy użyciu identyfikatora Entra firmy Microsoft.

Aby uzyskać dostęp do innych zasobów platformy Azure, takich jak Azure Cosmos DB, Key Vault lub Blob Storage, zasobnik wymaga poświadczeń uwierzytelniania. Możesz zdefiniować poświadczenia uwierzytelniania przy użyciu obrazu kontenera lub wstrzyknąć je jako wpis tajny kubernetes. Tak czy inaczej, należy ręcznie utworzyć i przypisać je. Zazwyczaj te poświadczenia są ponownie używane w zasobnikach i nie są regularnie obracane.

W przypadku tożsamości zarządzanych przez zasobniki (wersja zapoznawcza) dla zasobów platformy Azure automatycznie żądasz dostępu do usług za pośrednictwem identyfikatora Entra firmy Microsoft. Tożsamości zarządzane przez zasobniki są obecnie dostępne w wersji zapoznawczej dla usługi AKS. Zapoznaj się z dokumentacją Dotyczącą rozpoczynania pracy przy użyciu tożsamości zarządzanych przez zasobniki firmy Microsoft w usłudze Azure Kubernetes Service (wersja zapoznawcza).

Tożsamość zarządzana zasobnika firmy Microsoft (wersja zapoznawcza) obsługuje dwa tryby operacji:

Tryb standardowy : w tym trybie są wdrażane następujące 2 składniki w klastrze usługi AKS:
- Managed Identity Controller (MIC): kontroler Kubernetes, który obserwuje zmiany w zasobnikach, azureIdentity i AzureIdentityBinding za pośrednictwem serwera interfejsu API Kubernetes. Po wykryciu odpowiedniej zmiany mikrofon dodaje lub usuwa element AzureAssignedIdentity zgodnie z potrzebami. W szczególności, gdy zasobnik jest zaplanowany, mic przypisuje tożsamość zarządzaną na platformie Azure do bazowego zestawu skalowania maszyn wirtualnych używanych przez pulę węzłów w fazie tworzenia. Usunięcie wszystkich zasobników korzystających z tożsamości powoduje usunięcie tożsamości z zestawu skalowania maszyn wirtualnych puli węzłów, chyba że ta sama tożsamość zarządzana jest używana przez inne zasobniki. Mic wykonuje podobne akcje, gdy tworzone lub usuwane są identyfikatory AzureIdentityBinding lub AzureIdentityBinding.
- Tożsamość zarządzana węzła (NMI): to zasobnik, który działa jako element DaemonSet w każdym węźle w klastrze usługi AKS. Usługa NMI przechwytuje żądania tokenu zabezpieczającego do usługi Azure Instance Metadata Service w każdym węźle. Przekierowuje żądania do siebie i sprawdza, czy zasobnik ma dostęp do tożsamości, dla której żąda tokenu, i pobiera token z dzierżawy Microsoft Entra w imieniu aplikacji.
Tryb zarządzany : w tym trybie jest tylko NMI. Tożsamość musi być przypisana ręcznie i zarządzana przez użytkownika. Aby uzyskać więcej informacji, zobacz Tożsamość zasobnika w trybie zarządzanym. W tym trybie, gdy używasz polecenia az aks pod-identity add , aby dodać tożsamość zasobnika do klastra usługi Azure Kubernetes Service (AKS), tworzy klaster AzureIdentity i AzureIdentityBinding w przestrzeni nazw określonej przez --namespace parametr, podczas gdy dostawca zasobów usługi AKS przypisuje tożsamość zarządzaną określoną przez --identity-resource-id parametr do zestawu skalowania maszyn wirtualnych każdej puli węzłów w klastrze usługi AKS.

Uwaga

Jeśli zamiast tego zdecydujesz się zainstalować tożsamość zarządzaną zasobnika firmy Microsoft przy użyciu dodatku klastra usługi AKS, instalator korzysta z managed trybu .

Tryb managed zapewnia następujące korzyści w porównaniu z elementem standard:

Przypisanie tożsamości w zestawie skalowania maszyn wirtualnych puli węzłów może potrwać od 40 do 60. W przypadku zadań cronjob lub aplikacji, które wymagają dostępu do tożsamości i nie mogą tolerować opóźnienia przypisania, najlepiej użyć managed trybu, ponieważ tożsamość jest wstępnie przypisana do zestawu skalowania maszyn wirtualnych puli węzłów. Ręcznie lub za pomocą polecenia az aks pod-identity add .
W standard trybie mikrofon wymaga uprawnień do zapisu w zestawie skalowania maszyn wirtualnych używanych przez klaster usługi AKS i Managed Identity Operator uprawnieniach do tożsamości zarządzanych przypisanych przez użytkownika. W przypadku uruchamiania w programie managed mode, ponieważ nie ma mikrofonu, przypisania ról nie są wymagane.

Zamiast ręcznie definiować poświadczenia dla zasobników, tożsamości zarządzane przez zasobniki żądają tokenu dostępu w czasie rzeczywistym, używając go do uzyskiwania dostępu tylko do przypisanych zasobów. W usłudze AKS istnieją dwa składniki obsługujące operacje umożliwiające zasobnikom korzystanie z tożsamości zarządzanych:

Serwer tożsamości zarządzania węzłem (NMI) to zasobnik, który działa jako element DaemonSet w każdym węźle w klastrze usługi AKS. Serwer NMI nasłuchuje żądań zasobników do usług platformy Azure.
Dostawca zasobów platformy Azure wysyła zapytanie do serwera interfejsu API Kubernetes i sprawdza mapowanie tożsamości platformy Azure odpowiadające zasobnikowi.

Gdy zasobniki żądają tokenu zabezpieczającego z identyfikatora Entra firmy Microsoft w celu uzyskania dostępu do zasobu platformy Azure, reguły sieciowe przekierowują ruch do serwera NMI.

Serwer NMI:
- Identyfikuje zasobniki żądające dostępu do zasobów platformy Azure na podstawie ich adresu zdalnego.
- Wysyła zapytanie do dostawcy zasobów platformy Azure.
Dostawca zasobów platformy Azure sprawdza mapowania tożsamości platformy Azure w klastrze usługi AKS.
Serwer NMI żąda tokenu dostępu z identyfikatora Entra firmy Microsoft na podstawie mapowania tożsamości zasobnika.
Identyfikator Entra firmy Microsoft zapewnia dostęp do serwera NMI, który jest zwracany do zasobnika.
- Ten token dostępu może służyć przez zasobnik do żądania dostępu do zasobów na platformie Azure.

W poniższym przykładzie deweloper tworzy zasobnik, który używa tożsamości zarządzanej do żądania dostępu do usługi Azure SQL Database:

Pod identities allow a pod to automatically request access to other resources.

Operator klastra tworzy konto usługi do mapowania tożsamości, gdy zasobniki żądają dostępu do zasobów.
Serwer NMI jest wdrażany w celu przekazywania wszystkich żądań zasobników wraz z dostawcą zasobów platformy Azure na potrzeby tokenów dostępu do identyfikatora Entra firmy Microsoft.
Deweloper wdraża zasobnik z tożsamością zarządzaną, która żąda tokenu dostępu za pośrednictwem serwera NMI.
Token jest zwracany do zasobnika i używany do uzyskiwania dostępu do usługi Azure SQL Database

Aby użyć tożsamości zarządzanych przez zasobniki, zobacz Use Microsoft Entra pod-managed identities in Azure Kubernetes Service (preview) (Używanie tożsamości zarządzanych przez pod firmy Microsoft w usłudze Azure Kubernetes Service (wersja zapoznawcza).

Następne kroki

Ten artykuł z najlepszymi rozwiązaniami koncentruje się na uwierzytelnianiu i autoryzacji dla klastra i zasobów. Aby zaimplementować niektóre z tych najlepszych rozwiązań, zobacz następujące artykuły:

Aby uzyskać więcej informacji na temat operacji klastra w usłudze AKS, zobacz następujące najlepsze rozwiązania:

Share via