Freigeben über

Kubernetes-Workload: Identität und Zugriff

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

In diesem Handbuch wird erläutert, wie AKS-Cluster, integrierte Dienste und Add-Ons verwaltete Identitäten verwenden, um auf Azure-Ressourcen zuzugreifen, z. B. Lastenausgleichsgeräte und verwaltete Datenträger. Außerdem wird die Verwendung der Microsoft Entra Workload-ID veranschaulicht, damit AKS-Workloads auf Azure-Ressourcen zugreifen können, ohne dass eine Verbindungszeichenfolge, zugriffstaste oder Benutzeranmeldeinformationen erforderlich sind.

Hinweis

Dieser Artikel ist Teil einer Reihe von Artikeln , die Fachleuten helfen, die mit Amazon EKS vertraut sind, Azure Kubernetes Service (AKS) zu verstehen.

Amazon EKS Identitäts- und Zugriffsverwaltung

Amazon EKS bietet native Optionen zum Verwalten von Identität und Zugriff in Kubernetes-Pods. Diese Optionen umfassen IAM-Rollen für Dienstkonten und amazon EKS-dienstverknüpfte Rollen.

IAM-Rollen für Dienstkonten

Sie können IAM-Rollen mit Kubernetes-Dienstkonten verknüpfen. Diese Zuordnung stellt den Containern in jedem Pod, der das Dienstkonto verwendet, AWS-Berechtigungen bereit. IAM-Rollen für Dienstkonten bieten die folgenden Vorteile:

  • Geringste Berechtigung: Sie können einem Dienstkonto spezifische IAM-Berechtigungen zuweisen, wodurch sichergestellt wird, dass nur die Pods, die dieses Dienstkonto verwenden, Zugriff auf diese Berechtigungen haben. Diese Konfiguration beseitigt die Notwendigkeit, erweiterte Berechtigungen für die Knoten-IAM-Rolle für alle Pods auf einem Knoten zu erteilen. Dieser Ansatz bietet eine verbesserte Sicherheit und granulare Kontrolle und beseitigt die Notwendigkeit von Partnerlösungen wie Kube2iam. Weitere Informationen finden Sie unter IAM-Rollen für Dienstkonten.

  • Isolierung der Anmeldeinformationen: Jeder Container in einem Pod kann nur die Anmeldeinformationen der IAM-Rolle abrufen, die mit seinem jeweiligen Dienstkonto verknüpft ist. Diese Isolation stellt sicher, dass ein Container nicht auf Anmeldeinformationen zugreifen kann, die zu einem anderen Container in einem anderen Pod gehören.

  • Auditierbarkeit: Amazon EKS verwendet AWS CloudTrail zur Bereitstellung von Zugriff und Ereignisprotokollierung, was die retrospektive Überwachung und Compliance erleichtert.

Weitere Informationen finden Sie unter IAM-Rollen für Dienstkonten.

Amazon EKS-dienstverknüpfte Rollen

Amazon EKS-dienstbezogene Rollen sind einzigartige IAM-Rollen, die direkt mit Amazon EKS verknüpft sind. Diese vordefinierten Rollen umfassen die erforderlichen Berechtigungen zum Aufrufen von AWS-Diensten im Auftrag der zugehörigen Rolle. Die wichtigste dienstverknüpfte Rolle für Amazon EKS ist die Amazon EKS-Knoten-IAM-Rolle.

Der Amazon EKS-Knotendaemon kubelet verwendet die Amazon EKS-Knoten-IAM-Rolle, um API-Aufrufe an AWS-Dienste im Auftrag des Knotens zu tätigen. Das IAM-Instanzprofil und die zugehörigen Richtlinien bieten Berechtigungen für diese API-Aufrufe. Diese Einrichtung vereinfacht die Verwaltung von IAM-Rollen für Knoten innerhalb des EKS-Clusters.

Weitere Informationen finden Sie unter Verwenden von dienstverknüpften Rollen für Amazon EKS.

Weitere Informationen zur Identitäts- und Zugriffsverwaltung

