Freigeben über


Verwenden der Microsoft Entra-Workload-ID mit Azure Kubernetes Service (AKS)

Workloads, die in einem Azure Kubernetes Services(AKS)-Cluster bereitgestellt werden, erfordern Microsoft Entra-Anwendungsanmeldeinformationen oder verwaltete Identitäten, um auf geschützte Microsoft Entra-Ressourcen wie Azure Key Vault und Microsoft Graph zuzugreifen. Die Microsoft Entra-Workload-ID lässt sich in die nativen Funktionen von Kubernetes integrieren, um mit externen Identitätsanbietern einen Verbund zu bilden.

Microsoft Entra Workload ID verwendet die Volumeprojektion für Dienstkontotoken (also ein Dienstkonto), damit Pods eine Kubernetes-Identität verwenden können. Ein Kubernetes-Token wird ausgegeben, und der OIDC-Verbund ermöglicht Kubernetes-Anwendungen den sicheren Zugriff auf Azure-Ressourcen mit Microsoft Entra ID basierend auf mit Anmerkungen versehenen Dienstkonten.

Microsoft Entra Workload ID funktioniert besonders gut mit den Azure Identity-Clientbibliotheken oder der Sammlung der Microsoft Authentication Library (MSAL), wenn Sie die Anwendungsregistrierung verwenden. Ihre Workload kann eine dieser Bibliotheken verwenden, um Azure-Cloudressourcen nahtlos zu authentifizieren und darauf zuzugreifen.

Dieser Artikel hilft Ihnen dabei, Microsoft Entra Workload ID kennenzulernen und die verfügbaren Optionen zur Planung Ihrer Projektstrategie und einer möglichen Migration von einer podseitig verwalteten Microsoft Entra-Identität zu prüfen.

Hinweis

Sie können den Dienstconnector verwenden, um einige Schritte automatisch zu konfigurieren. Siehe auch: Was ist der Dienstconnector?

Abhängigkeiten

  • AKS unterstützt Microsoft Entra-Workload-IDs ab Version 1.22.
  • Azure CLI-Version 2.47.0 oder höher. Führen Sie az --version aus, um die Version zu finden, und führen Sie az upgrade aus, um ein Upgrade für die Version durchzuführen. Informationen zum Durchführen einer Installation oder eines Upgrades finden Sie bei Bedarf unter Installieren der Azure CLI.

Azure Identity-Clientbibliotheken

Wählen Sie in den Azure Identity-Clientbibliotheken einen der folgenden Ansätze aus:

  • Verwenden Sie DefaultAzureCredential, die versucht, die WorkloadIdentityCredential zu verwenden.
  • Erstellen Sie eine ChainedTokenCredential-Instanz, die WorkloadIdentityCredential enthält.
  • Verwenden Sie WorkloadIdentityCredential direkt.

Die folgende Tabelle enthält die Mindestpaketversion, die für die Clientbibliothek der einzelnen Sprach-Ökosysteme erforderlich ist.

Ökosystem Bibliothek Mindestversion
.NET Azure.Identity 1.9.0
C++ azure-identity-cpp 1.6.0
Go azidentity 1.3.0
Java azure-identity 1.9.0
Node.js @azure/identity 3.2.0
Python azure-identity 1.13.0

In den folgenden Codebeispielen DefaultAzureCredential wird verwendet. Dieser Anmeldeinformationstyp verwendet die Umgebungsvariablen, die vom Webhook zum Ändern der Azure-Workloadidentität eingeschleust werden, um sich bei Azure Key Vault zu authentifizieren.

using Azure.Identity;
using Azure.Security.KeyVault.Secrets;

string keyVaultUrl = Environment.GetEnvironmentVariable("KEYVAULT_URL");
string secretName = Environment.GetEnvironmentVariable("SECRET_NAME");

var client = new SecretClient(
    new Uri(keyVaultUrl),
    new DefaultAzureCredential());

KeyVaultSecret secret = await client.GetSecretAsync(secretName);

Microsoft Authentication Library (MSAL)

Die folgenden Clientbibliotheken sind die erforderliche Mindestversion.

Ökosystem Bibliothek Image Beispiel Verfügt über Windows
.NET microsoft-authentication-library-for-dotnet ghcr.io/azure/azure-workload-identity/msal-net:latest Link Ja
Go microsoft-authentication-library-for-go ghcr.io/azure/azure-workload-identity/msal-go:latest Link Ja
Java microsoft-authentication-library-for-java ghcr.io/azure/azure-workload-identity/msal-java:latest Link Nein
JavaScript microsoft-authentication-library-for-js ghcr.io/azure/azure-workload-identity/msal-node:latest Link Nein
Python microsoft-authentication-library-for-python ghcr.io/azure/azure-workload-identity/msal-python:latest Link Nein

