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

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:

Korzystanie z identyfikatora Entra firmy Microsoft

Wskazówki dotyczące najlepszych rozwiązań

Wdrażanie klastrów AKS z integracją 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 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.

Tworząc zintegrowane klastry Microsoft Entra 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 Kubernetes RBAC w następnej sekcji. Integracja firmy Microsoft Entra i sposób kontrolowania dostępu do zasobów można zobaczyć na poniższym diagramie:

1. Deweloper uwierzytelnia się za pomocą identyfikatora Entra firmy Microsoft.
2. Punkt końcowy wystawiania tokenu firmy Microsoft Entra wystawia token dostępu.
3. Deweloper wykonuje akcję przy użyciu tokenu Microsoft Entra, takiego jak kubectl create pod.
4. Platforma Kubernetes weryfikuje token za pomocą Microsoft Entra ID i pobiera członkostwo dewelopera w grupach.
5. Na platformie Kubernetes stosowane są zasady RBAC i polityki klastra.
6. Żądanie dewelopera zakończyło się pomyślnie na podstawie uprzedniej walidacji członkostwa w grupie Microsoft Entra oraz kontroli dostępu opartej na rolach (RBAC) platformy Kubernetes i polityk.

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

Korzystaj z kontroli dostępu opartej na rolach (RBAC) w Kubernetes.

Wskazówki dotyczące najlepszych rozwiązań

Zdefiniuj uprawnienia użytkownika lub grupy do zasobów klastra za pomocą RBAC w 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. Decydujesz, jakie zasoby mogą być zarządzane i z jakimi uprawnieniami. Następnie zastosujesz te role do użytkowników lub grup poprzez powiązanie. 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 uwierzytelnieniu developer1@contoso.com w klastrze AKS mają pełne uprawnienia do zasobów w przestrzeni nazw finance-app. W ten sposób logicznie oddzielasz i kontrolujesz dostęp do zasobów. Użyj RBAC Kubernetes z integracją Microsoft Entra ID.

Aby dowiedzieć się, jak używać grup Microsoft Entra do kontrolowania dostępu do zasobów Kubernetes przy użyciu kontroli dostępu opartej na rolach (RBAC), zobacz Kontrola dostępu do zasobów klastra przy użyciu kontroli dostępu opartej na rolach i tożsamości Microsoft Entra w usłudze AKS.

Użycie Azure RBAC

Wskazówki dotyczące najlepszych rozwiązań

Użyj Azure RBAC (kontrola dostępu oparta na rolach) do zdefiniowania minimalnego zestawu wymaganych uprawnień 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 za pomocą interfejsów API AKS
  • Przeciągnij plik kubeconfig.

  Aby dowiedzieć się, jak kontrolować dostęp do zasobu usługi AKS i kubeconfig, zobacz Ograniczanie dostępu do pliku konfiguracji klastra.

• Dostęp do interfejsu API platformy Kubernetes.

  Ten poziom dostępu jest kontrolowany albo przez:

  • Kubernetes RBAC (Kontrola dostępu oparta na rolach) platformy Kubernetes (tradycyjnie) lub
  • Dzięki integracji mechanizmu kontroli dostępu opartego na rolach platformy Azure z AKS w celu 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 pody

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 zaimplementować je jako sekret Kubernetes. Tak czy inaczej, konieczne będzie ręczne utworzenie i przypisanie ich. Zazwyczaj te poświadczenia są ponownie używane w zasobnikach i nie są regularnie zmieniane.

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 pod 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).

Zarządzana tożsamość technologii Microsoft Entra (wersja zapoznawcza) obsługuje dwa tryby działania:

• 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ą AzureIdentity lub AzureIdentityBinding.

  • Tożsamość zarządzana węzła (NMI): to pod, który działa jako DaemonSet na każdym węźle w klastrze 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 samego i weryfikuje, czy pod ma dostęp do tożsamości, dla której żąda tokenu, a następnie 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 AzureIdentity i AzureIdentityBinding w przestrzeni nazw, którą określa parametr --namespace, podczas gdy dostawca zasobów usługi AKS przypisuje tożsamość zarządzaną określoną przez parametr --identity-resource-id do zestawu skalowania maszyn wirtualnych w każdej puli węzłów w klastrze usługi AKS.

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

• Przypisanie tożsamości w zestawie skalowania maszyn wirtualnych w puli węzłów może potrwać od 40 do 60 sekund. W przypadku zadań cronjobs lub aplikacji, które wymagają dostępu do tożsamości i nie mogą tolerować opóźnienia przypisania, najlepiej jest użyć trybu managed, ponieważ tożsamość jest wstępnie przypisana do zestawu skalowania maszyn wirtualnych w puli węzłów. Ręcznie lub używając polecenia az aks pod-identity add.
• W standard trybie MIC wymaga uprawnień do zapisu w zestawie skalowania maszyn wirtualnych używanym przez klaster usługi AKS oraz uprawnień do zarządzanych tożsamości 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 zgłaszają żądanie o token dostępu w czasie rzeczywistym, używając go do uzyskiwania dostępu tylko do swoich przypisanych zasobów. W usłudze AKS znajdują się dwa komponenty, które obsługują operacje, umożliwiając zasobnikom korzystanie z tożsamości zarządzanej.

• Serwer tożsamości zarządzania węzłem (NMI) to pod, który działa jako DaemonSet na każdym węźle w klastrze AKS. Serwer NMI nasłuchuje żądań podów do usług Azure.
• Dostawca zasobów Azure wysyła zapytanie do serwera interfejsu API Kubernetes i sprawdza mapowanie tożsamości 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.

1. 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.

2. Dostawca zasobów Azure sprawdza mapowania tożsamości w klastrze AKS.

3. Serwer NMI żąda tokenu dostępu od Microsoft Entra ID na podstawie odwzorowania tożsamości podu.

4. Identyfikator Entra firmy Microsoft zapewnia dostęp do serwera NMI, który jest zwracany do zasobnika.

   • Ten token dostępu może być używany przez zasobnik do żądania dostępu do zasobów w Azure.

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

1. Operator klastrowy tworzy konto serwisowe do przypisania tożsamości, gdy pody wnioskują o dostęp do zasobów.
2. Serwer NMI jest wdrażany w celu przekazywania żądań podów, wraz z dostawcą zasobów Azure, dla tokenów dostępu do Microsoft Entra ID.
3. Deweloper wdraża pod z zarządzaną tożsamością, która żąda tokenu dostępu za pośrednictwem serwera NMI.
4. 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 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:

• Integrowanie identyfikatora Entra firmy Microsoft z usługą AKS
• Użyj tożsamości zarządzanych przez zasoby Microsoft Entra w usłudze Azure Kubernetes Service (wersja zapoznawcza)

Aby uzyskać więcej informacji na temat operacji klastra w usłudze AKS, zapoznaj się z następującymi najlepszymi praktykami:

• Wielodzierżawność i izolacja klastrów
• Podstawowe funkcje harmonogramu Kubernetes
• Zaawansowane funkcje harmonogramu Kubernetes