Tożsamość obciążenia i dostęp do platformy Kubernetes

W tym artykule opisano, jak usługa Amazon Elastic Kubernetes Service (EKS) i usługa Azure Kubernetes Service (AKS) zapewniają tożsamość obciążeń Kubernetes w celu uzyskania dostępu do usług platformy w chmurze. Aby uzyskać szczegółowe porównanie usług Amazon Web Services (AWS) Identity and Access Management (IAM) i Microsoft Entra ID, zobacz następujące zasoby:

• Zarządzanie tożsamościami Microsoft Entra oraz zarządzanie dostępem dla AWS
• Mapuj pojęcia IAM AWS do podobnych pojęć Azure

W tym przewodniku wyjaśniono, jak klastry AKS, wbudowane usługi i dodatki używają tożsamości zarządzanych do uzyskiwania dostępu do zasobów platformy Azure, takich jak moduły równoważenia obciążenia i dyski zarządzane. Pokazano również, jak używać identyfikatora obciążenia entra firmy Microsoft , aby obciążenia usługi AKS mogły uzyskiwać dostęp do zasobów platformy Azure bez konieczności używania parametrów połączenia, klucza dostępu lub poświadczeń użytkownika.

Uwaga / Notatka

Ten artykuł jest częścią serii artykułów, które ułatwiają specjalistom, którzy znają usługę Amazon EKS, rozumieją usługę Azure Kubernetes Service (AKS).

Zarządzanie tożsamościami i dostępem usługi Amazon EKS

Usługa Amazon EKS oferuje natywne opcje zarządzania tożsamościami i dostępem w zasobnikach Kubernetes. Te opcje obejmują role IAM dla kont usług i ról połączonych z usługą Amazon EKS.

Role IAM dla kont usług

Role IAM można skojarzyć z kontami usługi Kubernetes. To skojarzenie zapewnia uprawnienia platformy AWS do kontenerów w dowolnym zasobniku, który używa konta usługi. Role IAM dla kont usług zapewniają następujące korzyści:

• Najmniejsze uprawnienia: Do konta usługi można przypisać określone uprawnienia IAM, co gwarantuje, że tylko pody stosujące się do tego konta usługi mają dostęp do tych uprawnień. Ta konfiguracja eliminuje konieczność udzielania rozszerzonych uprawnień do roli IAM węzła dla wszystkich podów na węźle. Takie podejście zapewnia zwiększone zabezpieczenia i szczegółową kontrolę oraz eliminuje potrzebę rozwiązań partnerskich, takich jak kube2iam. Aby uzyskać więcej informacji, zobacz role IAM dla kont serwisowych.

• Izolacja poświadczeń: Każdy kontener w podzie może pobierać tylko poświadczenia roli IAM przypisanej do jego konkretnego konta usługi. Ta izolacja gwarantuje, że kontener nie może uzyskać dostępu do poświadczeń należących do innego kontenera w różnym podzie.

• Możliwość inspekcji: Usługa Amazon EKS używa platformy AWS CloudTrail do zapewniania dostępu i rejestrowania zdarzeń, co ułatwia retrospektywną inspekcję i zgodność.

Aby uzyskać więcej informacji, zobacz role IAM dla kont serwisowych.

Role połączone z usługą Amazon EKS

Role powiązane z usługą Amazon EKS to unikatowe role IAM, które bezpośrednio łączą się z Amazon EKS. Te wstępnie zdefiniowane role obejmują niezbędne uprawnienia do wywoływania usług AWS w imieniu skojarzonej roli. Główną rolą połączoną z usługą amazon EKS jest rola IAM węzła Amazon EKS.

Demon węzła Usługi Amazon EKS używa roli IAM węzła kubelet Amazon EKS do tworzenia wywołań interfejsu API do usług AWS w imieniu węzła. Profil instancji IAM i powiązane zasady zapewniają uprawnienia do tych wywołań API. Ta konfiguracja upraszcza zarządzanie rolami IAM dla węzłów w klastrze EKS.

