Nicht-interaktives Anmelden für Automatisierungsszenarien bei Azure PowerShell

  • Artikel

Ein Dienstprinzipal in Azure ist ein nicht interaktives Konto, das eine Identität bereitstellt, die von Anwendungen, Diensten und Automatisierungstools für den Zugriff auf bestimmte Azure-Ressourcen verwendet wird. Die Authentifizierung mit einem Dienstprinzipal ist die beste Möglichkeit, sichere Skripts zu schreiben, da sie als Sicherheitsidentität mit zugewiesenen Berechtigungen fungieren, die festlegen, welche Aktionen durchgeführt werden können und auf welche Ressourcen zugegriffen werden kann. Dienstprinzipale helfen dabei, Verwaltungsaufgaben sicher zu automatisieren, ohne persönliche Benutzerkonten zu verwenden, und ermöglichen so einen sichereren und besser verwaltbaren Zugriff auf Azure-Ressourcen. Wie bei anderen Benutzerkonten, verwalten Sie ihre Berechtigungen mit Microsoft Entra ID. Indem für einen Dienstprinzipal nur die benötigten Berechtigungen gewährt werden, bleibt die Sicherheit Ihrer Automatisierungsskripts gewahrt.

Voraussetzungen

Anmelden mit einer verwalteten Identität

Verwaltete Identitäten sind ein spezieller Typ von Dienstprinzipal, die Azure-Dienste mit einer automatisch verwalteten Identität in Azure AD auf sichere Weise bereitstellen. Bei Verwendung dieser Art von Identität müssen keine Anmeldeinformationen in der Konfiguration oder im Code gespeichert werden, um sich bei Azure-Diensten, die verwaltete Identitäten unterstützen, zu authentifizieren.

Es gibt zwei Arten von verwalteten Identitäten:

  • Systemseitig zugewiesene verwaltete Identität
  • Benutzerseitig zugewiesene verwaltete Identität

Verwaltete Identitäten bieten eine sichere Möglichkeit, mit anderen Azure-Diensten zu kommunizieren, ohne dass Entwickler*innen Anmeldeinformationen verwalten müssen. Sie tragen auch dazu bei, das Risiko von Anmeldedatenlecks zu verringern.

So funktionieren verwaltete Identitäten in der Praxis:

  • Azure verwaltet automatisch die Erstellung und Löschung der Anmeldeinformationen, die von der verwalteten Identität verwendet werden.
  • Ein mit einer verwalteten Identität aktivierter Azure-Dienst kann mithilfe von Microsoft Entra-Token sicher auf andere Dienste zugreifen, z. B. Azure Key Vault, Azure SQL-Datenbank, Azure Blob Storage usw.
  • Diese Identität wird direkt in Azure verwaltet, ohne dass eine zusätzliche Bereitstellung erforderlich ist.

Verwaltete Identitäten vereinfachen das Sicherheitsmodell, weil sie die Speicherung und Verwaltung von Anmeldeinformationen überflüssig machen, und sie spielen eine entscheidende Rolle beim sicheren Cloudbetrieb, da sie das mit der Handhabung von Geheimnissen verbundene Risiko verringern.

Systemseitig zugewiesene verwaltete Identität

Azure erstellt automatisch eine systemseitig zugewiesene verwaltete Identität für eine Azure-Dienstinstanz (z. B. eine Azure-VM, App Service oder Azure Functions). Wenn die Dienstinstanz gelöscht wird, bereinigt Azure automatisch die zum Dienst gehörigen Anmeldeinformationen und die Identität.

In folgenden Beispiel wird mithilfe der systemseitig zugewiesene verwaltete Identität der Hostumgebung eine Verbindung hergestellt. Wenn das auf einer virtuellen Maschine mit einer zugewiesenen verwalteten Identität ausgeführt wird, ermöglicht es dem Code, sich mit der zugewiesenen Identität anzumelden.

 Connect-AzAccount -Identity

Benutzerseitig zugewiesene verwaltete Identität

Eine vom benutzerseitig zugewiesene verwaltete Identität ist eine Identität, die Sie in Microsoft Entra erstellen und verwalten. Sie kann einer oder mehreren Azure-Dienstinstanzen zugewiesen werden. Der Lebenszyklus einer benutzerseitig zugewiesenen Identität wird getrennt von den Dienstinstanzen verwaltet, denen sie zugewiesen ist.

Wenn Sie eine benutzerseitig zugewiesene verwaltete Identität verwenden, müssen Sie den Parameter AccountId und den Parameter Identity angeben, wie im folgenden Beispiel gezeigt.

 Connect-AzAccount -Identity -AccountId <user-assigned-identity-clientId-or-resourceId>

Mit den folgenden Befehlen wird eine Verbindung unter Verwendung der verwalteten Identität myUserAssignedIdentity hergestellt: Sie fügt dem virtuellen Computer die benutzerseitig zugewiesene Identität hinzu und stellt dann mithilfe der Client-ID ClientId der benutzerseitig zugewiesenen Identität eine Verbindung her.

$identity = Get-AzUserAssignedIdentity -ResourceGroupName myResourceGroup -Name myUserAssignedIdentity
Get-AzVM -ResourceGroupName contoso -Name testvm | Update-AzVM -IdentityType UserAssigned -IdentityId $identity.Id
Connect-AzAccount -Identity -AccountId $identity.ClientId # Run on the virtual machine

