Kubernetes-Workload: Identität und Zugriff

In diesem Artikel wird beschrieben, wie Amazon Elastic Kubernetes Service (Amazon EKS) und Azure Kubernetes Service (AKS) Identität für Kubernetes-Workloads für den Zugriff auf Cloudplattformdienste bereitstellen. Einen detaillierten Vergleich zwischen Amazon Web Services (AWS) Identity & Access Management (IAM) und Microsoft Entra ID finden Sie unter:

• Microsoft Entra Identity Management und Zugriffsverwaltung für AWS
• Zuordnen von AWS IAM-Konzepten zu ähnlichen Konzepten in Azure

In diesem Leitfaden wird erläutert, wie AKS-Cluster, integrierte Dienste und Add-Ons verwaltete Identitäten verwenden, um auf Azure-Ressourcen wie Lastenausgleichsmodule und verwaltete Datenträger zuzugreifen. In dem Artikel wird ferner veranschaulicht, wie Sie Microsoft Entra Workload ID verwenden, damit AKS-Workloads auf Azure-Ressourcen zugreifen können, ohne dass eine Verbindungszeichenfolge, ein Zugriffsschlüssel oder Benutzeranmeldeinformationen benötigt werden.

Amazon EKS-Identitäts- und Zugriffsverwaltung

Amazon EKS verfügt über zwei native Optionen zum Aufrufen von AWS-Diensten aus einem Kubernetes-Pod: IAM-Rollen für Dienstkonten und mit dem Amazon EKS-Dienst verknüpfte Rollen.

IAM-Rollen für Dienstkonten ordnen IAM-Rollen einem Kubernetes-Dienstkonto zu. Dieses Dienstkonto stellt den Containern in jedem Pod, der das Dienstkonto verwendet, AWS-Berechtigungen bereit. IAM-Rollen für Dienstkonten bieten die folgenden Vorteile:

• Geringste Rechte: Sie müssen keine erweiterten Berechtigungen für die Knoten-IAM-Rolle für Pods auf diesem Knoten bereitstellen, um AWS-APIs aufrufen zu können. Sie können den Gültigkeitsbereich von IAM-Berechtigungen auf ein Dienstkonto beschränken, und nur Pods, die dieses Dienstkonto verwenden, haben Zugriff auf diese Berechtigungen. Dieses Feature beseitigt auch die Notwendigkeit für Lösungen von Drittanbietern wie kiam oder kube2iam.

• Isolation von Anmeldeinformationen: Ein Container kann nur Anmeldeinformationen für die IAM-Rolle abrufen, die dem Dienstkonto zugeordnet ist, zu dem er gehört. Ein Container hat nie Zugriff auf Anmeldeinformationen für einen anderen Container, der zu einem anderen Pod gehört.

• Überwachbarkeit: Amazon CloudTrail bietet Zugriffs- und Ereignisprotokollierung, um die retrospektive Überwachung zu gewährleisten.

Mit dem Amazon EKS-Dienst verknüpfte Rollen sind eindeutige IAM-Rollen, die direkt mit Amazon EKS verknüpft sind. Mit dem Dienst verknüpfte Rollen sind von Amazon EKS vordefiniert und enthalten alle Berechtigungen, die zum Aufrufen anderer AWS-Dienste im Auftrag der Rolle erforderlich sind. Für die Amazon EKS-Knoten-IAM-Rolle ruft der kubelet-Daemon des Amazon EKS-Knotens AWS-APIs im Auftrag des Knotens auf. Knoten erhalten Berechtigungen für diese API-Aufrufe aus einem IAM-Instanzprofil und zugeordneten Richtlinien.

Verwaltete Identitäten des AKS-Clusters