Aby uzyskać więcej informacji, zobacz Role powiązane z usługą Amazon EKS.

Więcej informacji na temat zarządzania tożsamościami i dostępem

Oprócz ról IAM dla kont usług i ról połączonych z usługą Amazon EKS inne istotne aspekty zarządzania tożsamością i dostępem w usłudze Amazon EKS obejmują:

• Autoryzacja RBAC usługi Amazon EKS: Usługa Amazon EKS obsługuje kontrolę dostępu opartą na rolach (RBAC). Ta funkcja służy do definiowania precyzyjnych uprawnień dla zasobów Kubernetes w klastrze.

• AWS IAM: Zarządzanie tożsamością IAM zapewnia kompleksowe rozwiązanie dla usług AWS, w tym EKS. Użyj IAM do tworzenia i zarządzania użytkownikami, grupami i rolami, aby kontrolować dostęp do zasobów EKS.

• Grupy zabezpieczeń Amazon EKS: użyj usługi Amazon EKS, aby zastosować reguły grupy zabezpieczeń do zasobników uruchamianych w klastrze. Ta funkcja służy do kontrolowania ruchu przychodzącego i wychodzącego.

Aby uzyskać więcej informacji, zobacz Co to jest Amazon EKS?.

Zarządzane tożsamości klastra AKS

Klastry usługi AKS wymagają tożsamości firmy Microsoft Entra w celu uzyskania dostępu do zasobów platformy Azure, takich jak moduły równoważenia obciążenia i dyski zarządzane. Zalecamy używanie tożsamości zarządzanych dla zasobów platformy Azure do autoryzowania dostępu z klastra usługi AKS do innych usług platformy Azure.

Zarządzane typy tożsamości

Deweloperzy często zmagają się z zarządzaniem wpisami tajnymi, poświadczeniami, certyfikatami i kluczami, które pomagają zabezpieczyć komunikację między usługami. Tożsamości zarządzane eliminują konieczność zarządzania tymi poświadczeniami. Tożsamości zarządzane można wykorzystać do uwierzytelniania klastra usługi AKS bez zarządzania poświadczeniami lub dołączenia ich do kodu. Przypisz tożsamości rolę RBAC platformy Azure, aby przyznać jej uprawnienia do określonych zasobów na platformie Azure.

Istnieją dwa typy tożsamości zarządzanych:

• Przypisane przez system. Niektóre zasoby platformy Azure, takie jak maszyny wirtualne, umożliwiają włączenie tożsamości zarządzanej bezpośrednio w zasobie. Po włączeniu tożsamości zarządzanej przypisanej przez system:

  • Dla tożsamości jest tworzony specjalny typ jednostki usługi w usłudze Microsoft Entra ID. Zasada usługi jest powiązana z cyklem życia tego zasobu platformy Azure. Po usunięciu zasobu platformy Azure platforma Azure automatycznie usunie jednostkę usługi.

  • Tylko ten zasób platformy Azure może używać tożsamości do żądania tokenów z Microsoft Entra ID.

  • Autoryzujesz tożsamość zarządzaną, aby mieć dostęp do co najmniej jednej usługi.

  • Nazwa przypisanej przez system jednostki usługi jest taka sama jak nazwa zasobu platformy Azure, dla którego została utworzona.

• Przypisana przez użytkownika. Możesz utworzyć tożsamość zarządzaną jako autonomiczny zasób platformy Azure. Można utworzyć tożsamość zarządzaną przypisaną przez użytkownika i przypisać ją do jednego lub więcej zasobów platformy Azure. Po włączeniu tożsamości zarządzanej przypisanej przez użytkownika:

  • Dla tożsamości jest tworzony specjalny typ jednostki usługi w usłudze Microsoft Entra ID. Główny element usługi jest zarządzany oddzielnie od zasobów, które go używają.

  • Z tego może korzystać wiele zasobów.

  • Autoryzujesz tożsamość zarządzaną, aby mieć dostęp do co najmniej jednej usługi.