Begrenzungen

  • Jede verwaltete Identität kann nur 20 Anmeldeinformationen für Verbundidentitäten aufweisen.
  • Es dauert einige Sekunden, bis die Verbundidentitäts-Anmeldeinformationen nach dem erstmaligen Hinzufügen weitergegeben werden.
  • Das Add-On für virtuelle Knoten, das auf dem Open-Source-Projekt Virtual Kubelet basiert, wird nicht unterstützt.
  • In den folgenden Regionen wird die Erstellung von Anmeldeinformationen für Verbundidentitäten für benutzerseitig zugewiesene verwaltete Identitäten nicht unterstützt.

Funktionsweise

In diesem Sicherheitsmodell fungiert der AKS-Cluster als Tokenaussteller. Microsoft Entra ID verwendet OpenID Connect, um öffentliche Signaturschlüssel zu ermitteln und die Authentizität des Dienstkontotokens zu überprüfen, bevor es gegen ein Microsoft Entra-Token ausgetauscht wird. Ihre Workload kann mithilfe der Azure Identity-Clientbibliothek oder der Microsoft Authentication Library (MSAL) ein auf ihr Volume projiziertes Dienstkontotoken gegen ein Microsoft Entra-Token austauschen.

Diagramm des AKS-Identitätssicherheitsmodells

In der folgenden Tabelle werden die erforderlichen OIDC-Ausstellerendpunkte für die Microsoft Entra-Workload-ID beschrieben:

Endpunkt BESCHREIBUNG
{IssuerURL}/.well-known/openid-configuration Auch als OIDC-Ermittlungsdokument bezeichnet. Es enthält die Metadaten zu den Konfigurationen des Ausstellers.
{IssuerURL}/openid/v1/jwks Es enthält die öffentlichen Signaturschlüssel, die Microsoft Entra ID verwendet, um die Authentizität des Dienstkontotokens zu überprüfen.

Im folgenden Diagramm wird die Authentifizierungssequenz mit OpenID Connect zusammengefasst dargestellt.

Diagramm der OIDC-Authentifizierungssequenz der AKS-Workloadidentität

Automatische Webhook-Zertifikatrotation

Ähnlich wie bei anderen Webhook-Add-Ons wird das Zertifikat durch automatische Rotation des Clusterzertifikats rotiert.

Dienstkontobezeichnungen und -anmerkungen

Die Microsoft Entra-Workload-ID unterstützt die folgenden Zuordnungen im Zusammenhang mit einem Dienstkonto:

  • 1:1, wobei ein Dienstkonto auf ein Microsoft Entra-Objekt verweist
  • n:1, wobei mehrere Dienstkonten auf dasselbe Microsoft Entra-Objekt verweisen
  • 1:n, wobei ein Dienstkonto auf mehrere Microsoft Entra-Objekte verweist, indem die Client-ID-Anmerkung geändert wird. Weitere Informationen finden Sie unter Verbinden mehrerer Identitäten mit einem Kubernetes-Dienstkonto.

Hinweis

Wenn die Anmerkungen des Dienstkontos aktualisiert werden, müssen Sie den Pod neu starten, damit die Änderungen wirksam werden.

Wenn Sie eine podseitig verwaltete Microsoft Entra-Identität verwendet haben, können Sie sich das Dienstkonto wie einen Azure-Dienstprinzipal vorstellen, mit dem Unterschied, dass ein Dienstkonto Teil der Kubernetes-Kern-API ist und keine benutzerdefinierte Ressourcendefinition. Die folgenden Abschnitte enthalten eine Liste der verfügbaren Bezeichnungen und Anmerkungen, die zum Konfigurieren des Verhaltens beim Austausch des Dienstkontotokens gegen ein Microsoft Entra-Zugriffstoken verwendet werden können.

Dienstkontoanmerkungen

Alle Anmerkungen sind optional. Wenn die Anmerkung nicht angegeben ist, wird der Standardwert verwendet.

Anmerkung BESCHREIBUNG Standard
azure.workload.identity/client-id Stellt die Client-ID der Microsoft Entra-Anwendung dar
die mit dem Pod verwendet werden soll.
azure.workload.identity/tenant-id Stellt die Azure-Mandanten-ID dar, in der die
Microsoft Entra-Anwendung registriert ist.
Umgebungsvariable AZURE_TENANT_ID,
aus ConfigMap azure-wi-webhook-config extrahiert
azure.workload.identity/service-account-token-expiration Stellt das Feld expirationSeconds
für das projizierte Dienstkontotoken dar. Es ist ein optionales Feld, das Sie konfigurieren können, um Ausfallzeiten zu verhindern,
die durch Fehler während der Aktualisierung des Dienstkontotokens verursacht werden. Ablaufdatum des Kubernetes-Dienstkontotokens korreliert nicht mit Microsoft Entra-Token. Microsoft Entra-Token sind 24 Stunden gültig, nachdem sie ausgestellt wurden.
3600
Der unterstützte Bereich ist 3600-86400.

Podbezeichnungen

Hinweis

