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.
Dotyczy: ✔️ AKS Automatic AKS Standard ✔️
AKS używa tożsamości w pięciu odrębnych scenariuszach. Każdy scenariusz odpowiada na inne pytanie i ma własny model konfiguracji.
W przypadku większości produkcyjnych obciążeń AKS zalecanym wyborem domyślnym jest AKS Automatic, ponieważ bazuje on na gotowej do wdrożenia produkcyjnego konfiguracji bazowej platformy, w tym na ustawieniach domyślnych związanych z tożsamością, przy jednoczesnym zachowaniu tego samego modelu tożsamości AKS opisanego w tym artykule.
Ten artykuł zawiera krótkie wprowadzenie do każdego scenariusza, wyjaśnia, jak zalecenia odnoszą się do usług AKS Automatic i AKS Standard, oraz odsyła do szczegółowej dokumentacji.
Pięć scenariuszy tożsamości w usłudze AKS
| Scenario | Pytanie, na które odpowiedziano | Dokumentacja dogłębna |
|---|---|---|
| Odp. Uwierzytelnianie warstwy kontrolnej Kubernetes | Kto jest dzwoniącym, który wywołuje interfejs API platformy Kubernetes? | Pojęcia dotyczące uwierzytelniania klastra, zewnętrzni dostawcy tożsamości |
| B. Autoryzacja warstwy kontrolnej Kubernetes | Co może zrobić wywołujący po uwierzytelnieniu się w API Kubernetes? | Pojęcia dotyczące autoryzacji klastra |
| C. Autoryzacja zasobów usługi AKS (Azure Resource Manager) | Kto może wykonywać operacje na poziomie platformy Azure w zasobie AKS, takie jak ściąganie kubeconfig? |
Ograniczanie dostępu do pliku konfiguracji klastra, wbudowanych ról platformy Azure |
| D. Tożsamość klastra (klaster → Azure) | Jak klaster usługi AKS działa na platformie Azure, aby zarządzać zasobami w Twoim imieniu? | Tożsamości zarządzane w usłudze AKS |
| E. Tożsamość obciążenia roboczego (pod → Azure) | Jak pody są uwierzytelniane w usługach platformy Azure, takich jak Key Vault lub Storage? | Omówienie identyfikatora obciążenia Entra firmy Microsoft |
Poziom bezpieczeństwa tożsamości w usłudze AKS Automatic i AKS Standard
Pięć scenariuszy tożsamości w tym artykule dotyczy zarówno usługi AKS Automatic, jak i AKS Standard. Główną różnicą jest sposób działania:
- Usługa AKS Automatic zapewnia więcej wstępnie skonfigurowanych ustawień domyślnych tożsamości i zabezpieczeń.
- Usługa AKS Standard zapewnia większą kontrolę ręczną i wymaga większej liczby opcji konfiguracji.
Użyj usługi AKS Automatic jako domyślnego punktu wyjścia dla większości obciążeń produkcyjnych i użyj usługi AKS Standard, gdy potrzebujesz bardziej szczegółowej niestandardowej konfiguracji platformy.
Aby uzyskać omówienie usługi AKS Automatic, zobacz Wprowadzenie do usługi Azure Kubernetes Service (AKS) Automatic.
Porównanie konfiguracji tożsamości w usługach AKS Automatic i AKS Standard
| Obszar tożsamości | Automatyczna pozycja AKS | Standardowy poziom zabezpieczeń AKS | Learn more |
|---|---|---|---|
| Uwierzytelnianie interfejsu API platformy Kubernetes | Domyślne ustawienia przeznaczone do środowisk produkcyjnych z integracją Microsoft Entra jako zalecanym modelem | Konfigurowalne, w tym konta lokalne i opcje integracji Entra | Pojęcia dotyczące uwierzytelniania klastra |
| Autoryzacja interfejsu API platformy Kubernetes | Usługa Azure RBAC na potrzeby autoryzacji w Kubernetes jest prekonfigurowana | Model preferujący konta lokalne i autoryzację wybrany przez konfigurację klastra | Pojęcia dotyczące autoryzacji klastra |
| Autoryzacja zasobów usługi AKS | Używa standardowego modelu Azure RBAC na zasobach AKS | Korzysta ze standardowego modelu RBAC platformy Azure w operacjach na zasobach AKS | Kontrolowanie dostępu do narzędzia kubeconfig |
| Tożsamość klastra | Używa modelu tożsamości zarządzanej z domyślnymi ustawieniami bazowymi dla środowiska produkcyjnego | Używa modelu tożsamości zarządzanej z wybraną przez operatora konfiguracją | Tożsamości zarządzane w usłudze AKS |
| Tożsamość zadania | Tożsamość obciążenia i wystawca OIDC zostały wstępnie skonfigurowane | Opcjonalne i konfigurowane przez operatora | Przegląd tożsamości obciążeń |
Pozostała część tego artykułu zawiera krótką orientację dla każdego scenariusza.
Odp. Uwierzytelnianie warstwy kontrolnej Kubernetes
Uwierzytelnianie płaszczyzny sterowania kubernetes ustanawia tożsamość użytkownika lub jednostki usługi wywołującej serwer interfejsu API Kubernetes. AKS obsługuje:
- Microsoft Entra ID (zalecane): użyj tożsamości i grup Entra ID, aby zalogować się do klastra. Integracja firmy Microsoft Entra aprowizuje i obraca integrację w Twoim imieniu. Aby włączyć, zobacz Korzystanie z integracji z firmą Microsoft Entra.
- Konta lokalne: wbudowany certyfikat administratora klastra, który pomija Entra ID. Zalecamy wyłączenie kont lokalnych w środowisku produkcyjnym. Zobacz Zarządzanie kontami lokalnymi.
- Zewnętrzni dostawcy tożsamości: użyj dostawcy tożsamości zgodnego ze standardem OIDC innego niż Microsoft Entra ID. Zobacz Uwierzytelnianie zewnętrznego dostawcy tożsamości.
W przypadku większości obciążeń produkcyjnych zacznij od AKS Automatic i integracji z Microsoft Entra.
Aby uzyskać szczegółowe informacje na temat sposobu uwierzytelniania żądań interfejsu API kubernetes w usłudze AKS, zobacz Pojęcia dotyczące uwierzytelniania klastra.
B. Autoryzacja warstwy kontrolnej Kubernetes
Po uwierzytelnieniu obiektu wywołującego w interfejsie API platformy Kubernetes usługa AKS autoryzuje żądanie przy użyciu jednego (lub obu) dwóch modeli:
-
Kubernetes RBAC: natywny dla Kubernetes model
Role,ClusterRoleiRoleBinding, oceniany przez serwer API. Uprawnienia występują w klastrze jako obiekty Kubernetes. -
Autoryzacja Microsoft Entra ID: element webhook autoryzacji platformy AKS deleguje decyzje o autoryzacji do usługi Microsoft Entra ID przy użyciu przypisań ról platformy Azure. Przypisania ról RBAC Azura z usługą
dataActionssą obsługiwane dla wszystkich standardowych zasobów interfejsu API Kubernetes, a przypisania ról z warunkami Azure ABAC są obsługiwane dla zasobów niestandardowych. Centralnie zarządzaj uprawnieniami w usłudze Microsoft Entra ID, aby kontrolować wiele klastrów za pomocą jednego przypisania roli na poziomie subskrypcji, grupy zarządzania lub grupy zasobów.
W usłudze AKS Automatic kontrola dostępu oparta na rolach platformy Azure (Azure RBAC) na potrzeby autoryzacji w Kubernetes jest wstępnie skonfigurowana w ramach domyślnej konfiguracji gotowej do użycia produkcyjnego.
Aby zapoznać się z porównaniem i wskazówkami dotyczącymi tego, kiedy używać każdego modelu, zobacz Pojęcia dotyczące autoryzacji klastra.
C. Autoryzacja zasobów usługi AKS (Azure Resource Manager)
Oprócz autoryzowania wywołań interfejsu API Kubernetes należy również autoryzować operacje na poziomie platformy Azure w samym zasobie usługi AKS. Najczęstszym przykładem jest kontrolowanie, kto może zarządzać klastrem kubeconfig, czyli autonomiczną operacją Azure Resource Manager, którą można szczegółowo zarządzać za pomocą kontroli dostępu opartej na rolach Azure RBAC. Ta operacja korzysta ze standardowego mechanizmu kontroli dostępu opartego na rolach platformy Azure (Azure RBAC) w odniesieniu do dostawcy zasobów Microsoft.ContainerService, jest niezależna od autoryzacji interfejsu API platformy Kubernetes i ma takie samo zastosowanie do AKS Automatic i AKS Standard. Aby uzyskać więcej informacji, zobacz Ograniczanie dostępu do pliku konfiguracji klastra oraz role wbudowane opisane w artykule Role wbudowane platformy Azure.
D. Tożsamość klastra (klaster → Azure)
Klastry usługi AKS używają tożsamości zarządzanych platformy Azure do działania na zasobach platformy Azure w Twoim imieniu — na przykład do tworzenia modułów równoważenia obciążenia, dołączania dysków lub ściągania obrazów z usługi Azure Container Registry. Główne tożsamości to:
- Tożsamość płaszczyzny sterowania: używana przez płaszczyznę sterowania klastra do zarządzania zasobami Azure dla klastra.
- Tożsamość kubelet: używana przez kubelet na każdym węźle do uwierzytelniania się w usługach, takich jak Azure Container Registry.
- Tożsamość dodatków/rozszerzeń: niektóre dodatki i rozszerzenia usługi AKS używają własnych tożsamości zarządzanych.
Usługa AKS Automatic utrzymuje ten sam model tożsamości, jednocześnie zmniejszając problemy z konfiguracją dzięki wstępnie skonfigurowanym domyślnym wartościom produkcyjnym.
Aby uzyskać szczegółowe informacje na temat poszczególnych typów tożsamości i sposobu używania tożsamości przypisanych przez system i tożsamości przypisanych przez użytkownika, zobacz Tożsamości zarządzane w usłudze AKS.
E. Tożsamość obciążenia roboczego (pod → Azure)
Tożsamość zasobów obciążenia pozwala na to, aby pody działające na klasterze AKS uwierzytelniały się w usługach platformy Azure, chronionych przez Microsoft Entra (takich jak Azure Key Vault, Azure Storage czy Cosmos DB), bez potrzeby przechowywania sekretów w klastrze. Usługa AKS używa Tożsamość obciążeń Microsoft Entra, który projektuje sfederowany token konta usługi Kubernetes do aplikacji Microsoft Entra lub przypisanej użytkownikowi tożsamości zarządzanej.
Usługa AKS Automatic obejmuje tożsamość obciążenia i wystawcę OIDC jako wstępnie skonfigurowane wartości domyślne. W usłudze AKS Standard te możliwości są opcjonalne i konfigurowane przez operatora.
Nie używaj przestarzałej tożsamości zarządzanej przez zasobniki Microsoft Entra dla nowych zadań.
Przewodnik po decyzjach
| Goal | Użyj tych dokumentów |
|---|---|
| Zacznij od bazowego poziomu tożsamości gotowego do użycia w środowisku produkcyjnym dla większości obciążeń | Wprowadzenie do usługi AKS Automatic |
| Logowanie użytkowników do klastra przy użyciu identyfikatora Entra firmy Microsoft | Włączanie integracji z firmą Microsoft Entra |
| Zarządzanie tym, kto może wykonywać zadania w interfejsie API platformy Kubernetes w wielu klastrach | Używanie autoryzacji Microsoft Entra ID dla interfejsu API Kubernetes |
| Ograniczanie dostępu do określonych niestandardowych typów zasobów | Warunki ABAC w autoryzacji Identyfikatora Entra |
| Nadawaj uprawnienia specyficzne dla klastra i przestrzeni nazw jako obiekty Kubernetes | Użyj kontroli dostępu opartej na rolach (RBAC) platformy Kubernetes z integracją Entra |
| Pozwól klastrowi pobierać z ACR lub przymocować dyski | Tożsamości zarządzane w usłudze AKS |
| Zezwalaj podom na dostęp do usługi Key Vault lub magazynu bez użycia wpisów tajnych. | Omówienie identyfikatora obciążenia Entra firmy Microsoft |
Ogranicz, kto może pobrać klaster kubeconfig |
Ograniczanie dostępu do pliku konfiguracji klastra |
| Utwórz klaster produkcyjny z domyślną konfiguracją tożsamości | Utwórz klaster automatyczny AKS |
Dokumentacja uprawnień usługi AKS
Informacje o uprawnieniach platformy Azure używanych przez usługę AKS (tożsamości tworzącej klaster, tożsamości klastra w czasie wykonywania, dodatkowych uprawnieniach tożsamości klastra oraz dostępie AKS do węzłów) znajdziesz w dokumencie Informacje o uprawnieniach usługi AKS.
Treści powiązane
- Wprowadzenie do Azure Kubernetes Service (AKS) Automatic
- Tworzenie klastra automatycznego Azure Kubernetes Service (AKS)
- Pojęcia dotyczące uwierzytelniania klastra
- Pojęcia dotyczące autoryzacji klastra
- Używanie autoryzacji Microsoft Entra ID dla interfejsu API Kubernetes
- Tożsamości zarządzane w usłudze AKS
- Omówienie identyfikatora obciążenia Entra firmy Microsoft
Aby uzyskać więcej informacji na temat podstawowych pojęć związanych z platformą Kubernetes i usługą AKS, zobacz następujące artykuły: