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

W tym artykule opisano, jak usługa Amazon Elastic Kubernetes Service (Amazon 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:

• Microsoft Entra identity management and access management for AWS
• Mapowanie pojęć związanych z zarządzaniem dostępem i tożsamościami platformy AWS do podobnych na platformie Azure

W tym przewodniku wyjaśniono, jak klastry usługi 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. W tym artykule pokazano również, jak używać Tożsamość obciążeń Microsoft Entra, aby obciążenia usługi AKS mogły uzyskiwać dostęp do zasobów platformy Azure bez konieczności parametry połączenia, klucza dostępu lub poświadczeń użytkownika.

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

Usługa Amazon Elastic Kubernetes Service (EKS) udostępnia 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 dla kont usług umożliwiają kojarzenie ról IAM z kontami usługi Kubernetes. To skojarzenie zapewnia uprawnienia platformy AWS do kontenerów w dowolnym zasobniku, który korzysta z konta usługi. Korzyści wynikające z używania ról IAM dla kont usług są następujące:

• najniższych uprawnień: można przypisać określone uprawnienia zarządzania dostępem i tożsamościami do konta usługi, zapewniając, że tylko zasobniki korzystające z tego konta usługi mają dostęp do tych uprawnień. Eliminuje to konieczność udzielania rozszerzonych uprawnień do roli zarządzania dostępem i tożsamościami węzłów dla wszystkich zasobników w węźle, zapewniając bezpieczniejsze i bardziej szczegółowe podejście. Ponadto ta funkcja eliminuje konieczność korzystania z rozwiązań innych firm, takich jak kube2iam. Aby uzyskać więcej informacji, zobacz role zarządzania dostępem i tożsamościami dla kont usług.

• izolacji poświadczeń: każdy kontener w zasobniku może pobierać tylko poświadczenia roli IAM skojarzonej z odpowiednim kontem usługi. Ta izolacja gwarantuje, że kontener nie może uzyskać dostępu do poświadczeń należących do innego kontenera w innym zasobniku.

• inspekcji: usługa Amazon EKS wykorzystuje Amazon CloudTrail w celu zapewnienia dostępu i rejestrowania zdarzeń, ułatwiając inspekcję retrospektywną i zgodność.

Aby uzyskać więcej informacji na temat ról zarządzania dostępem i tożsamościami dla kont usług, zapoznaj się z oficjalną dokumentacją .

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

Połączone role usługi Amazon EKS to unikatowe role IAM bezpośrednio połączone z usługą Amazon EKS. Te wstępnie zdefiniowane role obejmują wszystkie niezbędne uprawnienia wymagane 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.

Węzeł Amazon EKS kubelet demon wykorzystuje rolę IAM węzła Amazon EKS do tworzenia wywołań interfejsu API do usług AWS w imieniu węzła. Profil wystąpienia IAM i skojarzone zasady zapewniają uprawnienia do tych wywołań interfejsu API. Ta konfiguracja upraszcza zarządzanie rolami IAM dla węzłów w klastrze EKS.

Aby dowiedzieć się więcej o rolach połączonych z usługą Amazon EKS, odwiedź oficjalną dokumentację.

Dodatkowe informacje

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

1. autoryzacji RBAC usługi Amazon EKS: usługa Amazon EKS obsługuje kontrolę dostępu opartą na rolach (RBAC), umożliwiając zdefiniowanie precyzyjnych uprawnień dla zasobów Kubernetes w klastrze.

2. usług AWS Identity and Access Management (IAM): Zarządzanie tożsamościami zapewnia kompleksowe rozwiązanie do zarządzania tożsamościami dla usług AWS, w tym EKS. Umożliwia tworzenie użytkowników, grup i ról oraz zarządzanie nimi w celu kontrolowania dostępu do zasobów EKS.

3. grupy zabezpieczeń Amazon EKS: usługa Amazon EKS umożliwia stosowanie reguł grupy zabezpieczeń do zasobników działających w klastrze w celu kontrolowania ruchu przychodzącego i wychodzącego.

Aby uzyskać więcej informacji na temat zarządzania tożsamościami i dostępem w usłudze Amazon EKS, zobacz oficjalną dokumentację usługi Amazon EKS.

Tożsamości zarządzane klastra usługi AKS

Klastry usługi Azure Kubernetes Service (AKS) wymagają tożsamości firmy Microsoft Entra uzyskiwania dostępu do zasobów platformy Azure, takich jak moduły równoważenia obciążenia i dyski zarządzane. Tożsamości zarządzane dla zasobów platformy Azure to zalecany sposób autoryzowania dostępu z klastra usługi AKS do innych usług platformy Azure.

Co to są tożsamości zarządzane?

Typowym wyzwaniem dla deweloperów jest zarządzanie wpisami tajnymi, poświadczeniami, certyfikatami i kluczami używanymi do zabezpieczania komunikacji między usługami. tożsamości zarządzane wyeliminować konieczność zarządzania tymi poświadczeniami przez deweloperów. Tożsamości zarządzane umożliwiają uwierzytelnianie klastra usługi AKS bez zarządzania poświadczeniami lub dołączania ich do kodu. Dzięki tożsamościom zarządzanym przypisujesz rolę kontroli dostępu na podstawie ról (RBAC) platformy Azure do tożsamości, udzielając jej uprawnień do określonych zasobów na platformie Azure.

Oto 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:

  • Jednostka usługi specjalnego typu jest tworzona w identyfikatorze Entra firmy Microsoft dla tożsamości. Jednostka 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.
  • Zgodnie z projektem tylko ten zasób platformy Azure może używać tej tożsamości do żądania tokenów z identyfikatora Entra firmy Microsoft.
  • Autoryzujesz tożsamość zarządzaną, aby mieć dostęp do co najmniej jednej usługi.
  • Nazwa przypisanej przez system jednostki usługi jest zawsze taka sama jak nazwa zasobu platformy Azure, dla której jest tworzona.

• przypisane przez użytkownika. Możesz również utworzyć tożsamość zarządzaną jako autonomiczny zasób platformy Azure. Możesz utworzyć tożsamość zarządzaną przypisaną przez użytkownika i przypisać ją do co najmniej jednego zasobu platformy Azure. Po włączeniu tożsamości zarządzanej przypisanej przez użytkownika:

  • Jednostka usługi specjalnego typu jest tworzona w identyfikatorze Entra firmy Microsoft dla tożsamości. Jednostka usługi jest zarządzana oddzielnie od zasobów, które go używają.
  • Tożsamości przypisane przez użytkownika mogą być używane przez wiele zasobów.
  • Autoryzujesz tożsamość zarządzaną, aby mieć dostęp do co najmniej jednej usługi.

Aby uzyskać więcej informacji na temat różnic między dwoma typami tożsamości zarządzanych, zobacz Typy tożsamości zarządzanych.

Tożsamości zarządzane w usłudze Azure Kubernetes Service (AKS)

Te dwa typy tożsamości zarządzanych są podobne, dlatego można użyć dowolnego typu, aby autoryzować dostęp do zasobów platformy Azure z klastra usługi AKS. Kluczową różnicą między nimi jest to, że tożsamość zarządzana przypisana przez system jest skojarzona z pojedynczym zasobem platformy Azure, takim jak klaster usługi AKS, podczas gdy tożsamość zarządzana przypisana przez użytkownika jest samym autonomicznym zasobem platformy Azure. Aby uzyskać więcej informacji na temat różnic między typami tożsamości zarządzanych, zobacz Typy tożsamości zarządzanych w Tożsamości zarządzane dla zasobów platformy Azure.

Istnieją trzy typy tożsamości zarządzanych, których można używać z klastrem usługi AKS:

1. tożsamość zarządzana przypisana przez system: Ten typ tożsamości zarządzanej jest skojarzony z pojedynczym zasobem platformy Azure, takim jak klaster usługi AKS. Istnieje tylko w cyklu życia klastra.

2. tożsamość zarządzana przypisana przez użytkownika: Tożsamość zarządzana przypisana przez użytkownika jest autonomicznym zasobem platformy Azure, którego można użyć do autoryzowania dostępu do innych usług platformy Azure z klastra usługi AKS. Jest on utrwalany oddzielnie od klastra i może być używany przez wiele zasobów platformy Azure.

3. wstępnie utworzoną tożsamość zarządzaną kubelet: Jest to opcjonalna tożsamość przypisana przez użytkownika, która może być używana przez narzędzie kubelet do uzyskiwania dostępu do innych zasobów na platformie Azure. Jeśli dla rozwiązania kubelet 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.

Jak usługa AKS korzysta z tożsamości zarządzanych?

Podczas wdrażania klastra usługi AKS zostanie automatycznie utworzona tożsamość zarządzana przypisana przez system. Możesz również utworzyć klaster przy użyciu tożsamości zarządzanej przypisanej przez użytkownika . Klaster używa tej tożsamości zarządzanej do żądania tokenów z identyfikatora Entra firmy Microsoft, które są następnie używane do autoryzowania dostępu do innych zasobów działających na platformie Azure.

Przypisując rolę 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 wpisów tajnych w usłudze Azure Key Vault. Dzięki temu można łatwo autoryzować dostęp do klastra bez zarządzania poświadczeniami.

Korzystanie z tożsamości zarządzanych w usłudze AKS

W przypadku korzystania z tożsamości zarządzanych w usłudze AKS nie trzeba aprowizować ani wymieniać żadnych wpisów tajnych. Platforma Azure zarządza poświadczeniami tożsamości. Dzięki temu można autoryzować dostęp z aplikacji bez zarządzania dodatkowymi wpisami tajnymi.

Jeśli masz już klaster usługi AKS korzystający z tożsamości zarządzanej, możesz zaktualizować go do innego typu tożsamości zarządzanej. Należy jednak pamiętać, że może wystąpić opóźnienie, gdy składniki płaszczyzny sterowania przełączą się do nowej tożsamości. Ten proces może potrwać kilka godzin, a w tym czasie składniki płaszczyzny sterowania będą nadal używać starej tożsamości do momentu wygaśnięcia tokenu.

Podsumowanie tożsamości zarządzanych używanych przez usługę 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. Oto podsumowanie tożsamości zarządzanych używanych przez usługę AKS:

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

Tożsamość obciążeń Microsoft Entra dla platformy Kubernetes

identyfikator obciążenia entra firmy Microsoft integruje się z platformą Kubernetes, aby umożliwić obciążenia wdrożone w klastrze usługi AKS w celu uzyskania dostępu do chronionych zasobów firmy Microsoft, takich jak Azure Key Vault i Microsoft Graph. Używa ona funkcji natywnych dla platformy Kubernetes do federacji z zewnętrznymi dostawcami tożsamości. Aby uzyskać więcej informacji, zobacz Use Microsoft Entra Workload ID with Azure Kubernetes Service (Używanie identyfikatora obciążenia entra firmy Microsoft z usługą Azure Kubernetes Service).

Aby użyć identyfikatora obciążenia Entra firmy Microsoft, należy skonfigurować konto usługi w ramach platformy Kubernetes. To konto usługi jest następnie używane przez zasobniki do bezpiecznego uwierzytelniania i uzyskiwania dostępu do zasobów platformy Azure. Identyfikator obciążenia entra firmy Microsoft dobrze współpracuje z bibliotekami klienta tożsamości platformy Azure lub kolekcją biblioteki Microsoft Authentication Library (MSAL) wraz z rejestracją aplikacji.

Aby w pełni wykorzystać identyfikator obciążenia entra firmy Microsoft w klastrze Kubernetes, należy skonfigurować klaster usługi AKS do wystawiania tokenów i publikowania dokumentu odnajdywania OIDC na potrzeby weryfikacji tokenu. Aby uzyskać więcej informacji, zobacz Create an OpenID Connect provider on Azure Kubernetes Service (Tworzenie dostawcy openID Connect w usłudze Azure Kubernetes Service).

Należy również skonfigurować aplikacje firmy Microsoft Entra, aby ufały tokenom kubernetes. Deweloperzy mogą następnie skonfigurować swoje wdrożenia tak, aby używały kont usługi Kubernetes do uzyskiwania tokenów, które następnie są wymieniane dla tokenów usługi Microsoft Entra według identyfikatora obciążenia firmy Microsoft Entra. Na koniec 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.

Jak pokazano na poniższym diagramie, klaster Kubernetes staje się wystawcą tokenów zabezpieczających, 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ć dla tokenów dostępu firmy Microsoft entra przy użyciu zestawów SDK tożsamości platformy Azure lub biblioteki Microsoft Authentication Library (MSAL).

1. Agent kubelet projektuje token konta usługi do obciążenia w konfigurowalnej ścieżce pliku.
2. Obciążenie Kubernetes wysyła przewidywany, podpisany token konta usługi do identyfikatora Entra firmy Microsoft i żąda tokenu dostępu.
3. Identyfikator entra firmy Microsoft używa dokumentu odnajdywania OIDC, aby sprawdzić zaufanie do tożsamości zarządzanej zdefiniowanej przez użytkownika lub zarejestrowanej aplikacji i zweryfikować token przychodzący.
4. Identyfikator entra firmy Microsoft wystawia token dostępu do zabezpieczeń.
5. Obciążenie Kubernetes uzyskuje dostęp do zasobów platformy Azure przy użyciu tokenu dostępu firmy Microsoft Entra.

Aby uzyskać więcej informacji, dokumentacji i automatyzacji związanych z identyfikatorem obciążenia firmy Microsoft Entra, zapoznaj się z następującymi zasobami:

• projekt open source tożsamości obciążenia platformy Azure
• Federacja tożsamości obciążenia
• Tożsamość obciążeń Microsoft Entra federacji z platformą Kubernetes
• Tożsamość obciążeń Microsoft Entra federacji z zewnętrznymi dostawcami tożsamości OIDC
• Minimalna federacja Tożsamość obciążeń Microsoft Entra
• dokumentacji identyfikatora obciążenia firmy Microsoft
• Tożsamość obciążeń Microsoft Entra Szybki start
• Przykład: użyj identyfikatora obciążenia entra firmy Microsoft dla platformy Kubernetes z tożsamością zarządzaną przypisaną przez użytkownika w aplikacji .NET Standard

Przykładowe obciążenie

Przykładowe obciążenie uruchomione w klastrze usługi AKS składa się z frontonu i usługi zaplecza. Te usługi używają identyfikatora obciążenia Entra firmy Microsoft do uzyskiwania dostępu do usług platformy Azure, w tym usługi Azure Key Vault, Azure Cosmos DB, konta usługi Azure Storage i przestrzeni nazw usługi Azure Service Bus. Aby skonfigurować to przykładowe obciążenie, należy spełnić następujące wymagania wstępne:

1. Skonfiguruj klaster usługi AKS przy użyciu wystawcy OpenID Connect i identyfikator obciążenia entra firmy Microsoft włączony.
2. Utwórz konto usługi Kubernetes w przestrzeni nazw obciążenia.
3. Utwórz tożsamość zarządzaną przypisaną przez użytkownika firmy Microsoft lub zarejestrowaną aplikację .
4. Ustanów poświadczenia tożsamości federacyjnej między tożsamością zarządzaną firmy Microsoft lub zarejestrowaną aplikacją a kontem usługi obciążenia.
5. Przypisz niezbędne role z odpowiednimi uprawnieniami do tożsamości zarządzanej firmy Microsoft lub zarejestrowanej aplikacji.
6. Wdróż obciążenie i zweryfikuj uwierzytelnianie przy użyciu tożsamości obciążenia.

przepływ komunikatów Tożsamość obciążeń Microsoft Entra

W tym przykładowym obciążeniu aplikacje frontonu i zaplecza uzyskują tokeny zabezpieczające firmy Microsoft Entra w celu uzyskania dostępu do usług Azure Platform as a Service (PaaS). Na poniższym diagramie przedstawiono przepływ komunikatów:

Pobierz plik programu Visio z tą architekturą.

1. Platforma Kubernetes wystawia token zasobnikowi, gdy jest on zaplanowany na węźle na podstawie specyfikacji zasobnika lub wdrożenia.
2. Zasobnik wysyła token wystawiony przez identyfikator OIDC do firmy Microsoft Entra, aby zażądać tokenu Entra firmy Microsoft dla określonego appId zasobu i .
3. Microsoft Entra ID sprawdza zaufanie w aplikacji i weryfikuje token przychodzący.
4. Identyfikator entra firmy Microsoft wystawia token zabezpieczający: {sub: appId, aud: requested-audience}.
5. Zasobnik używa tokenu Microsoft Entra w celu uzyskania dostępu do docelowego zasobu platformy Azure.

Aby użyć Tożsamość obciążeń Microsoft Entra kompleksowego klastra Kubernetes:

1. Klaster usługi AKS należy skonfigurować tak, aby wystawiał tokeny i publikował dokument odnajdywania OIDC, aby umożliwić walidację tych tokenów.
2. Aplikacje firmy Microsoft Entra konfigurują się tak, aby ufały tokenom kubernetes.
3. Deweloperzy konfigurują swoje wdrożenia, aby uzyskiwać tokeny kubernetes przy użyciu kont usługi Kubernetes.
4. Tożsamość obciążeń Microsoft Entra wymienia tokeny Kubernetes dla tokenów Firmy Microsoft Entra.
5. Obciążenia klastra usługi AKS używają tokenów firmy Microsoft Entra do uzyskiwania dostępu do chronionych zasobów, takich jak Microsoft Graph.

Współautorzy

Ten artykuł jest obsługiwany przez firmę Microsoft. Pierwotnie został napisany przez następujących współautorów.

Autorzy zabezpieczeń:

• 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
• Cena Ed | Starszy menedżer programu zawartości
• Theano Petersen | Składnik zapisywania technicznego

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

Następne kroki

• Usługa AKS dla specjalistów amazon EKS
• Monitorowanie i rejestrowanie na platformie Kubernetes
• Zabezpieczanie dostępu sieciowego do platformy 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
• Microsoft Entra identity management and access management for AWS

Powiązane zasoby

• Używanie jednostki usługi z usługą Azure Kubernetes Service (AKS)
• Używanie tożsamości zarządzanej w usłudze Azure Kubernetes Service
• Implementowanie usługi Azure Kubernetes Service (AKS)
• Zarządzanie tożsamościami i dostępem w identyfikatorze Entra firmy Microsoft