Für Anwendungen, die eine Workloadidentität verwenden, muss die Bezeichnung azure.workload.identity/use: "true" zu den Podspezifikationen für AKS hinzugefügt werden. So kann AKS die Workloadidentität in ein Szenario vom Typ Fail Close überführen, um für Pods, die die Workloadidentität verwenden müssen, ein konsistentes und zuverlässiges Verhalten zu gewährleisten. Andernfalls schlagen die Pods nach dem Neustart fehl.

Bezeichnung BESCHREIBUNG Empfohlener Wert Erforderlich
azure.workload.identity/use Diese Bezeichnung ist in der Podvorlagenspezifikation erforderlich. Nur Pods mit dieser Bezeichnung werden durch den Webhook für mutierende Zulassungen „azure-workload-identity“ verändert, um die Azure-spezifischen Umgebungsvariablen und das angepasste Dienstkontotoken-Volumen einzuschleusen. true Ja

Podanmerkungen

Alle Anmerkungen sind optional. Wenn die Anmerkung nicht angegeben ist, wird der Standardwert verwendet.

Anmerkung BESCHREIBUNG Standard
azure.workload.identity/service-account-token-expiration Stellt das expirationSeconds-Feld für das projizierte Dienstkontotoken dar. Es ist ein optionales Feld, das Sie konfigurieren können, um Ausfallzeiten zu verhindern, die durch Fehler während der Aktualisierung des Dienstkontotokens verursacht werden. Ablaufdatum des Kubernetes-Dienstkontotokens korreliert nicht mit Microsoft Entra-Token. Microsoft Entra-Token sind 24 Stunden gültig, nachdem sie ausgestellt wurden. 1 3600
Der unterstützte Bereich ist 3600-86400.
azure.workload.identity/skip-containers Stellt eine durch Semikolons getrennte Containerliste dar, um das Hinzufügen von projizierten Dienstkontotokenvolumes zu überspringen. Beispiel: container1;container2. Standardmäßig wird das projizierte Dienstkontotokenvolume allen Containern hinzugefügt, wenn das Dienstkonto die Bezeichnung azure.workload.identity/use: true hat.
azure.workload.identity/inject-proxy-sidecar Fügt einen Proxy-Init-Container und einen Proxy-Sidecar in den Pod ein. Der Proxy-Sidecar wird verwendet, um Tokenanforderungen an IMDS abzufangen und ein Microsoft Entra-Token im Auftrag des Benutzers bzw. der Benutzerin mit Anmeldeinformationen für eine Verbundidentität zu erwerben. true
azure.workload.identity/proxy-sidecar-port Stellt den Port des Proxy-Sidecars dar. 8.000

1 Hat Vorrang, wenn das Dienstkonto ebenfalls mit der Anmerkung versehen ist.

Migrieren zu Microsoft Entra Workload ID

Sie können einen Cluster, der bereits eine podseitig verwaltete Identität ausführt, auf zwei Arten für die Verwendung der Workloadidentität konfigurieren. Die erste Option ermöglicht es Ihnen, die gleiche Konfiguration zu verwenden, die Sie für die podseitig verwaltete Identität implementiert haben. Sie können dem Dienstkonto im Namespace eine Anmerkung mit der Identität hinzufügen, um Microsoft Entra Workload ID zu aktivieren und die Anmerkungen in die Pods einzufügen.

Die zweite Option besteht darin, Ihre Anwendung neu zu schreiben, um die neueste Version der Azure Identity-Clientbibliothek zu verwenden.

Zur Optimierung und Vereinfachung des Migrationsprozesses haben wir einen Migrations-Sidecar entwickelt, der die IMDS-Transaktionen konvertiert, die Ihre Anwendung in OpenID Connect (OIDC) erstellt. Der Migrations-Sidecar ist nicht als langfristige Lösung gedacht, sondern als eine Möglichkeit, Workloadidentitäten schnell einzurichten und auszuführen. Wenn Sie den Migrations-Sidecar innerhalb Ihrer Anwendung ausführen, werden die IMDS-Transaktionen der Anwendung an OIDC weitergeleitet. Ein anderer Ansatz besteht darin, ein Upgrade einer unterstützten Version der Azure Identity-Clientbibliothek durchzuführen, die die OIDC-Authentifizierung unterstützt.

In der folgenden Tabelle werden unsere Migrations- bzw. Bereitstellungsempfehlungen für die Workloadidentität zusammengefasst.

Szenario BESCHREIBUNG
Neue oder vorhandene Clusterbereitstellung führt eine unterstützte Version der Azure Identity-Clientbibliothek aus. Es sind keine Migrationsschritte erforderlich.
Beispielbereitstellungsressourcen: Bereitstellen und Konfigurieren der Workloadidentität auf einem neuen Cluster
Neue oder vorhandene Clusterbereitstellung führt eine nicht unterstützte Version der Azure Identity-Clientbibliothek aus. Aktualisieren Sie das Containerimage, um eine unterstützte Version des Azure Identity SDK zu verwenden, oder verwenden Sie den Migrations-Sidecar.

Nächste Schritte