Partager via

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

  • Article

Un principal de service dans Azure est un compte non interactif qui fournit une identité utilisée par les applications, les services et les outils d’automatisation pour accéder à des ressources Azure spécifiques. L’authentification auprès d’un principal de service est la meilleure façon d’écrire des scripts sécurisés, car ils agissent en tant qu’identité de sécurité avec des autorisations attribuées qui régissent les actions qui peuvent être effectuées et quelles ressources sont accessibles. Les principaux de service permettent d’automatiser en toute sécurité les tâches de gestion sans utiliser de comptes d’utilisateur personnels, ce qui facilite l’accès plus sécurisé et gérable aux ressources Azure. Comme d’autres comptes d’utilisateur, vous gérez leurs autorisations avec Microsoft Entra. En accordant un principal de service uniquement aux autorisations dont il a besoin, vos scripts d’automatisation restent sécurisés.

Conditions préalables

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 assignée par le système
  • Identité gérée attribué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 attribué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 assignée par l'utilisateur, vous devez spécifier le paramètre AccountId et le paramètre Identity, comme 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'ClientId 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 de commande Connect-AzAccount. Vous aurez également besoin des informations suivantes pour le principal de service :

  • AppId
  • Informations d’identification pour la connexion ou accès au certificat utilisé pour créer le principal de service
  • ID de 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

Authentification par 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

Attention

Le secret du principal de service fourni est stocké dans le fichier AzureRmContext.json de 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 de commande Get-Credential. Cette applet de commande demande un nom d’utilisateur et un mot de passe. Utilisez le AppId du principal de service pour le nom d’utilisateur et convertissez son 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 des AppId et des SecretTextd’un principal de service :

$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