Ein AKS-Cluster erfordert eine Identität, um auf Azure-Ressourcen wie Lastenausgleichsmodule und verwaltete Datenträger zuzugreifen. Dabei kann es sich um eine verwaltete Identität oder einen Dienstprinzipal handeln. Standardmäßig wird durch das Erstellen eines AKS-Clusters automatisch auch eine systemseitig zugewiesene verwaltete Identität erstellt. Die Azure-Plattform verwaltet die Identität, und Sie müssen keine Geheimnisse bereitstellen oder rotieren. Weitere Informationen zu verwalteten Microsoft Entra-Identitäten finden Sie unter Was sind verwaltete Identitäten für Azure-Ressourcen?.

AKS erstellt nicht automatisch einen Dienstprinzipal. Wenn Sie also einen Dienstprinzipal verwenden möchten, müssen Sie ihn erstellen. Der Dienstprinzipal läuft letztendlich ab, und Sie müssen ihn verlängern, damit der Cluster funktionsfähig bleibt. Das Verwalten von Dienstprinzipalen erhöht die Komplexität, weshalb es einfacher ist, verwaltete Identitäten zu verwenden.

Verwaltete Identitäten sind im Wesentlichen Dienstprinzipale umschließende Wrapper, die die Verwaltung vereinfachen. Dieselben Berechtigungsanforderungen gelten sowohl für Dienstprinzipale als auch für verwaltete Identitäten. Verwaltete Identitäten verwenden die zertifikatbasierte Authentifizierung. Die Anmeldeinformationen für jede verwaltete Identität haben eine Gültigkeitsdauer von 90 Tagen und werden nach 45 Tagen rotiert.

AKS verwendet sowohl systemseitig zugewiesene als auch benutzerseitig zugewiesene verwaltete Identitätstypen, und diese Identitäten sind unveränderlich. Wenn Sie ein virtuelles AKS-Netzwerk, angefügte Azure-Datenträger, statische IP-Adressen, Routingtabellen oder benutzerseitig zugewiesene kubelet-Identitäten mit Ressourcen außerhalb der Knotenressourcengruppe erstellen oder verwenden, fügt die Azure CLI die Rollenzuweisung automatisch hinzu.

Wenn Sie eine andere Methode zum Erstellen des AKS-Clusters verwenden, z. B. eine Bicep-Vorlage, eine Azure Resource Manager-Vorlage oder ein Terraform-Modul, müssen Sie die Prinzipal-ID der clusterseitig verwalteten Identität verwenden, um eine Rollenzuweisung vorzunehmen. Die AKS-Clusteridentität muss mindestens die Rolle Netzwerkmitwirkender für das Subnetz in Ihrem virtuellen Netzwerk besitzen. Um eine benutzerdefinierte Rolle zu definieren, anstatt die integrierte Rolle „Netzwerkmitwirkender“ zu verwenden, benötigen Sie die folgenden Berechtigungen:

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

Wenn die Clusteridentität auf eine vorhandene Ressource zugreifen muss, z. B. wenn Sie einen AKS-Cluster in einem vorhandenen virtuellen Netzwerk bereitstellen, sollten Sie eine benutzerseitig zugewiesene verwaltete Identität verwenden. Wenn Sie eine systemseitig zugewiesene Steuerungsebenenidentität verwenden, kann der Ressourcenanbieter seine Prinzipal-ID nicht abrufen, bevor er den Cluster erstellt, sodass es unmöglich ist, die richtigen Rollenzuweisungen vor der Clusterbereitstellung zu erstellen.

Zusammenfassung der verwalteten Identitäten

AKS verwendet die folgenden benutzerseitig zugewiesenen verwalteten Identitäten für integrierte Dienste und Add-Ons.

Weitere Informationen finden Sie unter Verwenden einer verwalteten Identität in Azure Kubernetes Service.

Microsoft Entra Workload ID für Kubernetes

Kubernetes-Workloads erfordern Microsoft Entra-Anwendungsanmeldeinformationen, um auf durch Microsoft Entra ID geschützte Ressourcen zuzugreifen (z. B. Azure Key Vault und Microsoft Graph). Eine häufige Herausforderung für Entwickler ist die Verwaltung von Geheimnissen und Anmeldeinformationen, um die Kommunikation zwischen verschiedenen Komponenten einer Lösung zu sichern.