Zusätzlich zu den IAM-Rollen für Dienstkonten und dienstverknüpfte Amazon EKS-Rollen umfassen weitere wesentliche Aspekte der Identitäts- und Zugriffsverwaltung in Amazon EKS Folgende:

  • Amazon EKS RBAC-Autorisierung: Amazon EKS unterstützt rollenbasierte Zugriffssteuerung (RBAC). Verwenden Sie dieses Feature, um differenzierte Berechtigungen für Kubernetes-Ressourcen innerhalb Ihres Clusters zu definieren.

  • AWS IAM: IAM bietet eine umfassende Identitätsverwaltungslösung für AWS-Dienste, einschließlich EKS. Verwenden Sie IAM, um Benutzer, Gruppen und Rollen zu erstellen und zu verwalten, um den Zugriff auf Ihre EKS-Ressourcen zu steuern.

  • Amazon EKS-Sicherheitsgruppen: Verwenden Sie Amazon EKS, um Sicherheitsgruppenregeln auf Pods anzuwenden, die innerhalb Ihres Clusters ausgeführt werden. Verwenden Sie dieses Feature, um eingehenden und ausgehenden Datenverkehr zu steuern.

Weitere Informationen finden Sie unter Was ist Amazon EKS?.

Verwaltete Identitäten des AKS-Clusters

AKS-Cluster erfordern eine Microsoft Entra-Identität für den Zugriff auf Azure-Ressourcen, z. B. Lastenausgleichsgeräte und verwaltete Datenträger. Es wird empfohlen, verwaltete Identitäten für Azure-Ressourcen zu verwenden, um den Zugriff von einem AKS-Cluster auf andere Azure-Dienste zu autorisieren.

Verwaltete Identitätstypen

Entwickler kämpfen häufig mit der Verwaltung von Geheimnissen, Anmeldeinformationen, Zertifikaten und Schlüsseln, die die Kommunikation zwischen Diensten sichern. Verwaltete Identitäten vermeiden die Notwendigkeit, diese Anmeldeinformationen zu verwalten. Sie können verwaltete Identitäten verwenden, um Ihren AKS-Cluster zu authentifizieren, ohne Anmeldeinformationen zu verwalten oder sie in Ihren Code einzufügen. Weisen Sie einer Identität eine Azure RBAC-Rolle zu, um der Identität Berechtigungen für bestimmte Ressourcen in Azure zu gewähren.

Zwei Arten von verwalteten Identitäten umfassen:

  • Systemseitig zugewiesen: Sie können einige Azure-Ressourcen wie virtuelle Computer verwenden, um eine verwaltete Identität direkt auf der Ressource zu aktivieren. Wenn Sie eine systemseitig zugewiesene verwaltete Identität aktivieren, geschieht Folgendes:

    • Für die Identität wird in Microsoft Entra ID ein spezieller Dienstprinzipaltyp erstellt. Der Dienstprinzipal ist an den Lebenszyklus dieser Azure-Ressource gebunden. Wenn die Azure-Ressource gelöscht wird, löscht Azure automatisch den Dienstprinzipal.

    • Nur diese Azure-Ressource kann die Identität verwenden, um Token von Der Microsoft Entra-ID anzufordern.

    • Sie autorisieren die verwaltete Identität zum Zugriff auf einen oder mehrere Dienste.

    • Der Name des vom System zugewiesenen Dienstprinzipals entspricht dem Namen der Azure-Ressource, für die er erstellt wurde.

  • Benutzerseitig zugewiesen: Sie können eine verwaltete Identität als eigenständige Azure-Ressource erstellen. Sie können eine vom Benutzer zugewiesene verwaltete Identität erstellen und sie einer oder mehreren Azure-Ressourcen zuweisen. Wenn Sie eine benutzerseitig zugewiesene verwaltete Identität aktivieren, geschieht Folgendes:

    • Für die Identität wird in Microsoft Entra ID ein spezieller Dienstprinzipaltyp erstellt. Der Dienstprinzipal wird getrennt von den Ressourcen verwaltet, die ihn verwenden.

    • Es kann von mehreren Ressourcen genutzt werden.

    • Sie autorisieren die verwaltete Identität zum Zugriff auf einen oder mehrere Dienste.

