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 Identity and Access Management

Amazon Elastic Kubernetes Service (EKS) bietet native Optionen zum Verwalten von Identitäts- und Zugriffsverwaltung in Kubernetes-Pods. Diese Optionen umfassen IAM-Rollen für Dienstkonten und amazon EKS-dienstverknüpfte Rollen.

IAM-Rollen für Dienstkonten

MIT DEN IAM-Rollen für Dienstkonten können Sie IAM-Rollen kubernetes-Dienstkonten zuordnen. Diese Zuordnung stellt AWS-Berechtigungen für die Container innerhalb eines beliebigen Pods bereit, die das Dienstkonto verwenden. Die Vorteile der Verwendung von IAM-Rollen für Dienstkonten sind wie folgt:

• Geringste Berechtigung: Sie können einem Dienstkonto bestimmte IAM-Berechtigungen zuweisen und sicherstellen, dass nur die Pods, die dieses Dienstkonto verwenden, Zugriff auf diese Berechtigungen haben. Dadurch wird die Notwendigkeit beseitigt, der Knoten-IAM-Rolle für alle Pods auf einem Knoten erweiterte Berechtigungen zu erteilen, wodurch ein sichererer und differenzierterer Ansatz bereitgestellt wird. Darüber hinaus beseitigt dieses Feature die Notwendigkeit von Drittanbieterlösungen wie kube2iam. Weitere Informationen finden Sie unter IAM-Rollen für Dienstkonten.

• Isolation von Anmeldeinformationen: Jeder Container innerhalb eines Pods kann nur die Anmeldeinformationen für die MIT dem jeweiligen Dienstkonto verknüpfte IAM-Rolle abrufen. Diese Isolation stellt sicher, dass ein Container nicht auf Anmeldeinformationen zugreifen kann, die zu einem anderen Container in einem anderen Pod gehören.

• Auditability: Amazon EKS nutzt Amazon CloudTrail, um Zugriff und Ereignisprotokollierung zu ermöglichen und retrospektive Überwachung und Compliance zu ermöglichen.

Weitere Informationen zu IAM-Rollen für Dienstkonten finden Sie in der offiziellen Dokumentation.

Amazon EKS-dienstverknüpfte Rollen

Amazon EKS Service-verknüpfte Rollen sind einzigartige IAM-Rollen, die direkt mit Amazon EKS verknüpft sind. Diese vordefinierten Rollen enthalten alle erforderlichen Berechtigungen, um AWS-Dienste im Auftrag der zugehörigen Rolle aufzurufen. Die wichtigste serviceverknüpfte Rolle für Amazon EKS ist die Amazon EKS Node IAM Rolle.

Der Amazon EKS-Knoten kubelet Daemon verwendet die Amazon EKS-Knoten-IAM-Rolle, um API-Aufrufe an AWS-Dienste im Auftrag des Knotens durchzuführen. 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 zu serviceverknüpften Rollen von Amazon EKS finden Sie in der offiziellen Dokumentation.

Zusatzinformation

Zusätzlich zu DEN IAM-Rollen für Servicekonten und amazon EKS serviceverknüpfte Rollen gibt es weitere wesentliche Aspekte der Verwaltung von Identität und Zugriff in Amazon EKS.

1. Amazon EKS RBAC Authorization: Amazon EKS unterstützt rollenbasierte Zugriffssteuerung (RBAC), sodass Sie fein abgestimmte Berechtigungen für Kubernetes-Ressourcen innerhalb Ihres Clusters definieren können.

2. AWS Identity and Access Management (IAM): IAM bietet eine umfassende Identitätsverwaltungslösung für AWS-Dienste, einschließlich EKS. Damit können Sie Benutzer, Gruppen und Rollen erstellen und verwalten, um den Zugriff auf Ihre EKS-Ressourcen zu steuern.

3. Amazon EKS-Sicherheitsgruppen: Mit Amazon EKS können Sie Sicherheitsgruppenregeln auf Pods anwenden, die innerhalb Ihres Clusters ausgeführt werden, um eingehenden und ausgehenden Datenverkehr zu steuern.

Weitere Informationen zur Verwaltung von Identitäts- und Zugriffsverwaltung in Amazon EKS finden Sie in der offiziellen Amazon EKS-Dokumentation.

Verwaltete Identitäten des AKS-Clusters

Azure Kubernetes Service (AKS)-Cluster erfordern eine Microsoft Entra Identity für den Zugriff auf Azure-Ressourcen wie Lastenausgleichsgeräte und verwaltete Datenträger. Verwaltete Identitäten für Azure-Ressourcen sind die empfohlene Methode, um den Zugriff von einem AKS-Cluster auf andere Azure-Dienste zu autorisieren.

Was sind verwaltete Identitäten?

Eine häufige Herausforderung für Entwickler ist die Verwaltung von Geheimschlüsseln, Anmeldeinformationen, Zertifikaten und Schlüsseln, die zur Sicherung der Kommunikation zwischen Diensten verwendet werden. verwaltete Identitäten vermeiden, dass Entwickler diese Anmeldeinformationen verwalten müssen. Mit verwalteten Identitäten können Sie Ihren AKS-Cluster authentifizieren, ohne Anmeldeinformationen zu verwalten oder sie in Ihren Code einzugeben. Mit verwalteten Identitäten weisen Sie der Identität eine Azure-rollenbasierte Zugriffssteuerung (Azure RBAC) Rolle zu, und gewähren ihm Berechtigungen für bestimmte Ressourcen in Azure.

Hier sind zwei Arten von verwalteten Identitäten:

• vom System zugewiesene. Einige Azure-Ressourcen, z. B. virtuelle Computer, ermöglichen es Ihnen, eine verwaltete Identität direkt auf der Ressource zu aktivieren. Wenn Sie eine vom System zugewiesene verwaltete Identität aktivieren:

  • Ein Dienstprinzipal eines speziellen Typs wird in der Microsoft Entra-ID für die Identität erstellt. Der Dienstprinzipal ist an den Lebenszyklus dieser Azure-Ressource gebunden. Wenn die Azure-Ressource gelöscht wird, löscht Azure automatisch den Dienstprinzipal für Sie.
  • Standardmäßig kann nur diese Azure-Ressource diese Identität verwenden, um Token von Der Microsoft Entra-ID anzufordern.
  • Sie autorisieren die verwaltete Identität, um Zugriff auf einen oder mehrere Dienste zu haben.
  • Der Name des vom System zugewiesenen Dienstprinzipals entspricht immer dem Namen der Azure-Ressource, für die er erstellt wird.

• vom Benutzer zugewiesene. Sie können auch eine verwaltete Identität als eigenständige Azure-Ressource erstellen. Sie können eine vom Benutzer zugewiesene verwaltete Identität erstellen und einer oder mehreren Azure-Ressourcen zuweisen. Wenn Sie eine vom Benutzer zugewiesene verwaltete Identität aktivieren:

  • Ein Dienstprinzipal eines speziellen Typs wird in der Microsoft Entra-ID für die Identität erstellt. Der Dienstprinzipal wird getrennt von den Ressourcen verwaltet, die ihn verwenden.
  • Vom Benutzer zugewiesene Identitäten können von mehreren Ressourcen verwendet werden.
  • Sie autorisieren die verwaltete Identität, um Zugriff auf einen oder mehrere Dienste zu haben.

Weitere Informationen zu den Unterschieden zwischen den beiden Typen von verwalteten Identitäten finden Sie unter verwalteten Identitätstypen.

Verwaltete Identitäten in Azure Kubernetes Service (AKS)

Diese beiden Arten von verwalteten Identitäten sind ähnlich, da Sie beide Typen verwenden können, um den Zugriff auf Azure-Ressourcen von Ihrem AKS-Cluster zu autorisieren. Der Hauptunterschied zwischen ihnen besteht darin, dass eine vom System zugewiesene verwaltete Identität einer einzelnen Azure-Ressource wie einem AKS-Cluster zugeordnet ist, während eine vom Benutzer zugewiesene verwaltete Identität selbst eine eigenständige Azure-Ressource ist. Weitere Informationen zu den Unterschieden zwischen verwalteten Identitätstypen finden Sie unter verwalteten Identitätstypen in verwalteten Identitäten für Azure-Ressourcen.

Es gibt drei Arten von verwalteten Identitäten, die Sie mit einem AKS-Cluster verwenden können:

1. vom System zugewiesene verwaltete Identität: Dieser Typ der verwalteten Identität ist einer einzelnen Azure-Ressource zugeordnet, z. B. einem AKS-Cluster. Es ist nur für den Lebenszyklus des Clusters vorhanden.

2. vom Benutzer zugewiesenen verwalteten Identität: Eine vom Benutzer zugewiesene verwaltete Identität ist eine eigenständige Azure-Ressource, die Sie verwenden können, um den Zugriff auf andere Azure-Dienste von Ihrem AKS-Cluster zu autorisieren. Sie wird separat vom Cluster beibehalten und kann von mehreren Azure-Ressourcen verwendet werden.

3. Vordefinierte kubelet managed Identity: Dies ist eine optionale vom Kubelet zugewiesene Identität, die vom Kubelet für den Zugriff auf andere Ressourcen in Azure verwendet werden 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.

Wie verwendet AKS verwaltete Identitäten?

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

Indem 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. Auf diese Weise können Sie den Zugriff auf Ihren Cluster ganz einfach autorisieren, ohne Anmeldeinformationen zu verwalten.

Verwenden von verwalteten Identitäten in AKS