Microsoft Entra Workload ID für Kubernetes beseitigt die Notwendigkeit der Verwaltung von Anmeldeinformationen für den Zugriff auf Clouddienste wie Azure Cosmos DB, Azure Key Vault oder Azure Blob Storage. Eine von AKS gehostete Workloadanwendung kann Microsoft Entra Workload ID verwenden, um mithilfe eines Microsoft Entra-Sicherheitstokens auf einen von Azure verwalteten Dienst zuzugreifen, anstatt explizite Anmeldeinformationen wie eine Verbindungszeichenfolge, einen Benutzernamen und ein Kennwort oder einen Primärschlüssel zu verwenden.

Wie im folgenden Diagramm dargestellt, wird der Kubernetes-Cluster zum Aussteller von Sicherheitstoken, der Token für Kubernetes-Dienstkonten ausstellt. Sie können diese Token so konfigurieren, dass sie von Microsoft Entra-Anwendungen als vertrauenswürdig eingestuft werden. Die Token können dann mithilfe der Azure Identity SDKs oder der Microsoft-Authentifizierungsbibliothek (Microsoft Authentication Library, MSAL) gegen Microsoft Entra-Zugriffstoken ausgetauscht werden.

1. Der kubelet-Agent projiziert ein Dienstkontotoken in die Workload unter einem konfigurierbaren Dateipfad.
2. Die Kubernetes-Workload sendet das projizierte, signierte Dienstkontotoken an Microsoft Entra ID und fordert ein Zugriffstoken an.
3. Microsoft Entra ID verwendet ein OIDC-Ermittlungsdokument, um die Vertrauensstellung der benutzerseitig definierten verwalteten Identität oder der registrierten Anwendung zu überprüfen und das eingehende Token zu validieren.
4. Microsoft Entra ID stellt ein Sicherheitszugriffstoken aus.
5. Die Kubernetes-Workload greift mithilfe des Microsoft Entra-Zugriffstokens auf Azure-Ressourcen zu.

Der Microsoft Entra Workload ID-Verbund für Kubernetes wird derzeit nur für Microsoft Entra-Anwendungen unterstützt, aber dasselbe Modell könnte potenziell auch auf verwaltete Azure-Identitäten erweitert werden.

Weitere Informationen, Details zur Automatisierung und Dokumentation für Microsoft Entra Workload ID finden Sie hier:

• Open-Source-Projekt „Azure-Workloadidentität“.
• Workload-Identitätsverbund
• Microsoft Entra Workload ID-Verbund mit Kubernetes
• Microsoft Entra Workload ID-Verbund mit externen OIDC-Identitätsanbietern
• Minimaler Microsoft Entra Workload ID-Verbund
• Microsoft Entra Workload ID
• Schnellstart zu Microsoft Entra Workload ID
• Verwenden von Microsoft Entra Workload ID für Kubernetes mit einer dem Benutzer zugewiesenen verwalteten Identität in einer .NET Standard-Anwendung

Beispielworkload

Die Beispielworkload führt einen Front-End- und einen Back-End-Dienst in einem AKS-Cluster aus. Die Workloaddienste verwenden Microsoft Entra Workload ID, um mithilfe von Microsoft Entra-Sicherheitstoken auf die folgenden Azure-Dienste zuzugreifen:

• Azure Key Vault
• Azure Cosmos DB
• Azure Storage-Konto
• Azure Service Bus-Namespace

Voraussetzungen

