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 un accès plus sécurisé et gérable aux ressources Azure. À l’instar des autres comptes d’utilisateur, vous gérez leurs autorisations avec Microsoft Entra. En accordant uniquement les autorisations nécessaires à un principal de service, vous vous assurez que vos scripts d’automatisation restent sécurisés.

Prérequis

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 ni de 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 administrées :

  • Identité managée affectée par le système
  • Identité managée affecté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’aient besoin de gérer les informations d’identification. Elles 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. 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é managée affecté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). Si l’instance de service est supprimée, Azure efface automatiquement les informations d’identification et l’identité associées 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é managée affecté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. Elle peut être attribuée à une ou plusieurs instances d’un 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 Azure auxquelles elle est affectée.

Lorsque vous utilisez une identité managée affectée par l’utilisateur, vous devez spécifier le paramètre AccountId et le paramètre Identity, comme indiqué 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 du 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 se connecter avec un principal de service, utilisez le paramètre ServicePrincipal de la cmdlet Connect-AzAccount. 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
  • Tenant ID

La façon dont vous vous connectez à un principal de service dépende la configuration de l’authentification, basée sur un certificate ou sur un mot de passe.

Authentification par certificat

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

L’authentification par certificat nécessite qu’Azure PowerShell récupère des informations à partir d’un magasin de certificats local en se basant sur l’empreinte du certificat.

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

Quand vous utilisez un principal de service au lieu d’une application inscrite, spécifiez le paramètre ServicePrincipal et fournissez l’ID d’application du principal de service comme valeur du 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 qui est accessible via 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 dans les exemples de cette section. Pour plus d’informations sur la création de principaux de service, consultez Créer un principal de service 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). Assurez-vous que ce répertoire dispose des protections appropriées.

Pour obtenir les informations d’identification du principal de service en tant qu’objet, utilisez la cmdlet Get-Credential. Cette cmdlet demande un nom d’utilisateur et un mot de passe. Utilisez la valeur AppId du principal de service comme 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 valeurs AppId et SecretText d’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