Aby autoryzować dostęp do zasobów platformy Azure z klastra usługi AKS, możesz użyć dowolnego typu tożsamości zarządzanej.

Więcej informacji znajdziesz w Typach tożsamości zarządzanych.

Tożsamości zarządzane w AKS

W klastrze usługi AKS można użyć następujących typów tożsamości zarządzanych:

• Tożsamość zarządzana przypisana przez system jest skojarzona z pojedynczym zasobem platformy Azure, takim jak klaster usługi AKS. Istnieje tylko na czas życia klastra.

• Tożsamość zarządzana przypisana przez użytkownika to autonomiczny zasób platformy Azure, którego można użyć do autoryzowania dostępu do innych usług platformy Azure z klastra usługi AKS. Jest ona zachowywana oddzielnie od klastra, a wiele zasobów platformy Azure może z niego korzystać.

• Wstępnie utworzona tożsamość zarządzana kubelet to opcjonalna tożsamość przypisana przez użytkownika, której usługa kubelet może używać do uzyskiwania dostępu do innych zasobów na platformie Azure. Jeśli dla kubeleta nie określono tożsamości zarządzanej przypisanej przez użytkownika, usługa AKS tworzy tożsamość kubelet przypisaną przez użytkownika w grupie zasobów węzła.

Konfigurowanie zarządzanych tożsamości dla klastrów AKS

Podczas wdrażania klastra usługi AKS zostanie automatycznie utworzona tożsamość zarządzana przypisana przez system. Możesz także utworzyć klaster z przypisaną przez użytkownika zarządzaną tożsamością. Klaster używa tożsamości zarządzanej do żądania tokenów z identyfikatora Entra firmy Microsoft. Tokeny autoryzują dostęp do innych zasobów działających w platformie Azure.

Po przypisaniu roli RBAC platformy Azure do tożsamości zarządzanej możesz przyznać klastrowi uprawnienia dostępu do określonych zasobów. Można na przykład przypisać tożsamość zarządzaną rolę RBAC platformy Azure, która umożliwia jej dostęp do sekretów w magazynie kluczy Azure. Użyj tego podejścia, aby łatwo autoryzować dostęp do klastra bez zarządzania poświadczeniami.

Korzyści i zarządzanie tożsamościami zarządzanymi w usłudze AKS

W przypadku korzystania z tożsamości zarządzanych w serwisie AKS nie trzeba aprowizować ani aktualizować tajnych danych. Platforma Azure zarządza poświadczeniami tożsamości. W związku z tym możesz udzielać autoryzacji dostępu z poziomu aplikacji bez zarządzania dodatkowymi hasłami.

Jeśli masz już klaster usługi AKS korzystający z tożsamości zarządzanej, możesz zaktualizować klaster do innego typu tożsamości zarządzanej. Jednak ta aktualizacja może spowodować opóźnienie, gdy składniki płaszczyzny sterowania przełączą się do nowej tożsamości. Ten proces może zająć kilka godzin. W tym czasie składniki płaszczyzny sterowania nadal używają starej tożsamości do momentu wygaśnięcia tokenu.

Typy tożsamości zarządzanych w AKS

Usługa AKS używa różnych typów tożsamości zarządzanych do włączania różnych wbudowanych usług i dodatków.

