Workload-Identitätsverbund

  • Artikel

Dieser Abschnitt gewährt eine Übersicht über den Verbund Workload Identity für Software-Workloads. Mithilfe des Workloadidentitätsverbunds können Sie auf durch Microsoft Entra geschützte Ressourcen zugreifen, ohne Geheimnisse verwalten zu müssen (für unterstützte Szenarien).

Sie können den Workloadidentitätsverbund in Szenarien wie GitHub Actions, in Kubernetes ausgeführten Workloads oder auf Computeplattformen außerhalb von Azure ausgeführten Workloads verwenden.

Warum sollten Sie den Verbund Workload Identity (Arbeitslast-Identität) nutzen?

Sehen Sie sich dieses Video an, um zu erfahren, warum Sie den Workloadidentitätsverbund verwenden sollten.

In der Regel benötigt eine Software-Arbeitslast (Workload) (z. B. eine Anwendung, ein Dienst, ein Skript oder eine containerbasierte Anwendung) eine Identität, um Ressourcen zu authentifizieren und darauf zu zugreifen oder mit anderen Diensten zu kommunizieren. Wenn diese Workloads in Azure ausgeführt werden, können Sie verwaltete Identitäten verwenden, und die Azure-Plattform verwaltet die Anmeldeinformationen für Sie. Sie können verwaltete Identitäten jedoch nur für Softwareworkloads verwenden, die in Azure ausgeführt werden. Für eine Softwareworkload, die außerhalb von Azure ausgeführt wird, müssen Sie Anwendungsanmeldeinformationen (ein Geheimnis oder Zertifikat) für den Zugriff auf durch Microsoft Entra geschützte Ressourcen (z. B. Azure, Microsoft Graph, Microsoft 365 oder Ressourcen von Drittanbietern) verwenden. Diese Anmeldeinformationen stellen ein Sicherheitsrisiko dar und müssen sicher gespeichert und regelmäßig durchgewechselt werden. Außerdem besteht das Risiko einer Dienstausfallzeit, wenn die Anmeldeinformationen ablaufen.

Sie verwenden den Workloadidentitätsverbund, um eine benutzerseitig zugewiesene verwaltete Identität oder App-Registrierung in Microsoft Entra ID so zu konfigurieren, dass sie Token von einem externen Identitätsanbieter (IdP) wie GitHub oder Google vertraut. Die benutzerseitig zugewiesene verwaltete Identität oder App-Registrierung in Microsoft Entra ID wird zu einer Identität für Softwareworkloads, die z. B. in lokalen Kubernetes- oder GitHub Actions-Workflows ausgeführt werden. Sobald diese Vertrauensbeziehung hergestellt ist, tauscht Ihre externe Software-Workload vertrauenswürdige Token vom externen IdP gegen Zugriffstoken von der Microsoft Identitätsplattform aus. Ihre Software-Workload verwendet dann dieses Zugriffstoken für den Zugriff auf durch Microsoft Entra geschützte Ressourcen, auf die der Workload Zugriff gewährt wurde. Der Wartungsaufwand für die manuelle Verwaltung von Anmeldeinformationen entfällt und das Risiko, dass Geheimnisse preisgegeben werden oder Zertifikate ablaufen, wird eliminiert.

Unterstützte Szenarien