Account                              SubscriptionName TenantId                             Environment
-------                              ---------------- --------                             -----------
00000000-0000-0000-0000-000000000000 My Subscription  00000000-0000-0000-0000-000000000000 AzureCloud

Weitere Informationen finden Sie unter Konfigurieren von verwalteten Identitäten für Azure-Ressourcen auf einem virtuellen Azure-Computer mithilfe von PowerShell.

Anmelden mit einem Dienstprinzipal

Verwenden Sie für die Anmeldung mit einem Dienstprinzipal den Parameter ServicePrincipal für das Cmdlet Connect-AzAccount. Außerdem müssen folgende Informationen für den Dienstprinzipal konfiguriert werden:

  • AppId
  • Anmeldeinformationen oder Zugriff auf das Zertifikat, das zum Erstellen des Dienstprinzipals verwendet wird
  • Mandanten-ID

Wie Sie sich mit einem Dienstprinzipal anmelden, hängt davon ab, ob er für die zertifikatbasierte oder die kennwortbasierte Authentifizierung konfiguriert wurde.

Zertifikatbasierte Authentifizierung

Informationen zur Erstellung eines Dienstprinzipals für Azure PowerShell finden Sie unter Erstellen eines Azure-Dienstprinzipals mit Azure PowerShell.

Die zertifikatbasierte Authentifizierung erfordert, dass Azure PowerShell basierend auf einem Zertifikatfingerabdruck Informationen aus einem lokalen Zertifikatsspeicher abruft.

Connect-AzAccount -ApplicationId $appId -Tenant $tenantId -CertificateThumbprint <thumbprint>

Wenn Sie einen Dienstprinzipal anstelle einer registrierten Anwendung verwenden, geben Sie den Parameter ServicePrincipal und die AppId des Dienstprinzipals als Wert für den Parameter ApplicationId an.

Connect-AzAccount -ServicePrincipal -ApplicationId $servicePrincipalId -Tenant $tenantId -CertificateThumbprint <thumbprint>

In Windows PowerShell 5.1 kann der Zertifikatspeicher mit den PKI-Modul verwaltet und überprüft werden. Bei PowerShell 7.x und höher ist der Prozess anders. Die folgenden Skripts veranschaulichen, wie ein vorhandenes Zertifikat in den für PowerShell zugänglichen Zertifikatspeicher importiert wird.

Importieren eines Zertifikats in PowerShell Core 7.x und höher

# Import a PFX
$storeName = [System.Security.Cryptography.X509Certificates.StoreName]::My
$storeLocation = [System.Security.Cryptography.X509Certificates.StoreLocation]::CurrentUser
$store = [System.Security.Cryptography.X509Certificates.X509Store]::new($storeName, $storeLocation)
$certPath = <path to certificate>
$credentials = Get-Credential -Message "Provide PFX private key password"
$flag = [System.Security.Cryptography.X509Certificates.X509KeyStorageFlags]::Exportable
$certificate = [System.Security.Cryptography.X509Certificates.X509Certificate2]::new($certPath, $credentials.Password, $flag)
$store.Open([System.Security.Cryptography.X509Certificates.OpenFlags]::ReadWrite)
$store.Add($Certificate)
$store.Close()

Importieren eines Zertifikats in Windows PowerShell 5.1

# Import a PFX
$credentials = Get-Credential -Message 'Provide PFX private key password'
Import-PfxCertificate -FilePath <path to certificate> -Password $credentials.Password -CertStoreLocation cert:\CurrentUser\My

Kennwortbasierte Authentifizierung

Erstellen Sie einen Dienstprinzipal, den Sie für die Beispiele in diesem Abschnitt verwenden. Weitere Informationen zum Erstellen von Dienstprinzipalen finden Sie unter Erstellen eines Azure-Dienstprinzipals mit Azure PowerShell.

$sp = New-AzADServicePrincipal -DisplayName ServicePrincipalName

Achtung

Der bereitgestellte Dienstprinzipalschlüssel wird in der AzureRmContext.json-Datei in Ihrem Benutzerprofil ($env:USERPROFILE\.Azure) gespeichert. Stellen Sie sicher, dass dieses Verzeichnis ausreichend geschützt ist.

Verwenden Sie das Cmdlet Get-Credential, um die Anmeldeinformationen des Dienstprinzipals als Objekt abzurufen. Dieses Cmdlet fordert zur Eingabe von Benutzername und Kennwort auf. Verwenden Sie die AppId des Dienstprinzipals für den Benutzernamen, und konvertieren Sie dessen secret in Nur-Text für das Kennwort.

# Retrieve the plain text password for use with Get-Credential in the next command.
$sp.PasswordCredentials.SecretText

$pscredential = Get-Credential -UserName $sp.AppId
Connect-AzAccount -ServicePrincipal -Credential $pscredential -Tenant $tenantId

Für Automatisierungsszenarien müssen Sie Anmeldeinformationen aus der AppId und dem SecretText eines Dienstprinzipals erstellen:

$SecureStringPwd = $sp.PasswordCredentials.SecretText | ConvertTo-SecureString -AsPlainText -Force
$pscredential = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $sp.AppId, $SecureStringPwd
Connect-AzAccount -ServicePrincipal -Credential $pscredential -Tenant $tenantId

Verwenden Sie geeignete Methoden für die Kennwortspeicherung, wenn Sie Dienstprinzipalverbindungen automatisieren.

Siehe auch