Tożsamość zarządzana	Przypadek użycia	Uprawnienia domyślne
Płaszczyzna sterowania (przypisana przez system)	Składniki planu kontroli usługi AKS korzystają z tej tożsamości do zarządzania zasobami klastra. Te zasoby obejmują równoważniki obciążenia dla ruchu przychodzącego, publiczne adresy IP zarządzane przez usługę AKS, autoskalowanie klastra oraz dyski, pliki i sterowniki CSI dla obiektów blob platformy Azure.	Rola współautora dla grupy zasobów węzła
Kubelet (przypisany przez użytkownika)	Uwierzytelnianie za pomocą usługi Azure Container Registry.	N/A (dla platformy Kubernetes w wersji 1.15 lub nowszej)
Tożsamości dodatków (AzureNPM, monitorowanie sieci AzureCNI, Azure Policy i Calico)	Te dodatki nie wymagają tożsamości.	N/A
Marszruta zgłoszenia	Zarządza certyfikatami usług Azure DNS i Azure Key Vault.	Rola użytkownika wpisów tajnych usługi Key Vault dla usługi Key Vault, rola Współautor strefy DNS dla stref DNS, rola Współautor prywatnej strefy DNS dla prywatnych stref DNS
Bramka aplikacji Ingress	Zarządza wymaganymi zasobami sieciowymi.	Rola współautora dla grupy zasobów węzła
Agent pakietu Operations Management Suite (OMS)	Wysyła metryki usługi AKS do usługi Azure Monitor.	Rola publikującego metryki monitorowania
Węzeł wirtualny (konektor Azure Container Instances)	Zarządza wymaganymi zasobami sieciowymi dla usługi Container Instances.	Rola współautora dla grupy zasobów węzła
Analiza kosztów	Zbiera dane alokacji kosztów.	N/A
Tożsamość zadania (ID zadania)	Umożliwia aplikacjom bezpieczny dostęp do zasobów w chmurze przy użyciu identyfikatora obciążenia.	N/A

Aby uzyskać więcej informacji, zobacz Używanie tożsamości zarządzanej w usłudze AKS.

Identyfikator obciążenia dla platformy Kubernetes

Workload ID integruje się z platformą Kubernetes, aby obciążenia wdrożone w klastrze AKS mogły uzyskiwać dostęp do zasobów chronionych przez Microsoft, takich jak Key Vault i Microsoft Graph. Identyfikator obciążenia używa natywnych funkcji platformy Kubernetes do federacji z zewnętrznymi dostawcami tożsamości. Aby uzyskać więcej informacji, zobacz Używanie identyfikatora obciążenia z usługą AKS.

Aby użyć identyfikatora obciążenia, skonfiguruj konto usługi w ramach platformy Kubernetes. Zasobniki używają tego konta usługi do bezpiecznego uwierzytelniania zasobów platformy Azure i uzyskiwania do nich dostępu. Identyfikator obciążenia działa dobrze z bibliotekami klienta usług tożsamości platformy Azure lub kolekcją Biblioteki uwierzytelniania firmy Microsoft. Musisz zarejestrować aplikację w usłudze Microsoft Entra ID, aby zarządzać uprawnieniami i kontrolą dostępu dla tożsamości.

Aby w pełni stosować identyfikator obciążenia w klastrze Kubernetes, skonfiguruj klaster usługi AKS pod kątem wystawiania tokenów i publikowania dokumentu odnajdywania OpenID Connect (OIDC) na potrzeby walidacji tokenu. Aby uzyskać więcej informacji, zobacz Tworzenie dostawcy OIDC w usłudze AKS.

Należy również skonfigurować aplikacje firmy Microsoft Entra, aby ufały tokenom kubernetes. Deweloperzy mogą następnie skonfigurować wdrożenia tak, aby korzystały z kont usługi Kubernetes w celu uzyskania tokenów. Identyfikator obciążenia wymienia tokeny na tokeny Microsoft Entra. Obciążenia klastra usługi AKS mogą używać tych tokenów firmy Microsoft Entra do bezpiecznego uzyskiwania dostępu do chronionych zasobów na platformie Azure.

Na poniższym diagramie pokazano, jak klaster Kubernetes staje się wystawcą tokenu zabezpieczającego, który wystawia tokeny na kontach usługi Kubernetes. Te tokeny można skonfigurować tak, aby były zaufane w aplikacjach firmy Microsoft Entra. Tokeny można następnie wymieniać na tokeny dostępu Microsoft Entra za pośrednictwem zestawów SDK usług tożsamości platformy Azure lub Microsoft Authentication Library.