Die folgenden Szenarien werden für den Zugriff auf durch Microsoft Entra geschützte Ressourcen mithilfe eines Workloadidentitätsverbunds unterstützt:

  • Workloads, die auf einem beliebigen Kubernetes-Cluster (Azure Kubernetes Service (AKS), Amazon Web Services EKS, Google Kubernetes Engine (GKE) oder vor Ort) ausgeführt werden. Stellen Sie eine Vertrauensstellung zwischen Ihrer benutzerseitig zugewiesenen verwalteten Identität oder App in Microsoft Entra ID und einer Kubernetes-Workload her (wie in der Übersicht über Workloadidentitäten beschrieben).
  • GitHub Actions. Konfigurieren Sie zunächst eine Vertrauensstellung zwischen Ihrer benutzerseitig zugewiesenen verwalteten Identität oder der Anwendung in Microsoft Entra ID und einem GitHub-Repository im Microsoft Entra Admin Center oder mit Microsoft Graph. Konfigurieren Sie einen GitHub-Aktionen-Arbeitsablauf (Actions worklfow), um ein Zugriffstoken vom Microsoft-Identitäts-Provide abzurufen und auf Azure-Ressourcen zuzugreifen.
  • Google Cloud. Konfigurieren Sie zunächst eine Vertrauensstellung zwischen Ihrer benutzerseitig zugewiesenen verwalteten Identität oder App in Microsoft Entra ID und einer Identität in Google Cloud. Konfigurieren Sie dann Ihre in Google Cloud ausgeführte Softwareworkload, um ein Zugriffstoken vom Microsoft-Identitätsanbieter abzurufen und auf durch Microsoft Entra geschützte Ressourcen zuzugreifen. Weitere Informationen finden Sie unter Zugreifen auf geschützte Microsoft Entra ID-Ressourcen über eine App in Google Cloud.
  • Workloads, die in Amazon Web Services (AWS) ausgeführt werden. Konfigurieren Sie zunächst eine Vertrauensstellung zwischen Ihrer benutzerseitig zugewiesenen verwalteten Identität oder App in Microsoft Entra ID und einer Identität in Amazon Cognito. Konfigurieren Sie dann Ihre in AWS ausgeführte Softwareworkload, um ein Zugriffstoken vom Microsoft-Identitätsanbieter abzurufen und auf durch Microsoft Entra geschützte Ressourcen zuzugreifen. Weitere Informationen finden Sie unter Workload-Identitätsverbund mit AWS.
  • Andere Workloads, die auf Compute-Plattformen außerhalb von Azure ausgeführt werden. Konfigurieren Sie eine Vertrauensstellung zwischen Ihrer benutzerseitig zugewiesenen verwalteten Identität oder Anwendung in Microsoft Entra ID und dem externen IdP für Ihre Computeplattform. Sie können von dieser Plattform ausgestellte Token verwenden, um sich mit der Microsoft Identity Platform zu authentifizieren und APIs im Microsoft-Ökosystem aufzurufen. Verwenden Sie den Client-Anmeldeinformationen-Flow, um einen Zugriffstoken von der Microsoft Identity Platform zu bekommen. Übergeben Sie dabei das JWT des Identitäts-Providers, anstatt selbst ein Zugriffstoken mithilfe eines gespeicherten Zertifikats zu erstellen.
  • SPIFFE und SPIRE sind plattformunabhängige Open-Source-Standards für die Bereitstellung von Identitäten für Ihre Software-Workloads, die auf verschiedenen Plattformen und Cloud-Anbietern eingesetzt werden. Konfigurieren Sie zunächst eine Vertrauensstellung zwischen Ihrer benutzerseitig zugewiesenen verwalteten Identität oder App in Microsoft Entra ID und einer SPIFFE-ID für eine externe Workload. Konfigurieren Sie dann Ihre externe Software-Workload, um ein Zugriffstoken vom Microsoft Identity Provider zu erhalten und auf durch Microsoft Entra geschützte Ressourcen zuzugreifen. Weitere Informationen finden Sie unter Workload-Identitätsverbund mit SPIFFE und SPIRE.
  • Erstellen einer neuen Dienstverbindung in Azure Pipelines (Vorschau). Erstellen Sie eine Azure Resource Manager-Dienstverbindung mithilfe des Workload-Identitätsverbunds.

Hinweis

Von Microsoft Entra ID ausgestellte Token können möglicherweise nicht für Identitätsflows im Verbund verwendet werden. Der Flow mit Anmeldeinformationen für eine Verbundidentität unterstützt keine Token, die von Microsoft Entra ID ausgestellt wurden.

Funktionsweise

Erstellen Sie eine Vertrauensstellung zwischen dem externen IdP und einer benutzerseitig zugewiesenen verwalteten Identität oder Anwendung in Microsoft Entra ID. Die Anmeldeinformation einer Verbundidentität werden verwendet, um anzugeben, welches Token vom externen Identitätsanbieter von Ihrer Anwendung oder verwalteten Identität als vertrauenswürdig eingestuft werden soll. Sie haben zwei Möglichkeiten, eine Verbundidentität zu konfigurieren:

