Inicio de sesión en Azure PowerShell de forma no interactiva para escenarios de automatización
Una identidad administrada en Azure proporciona una manera segura y sin problemas de aplicaciones, servicios y herramientas de automatización para acceder a los recursos de Azure sin almacenar credenciales en el código o la configuración. A diferencia de las entidades de servicio, que requieren administración manual de credenciales, Azure controla automáticamente las identidades administradas y no expone secretos confidenciales. El uso de una identidad administrada es el procedimiento recomendado para escribir scripts de automatización segura porque simplifica la autenticación y minimiza el riesgo de pérdidas de credenciales. Las identidades administradas también ayudan a automatizar las tareas de administración de forma segura sin depender de identidades de usuario. Los permisos para las identidades administradas se administran a través de Microsoft Entra, lo que garantiza que solo tienen el acceso necesario a los recursos, lo que mejora la seguridad y el mantenimiento.
Importante
A partir de principios de 2025, la autenticación en Azure desde Azure PowerShell mediante una identidad de usuario de Id. de Microsoft Entra requerirá autenticación multifactor (MFA). Para más información, consulte Planning for mandatory multifactor authentication for Azure (Planeación de la autenticación multifactor obligatoria para Azure) y otros portales de administración.
Prerrequisitos
Inicio de sesión con una identidad administrada
Las identidades administradas son un tipo especial de entidad de servicio que proporciona servicios de Azure con una identidad administrada automáticamente. El uso de este tipo de identidad no requiere almacenar credenciales en la configuración ni el código para autenticarse en cualquier servicio de Azure que admita identidades administradas.
Hay dos tipos de identidades administradas:
- Identidad administrada asignada por el sistema
- Identidad administrada asignada por el usuario
Las identidades administradas proporcionan una manera segura de comunicarse con otros servicios de Azure sin que los desarrolladores necesiten administrar credenciales. También ayudan a mitigar el riesgo de pérdidas de credenciales.
Aquí se muestra cómo funcionan las identidades administradas en escenarios reales:
- Azure administra automáticamente la creación y eliminación de las credenciales usadas por la identidad administrada.
- Un servicio de Azure habilitado con una identidad administrada puede acceder de forma segura a otros servicios, como Azure Key Vault, Azure SQL Database, Azure Blob Storage, etc., mediante tokens de Microsoft Entra.
- Esta identidad se administra directamente dentro de Azure sin necesidad de aprovisionamiento adicional.
Las identidades administradas simplifican el modelo de seguridad evitando la necesidad de almacenar y administrar credenciales, y desempeñan un papel fundamental en las operaciones seguras en la nube al reducir el riesgo asociado con el control de secretos.
Identidad administrada asignada por el sistema
Azure crea automáticamente una identidad administrada asignada por el sistema para una instancia de servicio de Azure (como una máquina virtual de Azure, App Service o Azure Functions). Cuando se elimina la instancia de servicio, Azure limpia automáticamente las credenciales y la identidad asociada al servicio.
En el ejemplo siguiente se conecta mediante una identidad administrada asignada por el sistema del entorno de host. Si se ejecuta en una máquina virtual con una identidad administrada asignada, permite que el código inicie sesión con la identidad asignada.
Connect-AzAccount -Identity
Identidad administrada asignada por el usuario
Una identidad administrada asignada por el usuario es una identidad que se crea y administra en Microsoft Entra. Se puede asignar a una o varias instancias de servicio de Azure. El ciclo de vida de una identidad administrada asignada por el usuario se administra por separado de las instancias de servicio a las que está asignada.
Al usar una identidad administrada asignada por el usuario, debe especificar el parámetro AccountId y el parámetro Identity, como se muestra en el ejemplo siguiente.
Connect-AzAccount -Identity -AccountId <user-assigned-identity-clientId-or-resourceId>
Los siguientes comandos se conectan mediante la identidad administrada de myUserAssignedIdentity
. Agrega la identidad asignada por el usuario a la máquina virtual y, a continuación, se conecta mediante el ClientId de la identidad asignada por el usuario.
$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
Para más información, consulte Configuración de identidades administradas para recursos de Azure en una máquina virtual de Azure.
Inicio de sesión con un principal de servicio
Para iniciar sesión con una entidad de servicio, use el parámetro ServicePrincipal del cmdlet Connect-AzAccount
. También necesitará la siguiente información para la entidad de servicio:
- AppId
- Credenciales de inicio de sesión o acceso al certificado usado para crear el principal de servicio
- Id. de inquilino
La forma de iniciar sesión con una entidad de servicio depende de si está configurada para la autenticación basada en certificados o basada en contraseña.
Autenticación basada en certificados
Para obtener información sobre cómo crear una entidad de servicio para Azure PowerShell, consulte Creación de una entidad de servicio de Azure con Azure PowerShell.
La autenticación basada en certificados requiere Azure PowerShell para recuperar información de un almacén de certificados local basado en una huella digital de certificado.
Connect-AzAccount -ApplicationId $appId -Tenant $tenantId -CertificateThumbprint <thumbprint>
Al usar una entidad de servicio en lugar de una aplicación registrada, especifique el parámetro ServicePrincipal y proporcione el AppId de la entidad de servicio como valor para el parámetro ApplicationId.
Connect-AzAccount -ServicePrincipal -ApplicationId $servicePrincipalId -Tenant $tenantId -CertificateThumbprint <thumbprint>
En Windows PowerShell 5.1, el almacén de certificados se puede administrar e inspeccionar con el módulo PKI de. Para PowerShell 7.x y versiones posteriores, el proceso es diferente. Los scripts siguientes muestran cómo importar un certificado existente en el almacén de certificados al que PowerShell puede acceder.
Importación de un certificado en PowerShell 7.x y versiones posteriores
# 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()
Importación de un certificado en 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
Autenticación basada en contraseña
Cree una entidad de servicio para usarla con los ejemplos de esta sección. Para más información sobre cómo crear entidades de servicio, consulte Creación de una entidad de servicio de Azure con Azure PowerShell.
$sp = New-AzADServicePrincipal -DisplayName ServicePrincipalName
Cautela
El secreto del principal de servicio proporcionado se almacena en el archivo AzureRmContext.json
en tu perfil de usuario ($env:USERPROFILE\.Azure
). Asegúrese de que este directorio tiene las protecciones adecuadas.
Para obtener las credenciales de la entidad de servicio como un objeto, use el cmdlet Get-Credential
. Este cmdlet solicita un nombre de usuario y una contraseña. Use el AppId
del principal del servicio para el nombre de usuario y convierta su secret
en texto sin formato para la contraseña.
# 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
Para escenarios de automatización, debe crear credenciales a partir de la AppId
y la SecretText
de un principal de servicio.
$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
Use los procedimientos de almacenamiento de contraseñas adecuados al automatizar las conexiones del principal de servicio.
Consulte también
- Creación de una entidad de servicio de Azure con Azure PowerShell
- ¿Qué son las identidades administradas para los recursos de Azure?
- Asignar un acceso de identidad administrada a un recurso mediante PowerShell
- Visualiza la entidad de servicio de una identidad administrada mediante PowerShell
- Connect-AzAccount
- New-AzADServicePrincipal
- Get-Credential