Verwendung verwalteter Identitäten für Azure-Ressourcen zusammen mit virtuellen Azure-Computern
Verwaltete Identitäten für Azure-Ressourcen stellen für Azure-Dienste eine automatisch verwaltete Identität in Microsoft Entra ID bereit. Sie können diese Identität für die Authentifizierung bei jedem Dienst verwenden, der die Microsoft Entra-Authentifizierung unterstützt. Hierfür müssen keine Anmeldeinformationen im Code enthalten sein.
In diesem Artikel erfahren Sie, wie verwaltete Identitäten mit virtuellen Azure-Computern (Virtual Machines, VMs) verwendet werden.
Funktionsweise
Intern sind verwaltete Identitäten eine Sonderform von Dienstprinzipalen, die nur mit Azure-Ressourcen verwendet werden können. Wenn die verwaltete Identität gelöscht wird, wird automatisch auch der entsprechende Dienstprinzipal entfernt. Außerdem gilt: Wenn eine benutzerseitig oder systemseitig zugewiesenen Identität erstellt wird, gibt der Ressourcenanbieter der verwalteten Identität (Managed Identity Resource Provider, MSRP) intern ein Zertifikat für diese Identität aus.
Ihr Code kann eine verwaltete Identität zum Anfordern von Zugriffstoken für Dienste verwenden, die die Microsoft Entra-Authentifizierung unterstützen. Azure übernimmt die Weitergabe der von der Dienstinstanz verwendeten Anmeldeinformationen.
Das folgende Diagramm zeigt, wie verwaltete Dienstidentitäten mit virtuellen Azure-Computern funktionieren:
In der folgenden Tabelle sind die Unterschiede zwischen systemseitig zugewiesenen und benutzerseitig zugewiesenen verwalteten Identitäten aufgeführt:
| Eigenschaft | Systemseitig zugewiesene verwaltete Identität | Benutzerseitig zugewiesene verwaltete Identität |
|---|---|---|
| Erstellung | Als Teil einer Azure-Ressource (etwa eines virtuellen Azure-Computers oder einer Azure App Service-Instanz). | Als eigenständige Azure-Ressource. |
| Lebenszyklus | Gemeinsamer Lebenszyklus mit der Azure-Ressource, für die die verwaltete Identität erstellt wurde. Wenn die übergeordnete Ressource gelöscht wird, wird auch die verwaltete Identität gelöscht. |
Unabhängiger Lebenszyklus. Muss explizit gelöscht werden. |
| Gemeinsame Nutzung durch mehrere Azure-Ressourcen | Kann nicht freigegeben werden. Kann nur einer einzelnen Azure-Ressource zugeordnet werden. |
Gemeinsame Nutzung möglich. Die gleiche benutzerseitig zugewiesene verwaltete Identität kann mehreren Azure-Ressourcen zugeordnet werden. |
| Gängige Anwendungsfälle | Workloads innerhalb einer einzelnen Azure-Ressource. Workloads, für die unabhängige Identitäten erforderlich sind. Beispielsweise eine Anwendung, die auf einem einzelnen virtuellen Computer ausgeführt wird. |
Workloads, die auf mehrere Ressourcen ausgeführt werden und sich eine einzelne Identität teilen können. Workloads, die im Rahmen eines Bereitstellungsablaufs vorab für eine sichere Ressource autorisiert werden müssen. Workloads, bei denen Ressourcen häufig recycelt werden, die Berechtigungen aber konsistent bleiben sollen. Beispielsweise eine Workload, bei der mehrere virtuelle Computer auf die gleiche Ressource zugreifen müssen. |
Systemseitig zugewiesene verwaltete Identität
Azure Resource Manager empfängt eine Anforderung zur Aktivierung der vom System zugewiesenen verwalteten Identität auf einer VM.
Azure Resource Manager erstellt für die Identität des virtuellen Computers einen Dienstprinzipal in Microsoft Entra ID. Der Dienstprinzipal wird in dem Microsoft Entra-Mandanten erstellt, der von diesem Abonnement als vertrauenswürdig eingestuft wird.
Azure Resource Manager aktualisiert die VM-Identität mithilfe des Identitätsendpunkts von Azure Instance Metadata Service (für Windows und Linux) und stellt dem Endpunkt dabei die Client-ID und das Zertifikat des Dienstprinzipals zur Verfügung.
Wenn der virtuelle Computer über eine Identität verfügt, verwenden wir die Dienstprinzipalinformationen, um ihm Zugriff auf Azure-Ressourcen zu gewähren. Verwenden Sie zum Aufrufen von Azure Resource Manager die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) in Azure, um dem VM-Dienstprinzipal die entsprechende Rolle zuzuweisen. Gewähren Sie Ihrem Code zum Aufrufen von Key Vault Zugriff auf das spezifische Geheimnis oder den spezifischen Schlüssel in Key Vault.
Der auf dem virtuellen Computer ausgeführte Code kann ein Token vom Azure IMDS-Endpunkt (Instance Metadata Service) anfordern, auf das nur von dem virtuellen Computer aus zugegriffen werden kann:
http://169.254.169.254/metadata/identity/oauth2/token- Der Ressourcenparameter gibt den Dienst an, an den das Token gesendet wird. Verwenden Sie
resource=https://management.azure.com/für die Authentifizierung bei Azure Resource Manager. - Der API-Versionsparameter gibt die IMDS-Version an. Verwenden Sie mindestens „api-version=2018-02-01“.
Im folgenden Beispiel wird veranschaulicht, wie Sie mit CURL eine Anforderung an den lokalen Endpunkt der verwalteten Identität senden, um ein Zugriffstoken für Azure Instance Metadata Service abzurufen.
curl 'http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https%3A%2F%2Fstorage.azure.com%2F' -H Metadata:true- Der Ressourcenparameter gibt den Dienst an, an den das Token gesendet wird. Verwenden Sie
Über einen Microsoft Entra ID-Aufruf wird ein Zugriffstoken angefordert (siehe Schritt 5). Dabei werden die Client-ID und das Zertifikat verwendet, die in Schritt 3 konfiguriert wurden. Microsoft Entra ID gibt ein JWT-Zugriffstoken (JSON Web Token) zurück.
Anschließend sendet der Code das Zugriffstoken in einem Aufruf an einen Dienst, der die Microsoft Entra-Authentifizierung unterstützt.
Benutzerseitig zugewiesene verwaltete Identität
Azure Resource Manager empfängt eine Anforderung zur Erstellung einer vom Benutzer zugewiesenen verwalteten Identität.
Azure Resource Manager erstellt für die benutzerseitig zugewiesene verwaltete Identität einen Dienstprinzipal in Microsoft Entra ID. Der Dienstprinzipal wird in dem Microsoft Entra-Mandanten erstellt, der von diesem Abonnement als vertrauenswürdig eingestuft wird.
Azure Resource Manager empfängt eine Anforderung zum Konfigurieren der vom Benutzer zugewiesenen verwalteten Identität auf einer VM und aktualisiert den Identitätsendpunkt von Azure Instance Metadata Service mit der Client-ID und dem Zertifikat des Dienstprinzipals der vom Benutzer zugewiesenen verwalteten Identität.
Nachdem die vom Benutzer zugewiesene verwaltete Identität erstellt wurde, werden die Dienstprinzipalinformationen verwendet, um der Identität Zugriff auf Azure-Ressourcen zu gewähren. Verwenden Sie Azure RBAC zum Aufrufen von Azure Resource Manager, um dem Dienstprinzipal der vom Benutzer zugewiesenen Identität die entsprechende Rolle zuzuweisen. Gewähren Sie Ihrem Code zum Aufrufen von Key Vault Zugriff auf das spezifische Geheimnis oder den spezifischen Schlüssel in Key Vault.
Hinweis
Sie können diesen Schritt auch vor Schritt 3 ausführen.
Der auf dem virtuellen Computer ausgeführte Code kann ein Token vom Azure IMDS-Identitätsendpunkt (Instance Metadata Service) anfordern, auf das nur von dem virtuellen Computer aus zugegriffen werden kann:
http://169.254.169.254/metadata/identity/oauth2/tokenDer Ressourcenparameter gibt den Dienst an, an den das Token gesendet wird. Verwenden Sie
resource=https://management.azure.com/für die Authentifizierung bei Azure Resource Manager.Der Parameter
client_idgibt die Identität an, für die das Token angefordert wird. Dieser Wert ist erforderlich, um Mehrdeutigkeiten zu vermeiden, wenn auf einer einzelnen VM mehrere vom Benutzer zugewiesene Identitäten vorhanden sind. Die Client-ID finden Sie in der Übersicht der verwalteten Identität:
Der API-Versionsparameter gibt die Azure Instance Metadata Service-Version an. Verwenden Sie
api-version=2018-02-01oder höher.Im folgenden Beispiel wird veranschaulicht, wie Sie mit CURL eine Anforderung an den lokalen Endpunkt der verwalteten Identität senden, um ein Zugriffstoken für Azure Instance Metadata Service abzurufen.
curl 'http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https%3A%2F%2Fstorage.azure.com%2F&client_id=12345678-0000-0000-0000-000000000000' -H Metadata:true
Über einen Microsoft Entra ID-Aufruf wird ein Zugriffstoken angefordert (siehe Schritt 5). Dabei werden die Client-ID und das Zertifikat verwendet, die in Schritt 3 konfiguriert wurden. Microsoft Entra ID gibt ein JWT-Zugriffstoken (JSON Web Token) zurück.
Anschließend sendet der Code das Zugriffstoken in einem Aufruf an einen Dienst, der die Microsoft Entra-Authentifizierung unterstützt.
Nächste Schritte
Informationen zu den ersten Schritten mit der Funktion für verwaltete Identitäten für Azure-Ressourcen finden Sie in den folgenden Schnellstartanleitungen:
- Use a Windows VM system-assigned managed identity to access Resource Manager (Verwenden der systemseitig zugewiesenen verwalteten Identität einer Windows-VM für den Zugriff auf Resource Manager)
- Use a Linux VM system-assigned managed identity to access Resource Manager (Verwenden der systemseitig zugewiesenen verwalteten Identität einer Linux-VM für den Zugriff auf Resource Manager)