Hinweis

Die Werte issuer, subject und audience von Verbundidentitäts-Anmeldeinformationen müssen unter Berücksichtigung der Groß- und Kleinschreibung mit den entsprechenden Werten issuer, subject und audience in dem Token übereinstimmen, das vom externen Identitätsanbieter (IdP) an Microsoft Entra ID gesendet wird, damit in diesem Szenario eine Autorisierung erfolgt. Weitere Informationen zu dieser Änderung finden Sie unter Neuigkeiten bei der Authentifizierung.

Der Arbeitsablauf (Workflow) zum Austauschen eines externen Tokens gegen ein Zugriffstoken ist jedoch in allen Fällen identisch. Das folgende Diagramm zeigt den allgemeinen Arbeitsablauf einer Workload, die ein externes Token gegen ein Zugriffstoken austauscht und dann auf durch Microsoft Entra geschützte Ressourcen zugreift.

Diagramm, das ein externes Token zeigt, das gegen ein Zugriffstoken ausgetauscht wurde und auf Azure zugreift

  1. Die externe Workload (z. B. ein GitHub-Aktions-Arbeitsablauf) fordert ein Token vom externen IdP an (z. B. GitHub).
  2. Der externe IdP stellt ein Token für die externe Workload aus.
  3. Die externe Workload (z. B. die Anmeldeaktion in einem GitHub-Workflow) sendet das Token an Microsoft Identity Platform und fordert ein Zugriffstoken an.
  4. Die Microsoft Identity Platform prüft die Vertrauensstellung für die benutzerseitig zugewiesene verwaltete Identität oder App-Registrierung und validiert das externe Token anhand der Aussteller-URL von Open ID Connect (OIDC) auf dem externen IdP.
  5. Wenn die Überprüfungen zufriedenstellend ausgeführt worden sind, gibt die Microsoft Identity Platform einen Zugriffstoken für die externe Workload aus.
  6. Die externe Workload greift auf durch Microsoft Entra geschützte Ressourcen mithilfe des Zugriffstokens der Microsoft Identity Platform zu. Ein GitHub-Aktions-Workflow verwendet z. B. das Zugriffstoken, um eine Web-App in einem Azure-App-Service zu veröffentlichen.

Die Microsoft Identitätsplattform speichert nur die ersten 100 Signaturschlüssel, wenn sie vom OIDC-Endpunkt des externen Identitätsanbieter heruntergeladen werden. Wenn der externe IdP mehr als 100 Signaturschlüssel zur Verfügung stellt, können bei der Verwendung des Workload-Identitätsverbunds Fehler auftreten.

Nächste Schritte

Erfahren Sie mehr über die Funktionsweise des Verbunds Workload Identity:

  • Hier erfahren Sie, wie Sie Anmeldeinformationen für Verbundidentität für eine benutzerseitig zugewiesene verwaltete Identität erstellen, löschen, einholen oder aktualisieren.
  • Hier erfahren Sie, wie Sie Anmeldeinformationen für Verbundidentität für eine App-Registrierung erstellen, löschen, einholen oder aktualisieren.
  • Erfahren Sie in der Übersicht über Workloadidentitäten, wie Sie eine Kubernetes-Workload so konfigurieren, dass sie ein Zugriffstoken vom Microsoft-Identitätsanbieter erhält und auf durch Microsoft Entra geschützte Ressourcen zugreifen kann.
  • Lesen Sie die GitHub Actions-Dokumentation, um mehr darüber zu erfahren, wie Sie Ihre GitHub Actions-Workflows konfigurieren, um ein Zugriffstoken vom Microsoft-Identitätsanbieter zu erhalten und auf durch Microsoft Entra geschützte Ressourcen zuzugreifen.
  • Wie nutzt Microsoft Entra ID die Gewährung von OAuth 2.0-Clientanmeldeinformationen und eine Clientassertion, die von einem anderen IdP ausgegeben wurde, um ein Token abzurufen.
  • Informationen zum erforderlichen Format von JWTs, die von externen Identitätsanbietern erstellt werden, finden Sie unter Assertionsformat.