Partager via

Connectez-vous à Azure PowerShell de manière non interactive pour les scénarios d’automatisation

Une identité managée dans Azure offre un moyen sécurisé et transparent pour les applications, services et outils d’automatisation d’accéder aux ressources Azure sans stocker d’informations d’identification dans le code ou la configuration. Contrairement aux principaux de service, qui nécessitent une gestion manuelle des informations d’identification, Azure gère automatiquement les identités managées et n’expose pas de secrets sensibles. L’utilisation d’une identité managée est la meilleure pratique pour écrire des scripts d’automatisation sécurisés, car elle simplifie l’authentification et réduit le risque de fuites d’informations d’identification. Les identités managées permettent également d’automatiser les tâches de gestion en toute sécurité sans compter sur les identités utilisateur. Les autorisations pour les identités managées sont gérées via Microsoft Entra, ce qui garantit qu’elles disposent uniquement de l’accès nécessaire aux ressources, ce qui améliore la sécurité et la maintenance.

Important

À compter de septembre 2025, Azure PowerShell nécessite une authentification multifacteur (MFA) lors de la connexion avec une identité d’utilisateur Microsoft Entra ID. Cette modification améliore la sécurité, mais peut affecter les workflows d’automatisation qui s’appuient sur l’authentification par nom d’utilisateur et mot de passe. Pour plus d’informations, consultez l’impact de l’authentification multifacteur sur Azure PowerShell dans les scénarios d’automatisation.

Prerequisites

Connexion avec une identité managée

Les identités managées sont un type spécial de principal de service qui fournit des services Azure avec une identité managée automatiquement. L’utilisation de ce type d’identité ne nécessite pas de stockage d’informations d’identification dans la configuration ou le code pour s’authentifier auprès d’un service Azure prenant en charge les identités managées.

Il existe deux types d’identités managées :

  • Identité gérée attribuée par le système
  • Identité gérée assignée par l’utilisateur

Les identités managées offrent un moyen sécurisé de communiquer avec d’autres services Azure sans que les développeurs n’ont besoin de gérer les informations d’identification. Ils aident également à atténuer le risque de fuites d’informations d’identification.

Voici comment les identités managées fonctionnent dans des scénarios réels :

  • Azure gère automatiquement la création et la suppression des informations d’identification utilisées par l’identité managée.
  • Un service Azure activé avec une identité managée peut accéder en toute sécurité à d’autres services, tels qu’Azure Key Vault, Azure SQL Database, Stockage Blob Azure, etc., à l’aide de jetons Microsoft Entra.
  • Cette identité est gérée directement dans Azure sans nécessiter d’approvisionnement supplémentaire.

Les identités managées simplifient le modèle de sécurité en évitant la nécessité de stocker et de gérer les informations d’identification, et elles jouent un rôle crucial dans les opérations cloud sécurisées en réduisant le risque associé à la gestion des secrets.

Identité gérée attribuée par le système

Azure crée automatiquement une identité managée affectée par le système pour une instance de service Azure (comme une machine virtuelle Azure, App Service ou Azure Functions). Lorsque l’instance de service est supprimée, Azure nettoie automatiquement les informations d’identification et l’identité associée au service.

L’exemple suivant se connecte à l’aide d’une identité managée affectée par le système de l’environnement hôte. S’il est exécuté sur une machine virtuelle avec une identité managée affectée, il permet au code de se connecter à l’aide de l’identité affectée.

 Connect-AzAccount -Identity

Identité gérée assignée par l’utilisateur

Une identité managée affectée par l’utilisateur est une identité que vous créez et gérez dans Microsoft Entra. Il peut être affecté à une ou plusieurs instances de service Azure. Le cycle de vie d’une identité managée affectée par l’utilisateur est géré séparément des instances de service auxquelles elle est affectée.

Lorsque vous utilisez une identité managée affectée par l’utilisateur, vous devez spécifier les paramètres AccountId et Identity , comme illustré dans l’exemple suivant.

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

Les commandes suivantes se connectent à l’aide de l’identité managée de myUserAssignedIdentity. Il ajoute l’identité affectée par l’utilisateur à la machine virtuelle, puis se connecte à l’aide de l’ID client de l’identité affectée par l’utilisateur.

$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

Pour plus d’informations, consultez Configurer des identités managées pour les ressources Azure sur une machine virtuelle Azure.

Connexion avec un principal de service

Pour vous connecter avec un principal de service, utilisez le paramètre ServicePrincipal de l’applet Connect-AzAccount de commande. Vous aurez également besoin des informations suivantes pour le principal de service :

  • AppId
  • Informations d’identification de connexion ou accès au certificat utilisé pour créer le principal de service
  • ID du locataire

La façon dont vous vous connectez avec un principal de service dépend de sa configuration pour l’authentification basée sur un certificat ou par mot de passe.

Authentification basée sur un certificat

Pour savoir comment créer un principal de service pour Azure PowerShell, consultez Créer un principal de service Azure avec Azure PowerShell.

L’authentification basée sur un certificat nécessite qu’Azure PowerShell récupère les informations d’un magasin de certificats local en fonction d’une empreinte numérique de certificat.

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

Lorsque vous utilisez un principal de service au lieu d’une application inscrite, spécifiez le paramètre ServicePrincipal et fournissez l’AppId du principal de service comme valeur pour le paramètre ApplicationId .

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

Dans Windows PowerShell 5.1, le magasin de certificats peut être géré et inspecté avec le module PKI . Pour PowerShell 7.x et versions ultérieures, le processus est différent. Les scripts suivants montrent comment importer un certificat existant dans le magasin de certificats accessible par PowerShell.

Importer un certificat dans PowerShell 7.x et versions ultérieures

# 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()

Importer un certificat dans 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

L’authentification basée sur un mot de passe

Créez un principal de service à utiliser avec les exemples de cette section. Pour plus d’informations sur la création de principaux de service, consultez Créer un principal de service Azure avec Azure PowerShell.

$sp = New-AzADServicePrincipal -DisplayName ServicePrincipalName

Caution

Le secret du principal de service fourni est stocké dans le AzureRmContext.json fichier dans votre profil utilisateur ($env:USERPROFILE\.Azure). Vérifiez que ce répertoire dispose de protections appropriées.

Pour obtenir les informations d’identification du principal de service en tant qu’objet, utilisez l’applet Get-Credential de commande. Cette applet de commande demande un nom d’utilisateur et un mot de passe. Utilisez le principal de AppId service pour le nom d’utilisateur et convertissez-le secret en texte brut pour le mot de passe.

# 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

Pour les scénarios d’automatisation, vous devez créer des informations d’identification à partir d’un principal de AppId service et SecretText:

$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

Utilisez les pratiques de stockage de mot de passe appropriées lors de l’automatisation des connexions de principal de service.

Voir aussi

  • Last updated on