Diagram sekwencji przedstawia interakcję między pięcioma składnikami: kubeletem, obciążeniem Kubernetes, identyfikatorem Microsoft Entra ID, dokumentem odnajdywania OpenID i zasobami platformy Azure. Interakcje są numerowane z zakresu od 1 do 5. Strzałki wskazują kierunek komunikacji. Strzałka od Kubelet do obciążenia Kubernetes ma etykietę 1. Strzałka oznaczona '2' prowadzi od zasobu Kubernetes do usługi Microsoft Entra ID. Strzałka z Microsoft Entra ID do dokumentu odkrycia OpenID ma etykietę 3. Strzałka z identyfikatora Entra firmy Microsoft z powrotem do obciążenia Kubernetes ma etykietę 4. Strzałka od obciążenia Kubernetes do zasobów Azure jest oznaczona jako 5.

1. Agent kubelet przekazuje token konta usługi do zadania w określonej ścieżce pliku.

2. Zadanie Kubernetes wysyła przewidziany i podpisany token konta usługi do Microsoft Entra ID i żąda tokenu dostępu.

3. Microsoft Entra ID używa dokumentu wykrywania OIDC do potwierdzania zaufania w zarządzanej tożsamości zdefiniowanej przez użytkownika lub zarejestrowanej aplikacji oraz do weryfikacji przychodzącego tokena.

4. Microsoft Entra ID wystawia token dostępu zabezpieczeń.

5. Obciążenie Kubernetes uzyskuje dostęp do zasobów platformy Azure za pośrednictwem tokenu dostępu firmy Microsoft Entra.

Aby uzyskać więcej informacji na temat identyfikatora obciążenia, zobacz następujące zasoby:

• Projekt open source identyfikatora obciążenia
• Federacja tożsamości obciążeniowej
• Federacja identyfikatora obciążenia z platformą Kubernetes
• Federacja identyfikatorów obciążeń z zewnętrznymi dostawcami tożsamości OIDC
• Minimalna federacja identyfikatorów obciążenia pracą
• Dokumentacja identyfikatora obciążenia
• Identyfikator obciążenia — szybki start
• Używanie identyfikatora obciążenia dla platformy Kubernetes z tożsamością zarządzaną przypisaną przez użytkownika w aplikacji .NET Standard

Przykładowe obciążenie

Poniższe przykładowe obciążenie działa w klastrze usługi AKS i składa się z frontonu i usługi zaplecza. Te usługi używają identyfikatora obciążenia do uzyskiwania dostępu do usług platformy Azure, w tym usługi Key Vault, Azure Cosmos DB, kont usługi Azure Storage i przestrzeni nazw usługi Azure Service Bus. Aby skonfigurować to przykładowe obciążenie, wykonaj następujące wymagania wstępne:

1. Skonfiguruj klaster usługi AKS z włączonym wystawcą OIDC i tożsamością obciążenia .

2. Utwórz konto usługi Kubernetes w przestrzeni nazw obciążenia.

3. Utwórz zarządzaną tożsamość przypisaną przez użytkownika lub zarejestrowaną aplikację w Microsoft Entra.

4. Ustanów poświadczenia tożsamości federacyjnej między zarządzaną tożsamością Microsoft Entra lub zarejestrowaną aplikacją a kontem usługi obciążenia roboczego.

5. Przypisz niezbędne role z odpowiednimi uprawnieniami do zarządzanej tożsamości Microsoft Entra lub zarejestrowanej aplikacji.

6. Wdróż obciążenie i zweryfikuj uwierzytelnianie przy użyciu tożsamości obciążenia.

Przepływ komunikatów o identyfikatorze obciążenia

