Kontextwechsel in Azure Automation

Kontextwechsel bedeutet, dass der Kontext in einem Prozess den Kontext in einem anderen Prozess ändert. Ein Azure Kontext ist eine Reihe von Informationen, die das Ziel von Azure PowerShell Cmdlets definieren. Der Kontext besteht aus den folgenden Eigenschaften:

Eigenschaft Beschreibung
Name Der Name des Kontexts.
Konto Der Benutzername oder der Dienstprinzipalname, der zur Authentifizierung der Kommunikation mit Azure verwendet wird.
Umgebung Stellt die Azure global oder eine der nationalen Azure Clouds dar, z. B. Azure Government. Sie können auch eine hybride Cloudplattform angeben, z. B. Azure Stack.
Abonnement Stellt das Azure-Abonnement dar, das die Ressourcen enthält, die Sie verwalten möchten.
Mandant Eine dedizierte und vertrauenswürdige Instanz von Microsoft Entra ID, die eine einzelne Organisation darstellt.
Anmeldeinformationen Die informationen, die von Azure verwendet werden, um Ihre Identität zu überprüfen und Ihre Autorisierung für den Zugriff auf Ressourcen in Azure zu bestätigen.

Wenn sich ein Konto anmeldet, das auf mehrere Abonnements zugreifen kann, kann jedes dieser Abonnements dem Kontext der Benutzer*innen hinzugefügt werden. Um das richtige Abonnement zu gewährleisten, müssen Sie es beim Verbinden angeben. Verwenden Sie z. B. Add-AzAccount -Credential $Cred -subscription 'aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e'. Es können jedoch Probleme auftreten, wenn Ihre Runbooks, die ein Abonnement verwalten, im gleichen Sandboxprozess wie Ihre anderen Runbooks ausgeführt werden, die Ressourcen in einem anderen Abonnement aus demselben Automation-Konto verwalten. Änderungen am Kontext, die von einem Runbook vorgenommen werden, können sich bei Verwendung des Standardkontexts auf Ihre anderen Runbooks auswirken. Da der Kontext Informationen wie die zu verwendenden Anmeldeinformationen und das Zielabonnement enthält, können Cmdlets auf das falsche Abonnement abzielen, was möglicherweise zu not found oder Berechtigungsfehlern führt. Dieses Problem wird als Kontextwechsel bezeichnet.

Verwalten von Azure Kontexten

Überprüfen Sie die folgenden Empfehlungen, um zu verhindern, dass Ihre Runbooks im falschen Abonnement auf Ressourcen zugreifen.

  1. Deaktivieren Sie das Speichern des Sandboxkontexts in Ihrem Automation-Runbook, indem Sie den folgenden Befehl am Anfang jedes Runbooks verwenden: Disable-AzContextAutosave -Scope Process.
  2. Die Azure PowerShell Cmdlets unterstützen den Parameter -DefaultProfile. Dieser Parameter wurde allen Az- und Azure Resource Manager-Cmdlets (AzureRM) hinzugefügt, um das Ausführen mehrerer Skripts im selben Prozess zu unterstützen, sodass Sie für jedes Cmdlet angeben können, welches Kontext verwendet werden soll. Speichern Sie Ihr Kontextobjekt in Ihrem Runbook, wenn es erstellt wird und jedes Mal, wenn es geändert wird. Verweisen Sie dann in jedem Aufruf, der mithilfe des Az- oder AzureRM-Cmdlets erfolgt, auf dieses Objekt. Beispielsweise $AzureContext = Set-AzContext -SubscriptionId $subID.
  3. Übergeben Sie das Kontextobjekt an das PowerShell-Cmdlet (z. B. Get-AzVM -ResourceGroupName "myGroup" -DefaultProfile $AzureContext).

Hier ist ein PowerShell-Runbook-Codeausschnitt, der eine vom System zugewiesene verwaltete Identität verwendet und den Empfehlungen zur Vermeidung von Kontextwechseln folgt.

# Ensures you do not inherit an AzContext in your runbook
Disable-AzContextAutosave -Scope Process

# Connect to Azure with system-assigned managed identity
$AzureContext = (Connect-AzAccount -Identity).context

# set and store context
$AzureContext = Set-AzContext -SubscriptionName $AzureContext.Subscription -DefaultProfile $AzureContext

# Pass context object - even though the context had just been set
# This is the step that guarantees the context will not be switched.
Get-AzVM -ResourceGroupName "resourceGroupName" -DefaultProfile $AzureContext | Select Name

Mögliche Symptome

Wenn Sie diesen Empfehlungen nicht nachkommen, kann es zwar sein, dass kein Problem auftritt, die Möglichkeit besteht aber dennoch. Das zugrunde liegende Problem in dieser Situation ist das Timing; es hängt davon ab, was jedes Runbook zu dem Zeitpunkt macht, zu dem das andere Runbook seinen Kontext wechselt. Im Folgenden finden Sie einige mögliche Fehlermeldungen. Diese Fehlermeldungen können jedoch durch nicht kontextabhängige Wechselbedingungen verursacht werden.

The subscription named <subscription name> cannot be found.

Get-AzVM : The client '<clientid>' with object id '<objectid>' does not have authorization to perform action 'Microsoft.Compute/virtualMachines/read' over scope '/subscriptions/<subscriptionIdOfSubscriptionWhichDoesntContainTheVM>/resourceGroups/REsourceGroupName/providers/Microsoft.Compute/virtualMachines/VMName '.
   ErrorCode: AuthorizationFailed
   StatusCode: 403
   ReasonPhrase: Forbidden Operation
   ID : <AGuidRepresentingTheOperation> At line:51 char:7 + $vm = Get-AzVM -ResourceGroupName $ResourceGroupName -Name $UNBV... +

Get-AzureRmResource : Resource group "SomeResourceGroupName" could not be found.
... resources = Get-AzResource -ResourceGroupName $group.ResourceGro ...
                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : CloseError: (:) [Get-AzResource], CloudException
    + FullyQualifiedErrorId : Microsoft.Azure.Commands.ResourceManager.Cmdlets.Implementation.GetAzureResourceCmdlet

Nächste Schritte

  • Last updated on