Sie können einen der beiden Arten von verwalteter Identität verwenden, um den Zugriff auf Azure-Ressourcen von Ihrem AKS-Cluster zu autorisieren.

Weitere Informationen finden Sie unter Arten von verwalteten Identitäten.

Verwaltete Identitäten in AKS

Sie können die folgenden Arten von verwalteten Identitäten mit einem AKS-Cluster verwenden:

  • Eine vom System zugewiesene verwaltete Identität ist einer einzelnen Azure-Ressource zugeordnet, z. B. einem AKS-Cluster. Es ist nur für den Lebenszyklus des Clusters vorhanden.

  • Eine vom Benutzer zugewiesene verwaltete Identität ist eine eigenständige Azure-Ressource , mit der Sie den Zugriff auf andere Azure-Dienste über Ihren AKS-Cluster autorisieren können. Es besteht unabhängig vom Cluster, und verschiedene Azure-Ressourcen können darauf zugreifen.

  • Eine vordefinierte kubelet verwaltete Identität ist eine optionale vom Benutzer zugewiesene Identität, die das Kubelet für den Zugriff auf andere Ressourcen in Azure verwenden kann. Wenn keine vom Benutzer zugewiesene verwaltete Identität für das Kubelet angegeben wird, erstellt AKS eine vom Benutzer zugewiesene Kubelet-Identität in der Knotenressourcengruppe.

Konfigurieren verwalteter Identitäten für AKS-Cluster

Wenn Sie einen AKS-Cluster bereitstellen, wird automatisch eine vom System zugewiesene verwaltete Identität erstellt. Sie können den Cluster auch mit einer benutzerseitig zugewiesenen verwalteten Identität erstellen. Der Cluster verwendet die verwaltete Identität, um Token von der Microsoft Entra-ID anzufordern. Die Token autorisieren den Zugriff auf andere Ressourcen, die in Azure ausgeführt werden.

Wenn Sie der verwalteten Identität eine Azure RBAC-Rolle zuweisen, können Sie Ihren Clusterberechtigungen für den Zugriff auf bestimmte Ressourcen erteilen. Sie können beispielsweise die verwaltete Identität einer Azure RBAC-Rolle zuweisen, die es ermöglicht, auf geheime Schlüssel in einem Azure Key Vault zuzugreifen. Verwenden Sie diesen Ansatz, um den Zugriff auf Ihren Cluster ganz einfach zu autorisieren, ohne Anmeldeinformationen zu verwalten.

Vorteile und Verwaltung von verwalteten Identitäten in AKS

Wenn Sie verwaltete Identitäten in AKS verwenden, müssen Sie Geheimnisse nicht bereitstellen oder aktualisieren. Azure verwaltet die Anmeldeinformationen der Identität. Daher können Sie den Zugriff von Ihren Anwendungen autorisieren, ohne zusätzliche geheime Schlüssel zu verwalten.

Wenn Sie bereits über einen AKS-Cluster verfügen, der eine verwaltete Identität verwendet, können Sie den Cluster auf einen anderen Typ von verwalteter Identität aktualisieren. Dieses Update kann jedoch zu einer Verzögerung führen, während die Komponenten der Steuerungsebene zur neuen Identität wechseln. Dieser Prozess kann mehrere Stunden dauern. Während dieser Zeit verwenden die Komponenten der Steuerungsebene weiterhin die alte Identität, bis ihr Token abläuft.

Typen von verwalteten Identitäten in AKS

AKS verwendet verschiedene Arten von verwalteten Identitäten, um verschiedene integrierte Dienste und Add-Ons zu ermöglichen.