W tym przykładowym obciążeniu aplikacje front-end i back-end uzyskują tokeny zabezpieczające Microsoft Entra, aby uzyskać dostęp do rozwiązań platformy Azure w modelu PaaS (platforma jako usługa). Na poniższym diagramie przedstawiono przepływ komunikatów.

Główną sekcją jest konfiguracja klastra usługi AKS, która obejmuje kontroler ruchu przychodzącego NGINX oraz przestrzeń nazw todolist i jego składniki. Kontenery wdrażania wskazują krok 1 w ogólnym przepływie pracy. Usługa Flow 2 przechodzi z kontenerów wdrażania do identyfikatora Entra firmy Microsoft. Flow 3 przechodzi z Microsoft Entra ID do adresu URL wystawcy OIDC. Flow 4 jest przesyłany z Microsoft Entra ID do kontenerów wdrożeniowych. Usługa Flow 5 przechodzi z kontenerów wdrażania do usługi Azure Key Vault, usługi Azure Service Bus, usługi Azure Cosmos DB i konta usługi Azure Storage.

Pobierz plik programu Visio tej architektury.

1. Platforma Kubernetes wystawia token zasobnikowi, gdy zasobnik jest zaplanowany w węźle. Ten token oparty jest na specyfikacjach zasobnika lub wdrożenia.

2. Zasobnik wysyła token OIDC do Microsoft Entra ID, aby zażądać tokenu Entra ID Microsoft dla określonego zasobu i appId.

3. Identyfikator entra firmy Microsoft weryfikuje zaufanie w aplikacji i weryfikuje token przychodzący.

4. Identyfikator entra firmy Microsoft wystawia token zabezpieczający: {sub: appId, aud: requested-audience}.

5. Pod używa tokenu Microsoft Entra do uzyskania dostępu do docelowego zasobu platformy Azure.

Aby użyć kompleksowego identyfikatora obciążenia w klastrze Kubernetes:

1. Skonfiguruj klaster usługi AKS tak, aby wystawiał tokeny i publikował dokument odnajdywania OIDC, aby umożliwić walidację tych tokenów.

2. Skonfiguruj aplikacje firmy Microsoft Entra, aby ufały tokenom kubernetes.

3. Deweloperzy konfigurują swoje wdrożenia, aby uzyskiwać tokeny kubernetes przy użyciu kont usługi Kubernetes.

4. Identyfikator zadania roboczego wymienia tokeny Kubernetes na tokeny Microsoft Entra.

5. Obciążenia klastrów AKS używają tokenów Microsoft Entra do uzyskiwania dostępu do chronionych zasobów, takich jak Microsoft Graph.

Współautorzy

Firma Microsoft utrzymuje ten artykuł. Następujący współautorzy napisali ten artykuł.

Główni autorzy:

• Paolo Salvatori | Główny inżynier usługi
• Martin Gjoszewski | Starszy inżynier ds. usług

Inni współautorzy:

• Laura Nicolas | Starszy inżynier oprogramowania
• Chad Kittel | Główny inżynier oprogramowania — wzorce i praktyki dotyczące platformy Azure
• Ed Price | Starszy menedżer ds. programu treści
• Theano Petersen | Autor techniczny

Aby wyświetlić niepubliczne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.

Dalsze kroki

• Używanie jednostki usługi z usługą AKS
• Użyj tożsamości zarządzanej w AKS
• Ścieżka szkoleniowa: zarządzanie tożsamościami i dostępem w identyfikatorze Entra firmy Microsoft

Powiązane zasoby

• AKS dla specjalistów Amazon EKS
• Monitorowanie i rejestrowanie na platformie Kubernetes
• Bezpieczny dostęp sieciowy do Kubernetes
• Opcje magazynu dla klastra Kubernetes
• Zarządzanie kosztami dla platformy Kubernetes
• Zarządzanie węzłami i pulami węzłów Kubernetes
• Nadzór nad klastrem
• Zarządzanie tożsamościami Microsoft Entra oraz zarządzanie dostępem dla AWS