1. Richten Sie einen AKS-Cluster mit aktiviertem OIDC-Aussteller ein.
2. Installieren Sie den Webhook für mutierende Zulassung.
3. Erstellen Sie ein Kubernetes-Dienstkonto für die Workloads.
4. Erstellen Sie wie im Schnellstart gezeigt eine Microsoft Entra-Anwendung.
5. Weisen Sie den erforderlichen registrierten Microsoft Entra-Anwendungen Rollen mit den richtigen Berechtigungen zu.
6. Richten Sie Anmeldeinformationen für die Verbundidentität zwischen der Microsoft Entra-Anwendung und dem Aussteller sowie dem Antragsteller des Dienstkontos ein.
7. Stellen Sie die Workloadanwendung auf dem AKS-Cluster bereit.

Nachrichtenfluss von Microsoft Entra Workload ID

AKS-Anwendungen erhalten Sicherheitstoken für ihr Dienstkonto vom OIDC-Aussteller des AKS-Clusters. Microsoft Entra Workload ID tauscht die Sicherheitstoken gegen von Microsoft Entra ID ausgestellte Sicherheitstoken aus, und die Anwendungen verwenden die von Microsoft Entra ID ausgestellten Sicherheitstoken für den Zugriff auf Azure-Ressourcen.

Das folgende Diagramm zeigt, wie die Front-End- und Back-End-Anwendungen Microsoft Entra-Sicherheitstoken beziehen, um Paas-Dienste (Platform-as-a-Service) von Azure zu verwenden.

Laden Sie eine Visio-Datei dieser Architektur herunter.

1. Kubernetes stellt dem Pod zu dem Zeitpunkt ein Token aus, zu dem er auf einem Knoten geplant ist, basierend auf der Pod- oder Bereitstellungsspezifikation.
2. Der Pod sendet das von OIDC ausgestellte Token an Microsoft Entra ID, um ein Microsoft Entra-Token für die spezifische appId und Ressource anzufordern.
3. Microsoft Entra ID überprüft die Vertrauensstellung für die Anwendung und validiert das eingehende Token.
4. Microsoft Entra ID stellt ein Sicherheitszugriffstoken aus: {sub: appId, aud: requested-audience}.
5. Der Pod verwendet das Microsoft Entra-Token, um auf die Azure-Zielressource zuzugreifen.

So verwenden Sie Microsoft Entra Workload ID End-to-End in einem Kubernetes-Cluster:

1. Sie konfigurieren den AKS-Cluster für das Ausstellen von Token und das Veröffentlichen eines OIDC-Ermittlungsdokuments, um die Validierung dieser Token zu ermöglichen.
2. Sie konfigurieren die Microsoft Entra-Anwendungen so, dass sie den Kubernetes-Token vertrauen.
3. Entwickler konfigurieren ihre Bereitstellungen für die Verwendung der Kubernetes-Dienstkonten, um Kubernetes-Token abzurufen.
4. Microsoft Entra Workload ID tauscht die Kubernetes-Token gegen Microsoft Entra-Token aus.
5. AKS-Clusterworkloads verwenden die Microsoft Entra-Token, um auf geschützte Ressourcen wie Microsoft Graph zuzugreifen.

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautoren:

• Paolo Salvatori | Principal Service Engineer
• Martin Gjoshevski | Senior Service Engineer

Andere Mitwirkende:

• Laura Nicolas | Senior Software Engineer
• Chad Kittel | Principal Software Engineer
• Ed Price | Senior Content Program Manager
• Theano Petersen | Technical Writer

Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.

Nächste Schritte

• AKS für Amazon EKS-Experten
• Kubernetes-Überwachung und -Protokollierung
• Sicherer Netzwerkzugriff auf Kubernetes
• Speicheroptionen für einen Kubernetes-Cluster
• Kostenmanagement für Kubernetes
• Kubernetes-Knoten- und -Knotenpoolverwaltung
• Clustergovernance
• Microsoft Entra Identity Management und Zugriffsverwaltung für AWS

Zugehörige Ressourcen

• Verwenden eines Dienstprinzipals mit Azure Kubernetes Service (AKS)
• Verwenden einer verwalteten Identität in Azure Kubernetes Service
• Implementieren von Azure Kubernetes Service (AKS)
• Verwalten von Identität und Zugriff in Microsoft Entra ID