Verwaltete Identität Anwendungsfall Standardberechtigungen
Steuerebene (systemseitig zugewiesen) AKS-Steuerungsebenenkomponenten verwenden diese Identität zum Verwalten von Clusterressourcen. Zu diesen Ressourcen gehören Eingangs-Load-Balancer, AKS-verwaltete öffentliche IP-Adressen, die Cluster-Autoskalierung und Azure-Datenträger-, Datei- und Blob-CSI-Treiber. „Mitwirkender“-Rolle für die Knotenressourcengruppe
Kubelet (benutzerseitig zugewiesen) Authentifizieren mit Azure Container Registry. N/A (für Kubernetes, Version 1.15 und höher)
Add-On-Identitäten (AzureNPM, AzureCNI-Netzwerküberwachung, Azure-Richtlinie und Calico) Für diese Add-Ons ist keine Identität erforderlich. Nicht verfügbar
Weiterleitung von Bewerbungen Verwaltet Azure DNS- und Azure Key Vault-Zertifikate. Rolle „Benutzer von Key VaultGeheimnissen“ für Key Vault, Rolle „DNS-Zonenmitwirkender“ für DNS-Zonen, Rolle „Private DNS-Zonenmitwirkender“ für private DNS-Zonen
Anwendungsgateway für eingehenden Datenverkehr Verwaltet erforderliche Netzwerkressourcen. „Mitwirkender“-Rolle für die Knotenressourcengruppe
Operations Management Suite-Agent (OMS) Sendet AKS-Metriken an Azure Monitor. Rolle „Herausgeber von Überwachungsmetriken“
Virtueller Knoten (Azure Container Instances Connector) Verwaltet erforderliche Netzwerkressourcen für Containerinstanzen. „Mitwirkender“-Rolle für die Knotenressourcengruppe
Kostenanalyse Erfasst Kostenzuordnungsdaten. Nicht verfügbar
Workload-Identität (Workload-ID) Ermöglicht Anwendungen den sicheren Zugriff auf Cloudressourcen mit Workload-ID. Nicht verfügbar

Weitere Informationen finden Sie unter Verwenden einer verwalteten Identität in AKS.

Workload-ID für Kubernetes

Workload-ID integriert sich in Kubernetes, um AKS-Cluster-Workloads den Zugriff auf geschützte Microsoft Entra-Ressourcen wie Key Vault und Microsoft Graph zu ermöglichen. Die Workload-ID verwendet kubernetes-native Funktionen, um eine Verbindung mit externen Identitätsanbietern zu erstellen. Weitere Informationen finden Sie unter Verwenden der Workload-ID mit AKS.

Um workload-ID zu verwenden, konfigurieren Sie ein Dienstkonto in Kubernetes. Pods verwenden dieses Dienstkonto, um Azure-Ressourcen sicher zu authentifizieren und darauf zuzugreifen. Die Workload-ID eignet sich gut für Azure Identity Services-Clientbibliotheken oder die Sammlung der Microsoft-Authentifizierungsbibliothek. Sie müssen die Anwendung in der Microsoft Entra-ID registrieren, um Berechtigungen und Zugriffssteuerung für die Identitäten zu verwalten.

Um die Workload-ID in einem Kubernetes-Cluster vollständig zu verwenden, konfigurieren Sie den AKS-Cluster, um Token auszugeben und ein OpenID Connect(OIDC)-Ermittlungsdokument für die Tokenüberprüfung zu veröffentlichen. Weitere Informationen finden Sie unter Erstellen eines OIDC-Anbieters auf AKS.

Außerdem müssen Sie die Microsoft Entra-Anwendungen so konfigurieren, dass sie den Kubernetes-Token vertrauen. Entwickler können dann ihre Bereitstellungen so konfigurieren, dass Kubernetes-Dienstkonten zum Abrufen von Token verwendet werden. Die Workload-ID tauscht die Token gegen Microsoft Entra-Token aus. AKS-Clusterworkloads können diese Microsoft Entra-Token verwenden, um sicher auf geschützte Ressourcen in Azure zuzugreifen.

Das folgende Diagramm zeigt, wie ein Kubernetes-Cluster zu einem Sicherheitstokenherausgeber wird, der Token für Kubernetes-Dienstkonten ausgibt. Sie können diese Token so konfigurieren, dass sie von Microsoft Entra-Anwendungen als vertrauenswürdig eingestuft werden. Die Token können dann über die Azure Identity Services-SDKs oder die Microsoft-Authentifizierungsbibliothek für Microsoft Entra-Zugriffstoken ausgetauscht werden.