Wenn Sie verwaltete Identitäten in AKS verwenden, müssen Sie keine geheimen Schlüssel bereitstellen oder drehen. Azure verwaltet die Anmeldeinformationen der Identität für Sie. Auf diese Weise 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 ihn auf einen anderen Typ von verwalteter Identität aktualisieren. Beachten Sie jedoch, dass es möglicherweise zu einer Verzögerung kommt, während die Komponenten der Steuerebene zur neuen Identität wechseln. Dieser Vorgang kann mehrere Stunden dauern, und während dieser Zeit verwenden die Komponenten der Steuerungsebene weiterhin die alte Identität, bis ihr Token abläuft.

Zusammenfassung der von AKS verwendeten verwalteten Identitäten

AKS verwendet verschiedene Arten von verwalteten Identitäten, um verschiedene integrierte Dienste und Add-Ons zu ermöglichen. Hier ist eine Zusammenfassung der verwalteten Identitäten, die von AKS verwendet werden:

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

Microsoft Entra Workload ID für Kubernetes

Microsoft Entra Workload ID in Kubernetes integriert, um Workloads zu ermöglichen, die auf einem AKS-Cluster bereitgestellt werden, um auf geschützte Microsoft Entra-Ressourcen zuzugreifen, z. B. Azure Key Vault und Microsoft Graph. Es verwendet die systemeigenen Funktionen von Kubernetes, um eine Verbindung mit externen Identitätsanbietern zu erstellen. Weitere Informationen finden Sie unter Verwenden der Microsoft Entra Workload-ID mit azure Kubernetes Service.

Um die Microsoft Entra Workload-ID zu verwenden, müssen Sie ein Dienstkonto in Kubernetes konfigurieren. Dieses Dienstkonto wird dann von Pods verwendet, um Azure-Ressourcen sicher zu authentifizieren und darauf zuzugreifen. Die Microsoft Entra Workload-ID eignet sich gut für Azure Identity-Clientbibliotheken oder die MsAL-Sammlung (Microsoft Authentication Library) zusammen mit der Anwendungsregistrierung.

Um die Microsoft Entra Workload-ID in einem Kubernetes-Cluster vollständig zu nutzen, müssen Sie den AKS-Cluster so konfigurieren, dass Token ausgegeben und ein OIDC-Ermittlungsdokument für die Tokenüberprüfung veröffentlicht werden. Weitere Informationen finden Sie unter Create an OpenID Connect provider on Azure Kubernetes Service.

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 dann von der Microsoft Entra Workload-ID für Microsoft Entra-Token ausgetauscht werden. Schließlich können AKS-Clusterworkloads diese Microsoft Entra-Token verwenden, um sicher auf geschützte Ressourcen in Azure zuzugreifen.

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.

Weitere Informationen, Dokumentationen und Automatisierungen im Zusammenhang mit der Microsoft Entra Workload ID finden Sie in den folgenden Ressourcen:

• Open-Source-Projekt "Azure Workload Identity"
• 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-Dokumentation
• Schnellstart zu Microsoft Entra Workload ID
• Beispiel: Verwenden der Microsoft Entra Workload-ID für Kubernetes mit einer vom Benutzer zugewiesenen verwalteten Identität in einer .NET Standard-Anwendung

Beispielworkload

Eine Beispielarbeitsauslastung, die auf einem AKS-Cluster ausgeführt wird, besteht aus einem Frontend- und einem Back-End-Dienst. Diese Dienste verwenden die Microsoft Entra Workload-ID für den Zugriff auf Azure-Dienste, einschließlich Azure Key Vault, Azure Cosmos DB, Azure Storage-Konto und Azure Service Bus-Namespace. Um diesen Beispielworkload einzurichten, müssen die folgenden Voraussetzungen erfüllt sein:

1. Richten Sie einen AKS-Cluster mit dem OpenID Connect-Aussteller und Microsoft Entra Workload ID ein, aktiviert ist.
2. Erstellen Sie ein Kubernetes-Dienstkonto im Workload Namespace-.
3. Erstellen Sie eine von Microsoft Entra vom Benutzer zugewiesene verwaltete Identität oder registrierten Anwendung.
4. Richten Sie eine Verbundidentitäts-Anmeldeinformationen zwischen der von Microsoft Entra verwalteten Identität oder der registrierten Anwendung und dem Workload-Dienstkonto ein.
5. Weisen Sie die erforderlichen Rollen mit entsprechenden Berechtigungen der von Microsoft Entra verwalteten Identität oder registrierten Anwendung zu.
6. Bereitstellen der Workload und Überprüfen der Authentifizierung mit der Workloadidentität

Nachrichtenfluss von Microsoft Entra Workload ID

In diesem Beispielworkload erwerben die Frontend- und Back-End-Anwendungen Microsoft Entra-Sicherheitstoken für den Zugriff auf Azure Platform as a Service (PaaS)-Dienste. Das folgende Diagramm veranschaulicht den Nachrichtenfluss:

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