Edytuj

Udostępnij za pośrednictwem

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

Identyfikator Microsoft Entra
Azure Kubernetes Service (AKS)

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:

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.

Uwaga

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

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

Usługa Amazon EKS ma dwie natywne opcje wywoływania usług AWS z poziomu zasobnika Kubernetes: role zarządzanie dostępem i tożsamościami dla kont usług oraz role połączone z usługą Amazon EKS.

Role zarządzania dostępem i tożsamościami dla kont usług kojarzą role zarządzania dostępem i tożsamościami z kontem usługi Kubernetes. To konto usługi 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: nie musisz udostępniać rozszerzonych uprawnień do roli zarządzania dostępem i tożsamościami węzłów dla zasobników w tym węźle w celu wywoływania interfejsów API platformy AWS. Możesz ograniczyć zakres uprawnień zarządzania dostępem i tożsamościami do konta usługi, a tylko zasobniki korzystające z tego konta usługi mają dostęp do tych uprawnień. Ta funkcja eliminuje również konieczność korzystania z rozwiązań innych firm, takich jak kiam lub kube2iam.

  • Izolacja poświadczeń: kontener może pobierać poświadczenia tylko dla roli IAM skojarzonej z kontem usługi, do którego należy. Kontener nigdy nie ma dostępu do poświadczeń dla innego kontenera należącego do innego zasobnika.

  • Inspekcja: Usługa Amazon CloudTrail zapewnia dostęp i rejestrowanie zdarzeń, aby zapewnić inspekcję retrospektywną.

Połączone role usługi Amazon EKS to unikatowe role IAM połączone bezpośrednio z usługą Amazon EKS. Role połączone z usługą są wstępnie zdefiniowane przez usługę Amazon EKS i obejmują wszystkie uprawnienia wymagane do wywoływania innych usług AWS w imieniu roli. W przypadku roli IAM węzła Usługi Amazon EKS demon węzła kubelet Amazon EKS wywołuje interfejsy API platformy AWS w imieniu węzła. Węzły uzyskują uprawnienia do tych wywołań interfejsu API z profilu wystąpienia IAM i skojarzonych zasad.

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

Klaster usługi AKS wymaga tożsamości w celu uzyskania dostępu do zasobów platformy Azure, takich jak moduły równoważenia obciążenia i dyski zarządzane. Ta tożsamość może być tożsamością zarządzaną lub jednostką usługi. Domyślnie tworzenie klastra usługi AKS automatycznie tworzy tożsamość zarządzaną przypisaną przez system. Platforma Azure zarządza tożsamością i nie musisz aprowizować ani obracać żadnych wpisów tajnych. Aby uzyskać więcej informacji na temat tożsamości zarządzanych firmy Microsoft Entra, zobacz Tożsamości zarządzane dla zasobów platformy Azure.

Usługa AKS nie tworzy automatycznie jednostki usługi, więc jeśli chcesz użyć jednostki usługi, musisz ją utworzyć. Jednostka usługi ostatecznie wygaśnie i należy ją odnowić, aby klaster działał. Zarządzanie jednostkami usługi zwiększa złożoność, dzięki czemu łatwiej jest używać tożsamości zarządzanych.

Tożsamości zarządzane są zasadniczo otokami jednostek usługi, które upraszczają zarządzanie. Te same wymagania dotyczące uprawnień dotyczą zarówno jednostek usługi, jak i tożsamości zarządzanych. Tożsamości zarządzane używają uwierzytelniania opartego na certyfikatach. Każde poświadczenie tożsamości zarządzanych ma wygaśnięcie 90 dni i jest obracane po 45 dniach.

Usługa AKS używa zarówno przypisanych przez system, jak i przypisanych przez użytkownika typów tożsamości zarządzanych, a te tożsamości są niezmienne. Podczas tworzenia lub używania sieci wirtualnej usługi AKS dołączonego dysku platformy Azure, statycznego adresu IP, tabeli tras lub tożsamości przypisanej przez kubelet użytkownika z zasobami spoza grupy zasobów węzła interfejs wiersza polecenia platformy Azure automatycznie dodaje przypisanie roli.

Jeśli używasz innej metody do utworzenia klastra usługi AKS, takiego jak szablon Bicep, szablon usługi Azure Resource Manager lub moduł Terraform, musisz użyć identyfikatora głównego tożsamości zarządzanej klastra, aby wykonać przypisanie roli. Tożsamość klastra usługi AKS musi mieć co najmniej rolę Współautor sieci w podsieci w sieci wirtualnej. Aby zdefiniować rolę niestandardową zamiast używać wbudowanej roli Współautor sieci, potrzebne są następujące uprawnienia:

  • Microsoft.Network/virtualNetworks/subnets/join/action
  • Microsoft.Network/virtualNetworks/subnets/read

Jeśli tożsamość klastra musi uzyskać dostęp do istniejącego zasobu, na przykład podczas wdrażania klastra usługi AKS w istniejącej sieci wirtualnej, należy użyć tożsamości zarządzanej przypisanej przez użytkownika. Jeśli używasz tożsamości płaszczyzny sterowania przypisanej przez system, dostawca zasobów nie może uzyskać swojego identyfikatora głównego przed utworzeniem klastra, więc nie można utworzyć odpowiednich przypisań ról przed aprowizowaniem klastra.

Podsumowanie tożsamości zarządzanych

