Pojęcia dotyczące uwierzytelniania klastra w usłudze Azure Kubernetes Service (AKS)

W tym artykule opisano, jak usługa Azure Kubernetes Service (AKS) uwierzytelnia osoby wywołujące interfejs API Kubernetes — czyli kto może nawiązać połączenie z płaszczyzną sterowania. Obejmuje ona zalecaną ścieżkę uwierzytelniania opartą na usłudze Microsoft Entra ID oraz sposób zabezpieczania dostępu awaryjnego.

Aby dowiedzieć się, jak usługa AKS ocenia, co może zrobić uwierzytelniony obiekt wywołujący, zobacz Pojęcia dotyczące autoryzacji klastra.

W przypadku innych scenariuszy tożsamości w usłudze AKS, zapoznaj się z:

  • Tożsamości zarządzane w usłudze AKS dla dostępu klastrów do platformy Azure (na przykład pobierania obrazów z usługi ACR lub dołączania dysków).
  • Przegląd Microsoft Entra Workload ID dla dostępu od pod do Azure (np. obciążenia wywołujące usługę Key Vault).

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.

Uwierzytelnij się na serwerze interfejsu API Kubernetes (control plane)

Sama platforma Kubernetes nie udostępnia katalogu tożsamości. Bez zewnętrznego dostawcy tożsamości należy zarządzać poświadczeniami lokalnymi na klaster, co nie skaluje się i tworzy luki w inspekcji.

Zalecamy wdrażanie klastrów AKS z uwierzytelnianiem Microsoft Entra ID dla płaszczyzny kontrolnej. Dzięki tej integracji klaster weryfikuje przychodzące żądania API Kubernetes względem usługi Microsoft Entra ID i używa tożsamości Entra wywołującego do podejmowania decyzji dotyczących autoryzacji. Microsoft Entra ID centralizuje warstwę tożsamości — każda zmiana stanu użytkownika lub grupy jest automatycznie odzwierciedlana w dostępie do klastra — i umożliwia dostęp warunkowy, uwierzytelnianie wieloskładnikowe i usługę Privileged Identity Management.

Diagram przedstawiający integrację firmy Microsoft z klastrami AKS na potrzeby uwierzytelniania.

Aby uzyskać informacje o konfiguracji, zobacz Włącz uwierzytelnianie Microsoft Entra ID dla płaszczyzny sterowania usługi AKS. Należy zwrócić uwagę na następujące kwestie:

  • Dzierżawa Microsoft Entra skonfigurowana do uwierzytelniania klastra musi być taka sama jak dzierżawa subskrypcji, która zawiera klaster AKS.
  • W przypadku logowania nieinterakcyjnego lub starszych kubectl wersji użyj wtyczki kubelogin .

Zewnętrzni dostawcy tożsamości (wersja zapoznawcza)

Niektóre organizacje muszą uwierzytelniać użytkowników klastra za pomocą dostawcy tożsamości zgodnego ze standardem OIDC, innego niż Microsoft Entra ID — na przykład GitHub, Google Workspace, Okta lub samodzielnie hostowany dostawca tożsamości. Usługa AKS obsługuje to poprzez uwierzytelnianie oparte na strukturze, które konfiguruje authentikatory JWT serwera API Kubernetes do weryfikacji ważności tokenów wystawionych przez dostawcę zewnętrznego.

Użyj tej opcji tylko wtedy, gdy masz twarde wymaganie, aby zachować tożsamość klastra poza identyfikatorem Entra firmy Microsoft. W przeciwnym razie preferuj ścieżkę identyfikatora Entra firmy Microsoft, aby uzyskać bogatszą integrację z dostępem warunkowym, uwierzytelnianiem wieloskładnikowym i usługą Privileged Identity Management.

Aby zapoznać się z omówieniem, zobacz External identity provider authentication for AKS clusters (Uwierzytelnianie zewnętrznego dostawcy tożsamości dla klastrów usługi AKS). Aby uzyskać informacje na temat konfiguracji, zobacz Konfigurowanie zewnętrznych dostawców tożsamości z uwierzytelnianiem strukturalnym AKS.

Wyłączanie kont lokalnych

Konta lokalne używają wbudowanego certyfikatu administratora klastra, który pomija identyfikator Entra firmy Microsoft. Każdy obiekt wywołujący, który może wyświetlić listę tych poświadczeń, uzyskuje pełny dostęp administratora klastra bez przechodzenia przez identyfikator Entra, który przerywa scentralizowaną inspekcję, dostęp warunkowy i usługę Privileged Identity Management. W środowisku produkcyjnym wyłącz konta lokalne, aby cały dostęp odbywał się za pośrednictwem Microsoft Entra ID.

Aby wymusić to na dużą skalę w wielu klastrach, przypisz wbudowaną zasadę Azure Policy klastry usługi Azure Kubernetes Service powinny mieć wyłączone lokalne metody uwierzytelniania na poziomie subskrypcji lub grupy zarządzania. Zasady audytują lub odrzucają klastry, które są tworzone lub aktualizowane z włączonymi kontami lokalnymi. Aby uzyskać pełną listę wbudowanych zasad związanych z usługą AKS, zobacz Wbudowane definicje usługi Azure Policy dla usługi AKS.

Aby uzyskać szczegółowe informacje, zobacz Zarządzanie kontami lokalnymi w usłudze AKS.

Uwierzytelnij się do węzłów klastra

Tryby dostępu SSH

Poza uwierzytelnianiem do interfejsu API platformy Kubernetes może być również konieczne uwierzytelnienie bezpośrednio w węźle za pośrednictwem protokołu SSH w celu rozwiązania problemów. Usługa AKS obsługuje trzy tryby dostępu SSH ustawione dla klastra lub puli węzłów:

  • Wyłączony protokół SSH (wersja zapoznawcza): Blokuje dostęp SSH do węzłów całkowicie. Zalecane w przypadku środowiska produkcyjnego, w którym dostęp na poziomie węzła jest możliwy tylko przez kubectl debug lub inne ścieżki natywne platformy Kubernetes.
  • Microsoft Entra ID based SSH (wersja zapoznawcza): Zaloguj się do węzłów przy użyciu tożsamości Microsoft Entra bez zarządzania kluczami SSH. Ten tryb jest zgodny z resztą uwierzytelniania klastra: dziedziczy Conditional Access i uwierzytelnianie wieloskładnikowe z Entra ID, obsługuje podnoszenie uprawnień w odpowiednim czasie za pośrednictwem Azure RBAC i usługi Privileged Identity Management oraz centralizuje inspekcję za pośrednictwem dzienników logowania Entra ID.
  • Protokół SSH użytkownika lokalnego: tradycyjny dostęp oparty na kluczach SSH. Tej opcji należy używać tylko wtedy, gdy protokół SSH oparty na identyfikatorze Entra nie jest opcją i regularnie obracaj klucze.

Aby uzyskać instrukcje konfiguracji konfiguracji poszczególnych trybów, zobacz Zarządzanie dostępem SSH w węzłach klastra usługi AKS.

Następne kroki

  • Last updated on