Diagramm, das einen vereinfachten Workflow für eine verwaltete Pod-Identität in Azure zeigt.

  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. Die Microsoft Entra-ID verwendet ein OIDC-Ermittlungsdokument, um die Vertrauensstellung für die benutzerdefinierte verwaltete Identität oder die registrierte Anwendung zu überprüfen und das eingehende Token zu überprüfen.

  4. Microsoft Entra ID stellt ein Sicherheitszugriffstoken aus.

  5. Die Kubernetes-Workload greift über das Microsoft Entra-Zugriffstoken auf Azure-Ressourcen zu.

Weitere Informationen zur Workload-ID finden Sie in den folgenden Ressourcen:

Beispielworkload

Der folgende Beispielworkload wird auf einem AKS-Cluster ausgeführt und besteht aus einem Front-End- und einem Back-End-Dienst. Diese Dienste verwenden Workload-ID für den Zugriff auf Azure-Dienste, einschließlich Key Vault, Azure Cosmos DB, Azure Storage-Konten und Azure Service Bus-Namespaces. Um diese Beispiel-Workload einzurichten, müssen die folgenden Voraussetzungen erfüllt sein:

  1. Richten Sie einen AKS-Cluster mit aktiviertem OIDC-Aussteller und aktivierter Workload-Identität ein.

  2. Erstellen Sie ein Kubernetes-Dienstkonto im Workload Namespace-.

  3. Erstellen Sie eine vom Benutzer zugewiesene verwaltete Identität oder registrierte Anwendung von Microsoft Entra.

  4. Richten Sie Anmeldeinformationen für die Verbundidentität zwischen der verwalteten Identität oder registrierten Anwendung von Microsoft Entra und dem Workload-Dienstkonto ein.

  5. Weisen Sie der von Microsoft Entra verwalteten Identität oder der registrierten Anwendung die notwendigen Rollen mit den entsprechenden Berechtigungen zu.

  6. Bereitstellen der Workload und Überprüfen der Authentifizierung mit der Workloadidentität

Nachrichtenfluss der Workload-ID

In diesem Workload-Beispiel erwerben die Frontend- und Backend-Anwendungen Microsoft Entra-Sicherheitstoken für den Zugriff auf Azure-Plattform als Dienstleistung (PaaS)-Lösungen. Das folgende Diagramm zeigt den Nachrichtenfluss.

Diagramm, das eine Beispielanwendung zeigt, die Workload-ID verwendet.

Laden Sie eine Visio-Datei dieser Architektur herunter.

  1. Kubernetes gibt ein Token für den Pod aus, wenn der Pod einem Knoten zugewiesen wird. Dieser Token basiert auf den Pod- oder Bereitstellungsspezifikationen.

  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 Vertrauenswürdigkeit der 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 Workload-ID End-to-End in einem Kubernetes-Cluster:

  1. Konfigurieren Sie den AKS-Cluster, um Token auszugeben und ein OIDC-Ermittlungsdokument zu veröffentlichen, um die Überprüfung dieser Token zu ermöglichen.

  2. Konfigurieren Sie die Microsoft Entra-Anwendungen, um den Kubernetes-Token zu vertrauen.

  3. Entwickler konfigurieren ihre Bereitstellungen für die Verwendung der Kubernetes-Dienstkonten, um Kubernetes-Token abzurufen.

  4. Die Workload-ID tauscht die Kubernetes-Token für Microsoft Entra-Token aus.

  5. AKS-Clusterworkloads verwenden die Microsoft Entra-Token für den Zugriff auf geschützte Ressourcen, z. B. Microsoft Graph.

Beitragende

Microsoft verwaltet diesen Artikel. Die folgenden Mitwirkenden haben diesen Artikel geschrieben.

Hauptautoren:

Andere Mitwirkende:

Um nichtöffentliche LinkedIn-Profile anzuzeigen, melden Sie sich bei LinkedIn an.

Nächste Schritte