Usługa AKS używa następujących tożsamości zarządzanych przypisanych przez użytkownika do wbudowanych usług i dodatków.

Tożsamość Nazwisko Przypadek użycia Uprawnienia domyślne Przynieś własną tożsamość
Płaszczyzna sterowania Nazwa klastra usługi AKS Zarządza zasobami klastra, w tym modułami równoważenia obciążenia ruchu przychodzącego i publicznymi adresami IP zarządzanymi przez usługę AKS, modułem skalowania automatycznego klastra oraz sterownikami plików plików platformy Azure i plików platformy Azure Rola współautora dla grupy zasobów węzła Obsługiwane
Kubelet Pula nazwa-agenta klastra usługi AKS Uwierzytelnianie za pomocą usługi Azure Container Registry NA (dla platformy Kubernetes w wersji 1.15 lub nowszej) Obsługiwane
Dodatek HTTPApplicationRouting Zarządza wymaganymi zasobami sieciowymi Rola czytelnika dla grupy zasobów węzła, rola Współautor dla strefy DNS Nie.
Dodatek Brama aplikacji ruchu przychodzącego Zarządza wymaganymi zasobami sieciowymi Rola współautora dla grupy zasobów węzła Nie.
Dodatek omsagent Wysyłanie metryk usługi AKS do usługi Azure Monitor Rola wydawcy metryk monitorowania Nie.
Dodatek Węzeł wirtualny (ACIConnector) Zarządza wymaganymi zasobami sieciowymi dla usługi Azure Container Instances Rola współautora dla grupy zasobów węzła Nie.

Aby uzyskać więcej informacji, zobacz Use a managed identity in Azure Kubernetes Service (Używanie tożsamości zarządzanej w usłudze Azure Kubernetes Service).

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

Obciążenia Kubernetes wymagają poświadczeń aplikacji firmy Microsoft Entra w celu uzyskania dostępu do chronionych zasobów firmy Microsoft, takich jak Azure Key Vault i Microsoft Graph. Typowym wyzwaniem dla deweloperów jest zarządzanie wpisami tajnymi i poświadczeniami w celu zabezpieczenia komunikacji między różnymi składnikami rozwiązania.

Tożsamość obciążeń Microsoft Entra dla platformy Kubernetes eliminuje konieczność zarządzania poświadczeniami w celu uzyskania dostępu do usług w chmurze, takich jak Azure Cosmos DB, Azure Key Vault lub Azure Blob Storage. Aplikacja obciążenia hostowana w usłudze AKS może używać Tożsamość obciążeń Microsoft Entra do uzyskiwania dostępu do usługi zarządzanej platformy Azure przy użyciu tokenu zabezpieczającego firmy Microsoft Entra, zamiast jawnych poświadczeń, takich jak parametry połączenia, nazwa użytkownika i hasło lub klucz podstawowy.

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

Diagram przedstawiający uproszczony przepływ pracy dla tożsamości zarządzanej zasobnika na platformie Azure.

  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.

federacja Tożsamość obciążeń Microsoft Entra dla platformy Kubernetes jest obecnie obsługiwana tylko w przypadku aplikacji Firmy Microsoft Entra, ale ten sam model może potencjalnie rozszerzyć na tożsamości zarządzane platformy Azure.

Aby uzyskać więcej informacji, automatyzacji i dokumentacji dla Tożsamość obciążeń Microsoft Entra, zobacz:

Przykładowe obciążenie

Przykładowe obciążenie uruchamia fronton i usługę zaplecza w klastrze usługi AKS. Usługi obciążeń używają Tożsamość obciążeń Microsoft Entra do uzyskiwania dostępu do następujących usług platformy Azure przy użyciu tokenów zabezpieczających firmy Microsoft Entra:

  • Azure Key Vault
  • Azure Cosmos DB
  • Konto usługi Azure Storage
  • Przestrzeń nazw usługi Azure Service Bus

Wymagania wstępne

  1. Skonfiguruj klaster usługi AKS z włączonym wystawcą OIDC.
  2. Zainstaluj mutujący element webhook wstępu.
  3. Utwórz konto usługi Kubernetes dla obciążeń.
  4. Utwórz aplikację Microsoft Entra, jak pokazano w przewodniku Szybki start.
  5. Przypisz role z odpowiednimi uprawnieniami do wymaganych zarejestrowanych aplikacji firmy Microsoft.
  6. Ustanów poświadczenia tożsamości federacyjnej między aplikacją Microsoft Entra a wystawcą konta usługi i podmiotem.
  7. Wdróż aplikację obciążenia w klastrze usługi AKS.

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

Aplikacje usługi AKS uzyskują tokeny zabezpieczające dla konta usługi od wystawcy OIDC klastra usługi AKS. Tożsamość obciążeń Microsoft Entra wymienia tokeny zabezpieczające za pomocą tokenów zabezpieczających wystawionych przez identyfikator Firmy Microsoft Entra, a aplikacje używają wystawionych przez firmę Microsoft Entra tokenów zabezpieczających w celu uzyskania dostępu do zasobów platformy Azure.

Na poniższym diagramie pokazano, jak aplikacje frontonu i zaplecza uzyskują tokeny zabezpieczające firmy Microsoft do korzystania z usług PaaS (Platform as a Service).

Diagram przedstawiający przykładową aplikację korzystającą z Tożsamość obciążeń Microsoft Entra.

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

Inni współautorzy:

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

Następne kroki