Поделиться через

Вход в Azure PowerShell без интерактивного взаимодействия для сценариев автоматизации

  • Статья

Управляемое удостоверение в Azure обеспечивает безопасный и удобный способ для приложений, служб и средств автоматизации для доступа к ресурсам Azure без хранения учетных данных в коде или конфигурации. В отличие от служебных принципов, требующих ручного управления учетными данными, Azure автоматически обрабатывает управляемые идентификационные данные и не раскрывает конфиденциальные секреты. Использование управляемого удостоверения — это рекомендация по написанию скриптов безопасной автоматизации, так как она упрощает проверку подлинности и снижает риск утечки учетных данных. Управляемые идентификаторы также помогают безопасно автоматизировать задачи управления без использования пользовательских удостоверений. Разрешения для управляемых удостоверений личности управляются через Microsoft Entra, обеспечивая только необходимый доступ к ресурсам и повышая как безопасность, так и удобство обслуживания.

Важный

Начиная с начала 2025 года аутентификация в Azure из Azure PowerShell с помощью удостоверения пользователя идентификатора Microsoft Entra ID потребует многофакторной проверки подлинности (MFA). Дополнительные сведения см. в статье Влияние многофакторной проверки подлинности на Azure PowerShell в сценариях автоматизации.

Необходимые условия

Вход с использованием управляемой идентичности

Управляемые удостоверения — это особый тип субъекта-службы, предоставляющего службы Azure автоматически управляемым удостоверением. Использование этого типа удостоверения не требует хранения учетных данных в конфигурации или коде для проверки подлинности в любой службе Azure, поддерживающей управляемые удостоверения.

Существует два типа управляемых удостоверений:

  • Назначаемый системой управляемый идентификатор
  • Управляемое удостоверение, назначаемое пользователем

Управляемые удостоверения обеспечивают безопасный способ взаимодействия с другими службами Azure без необходимости управлять учетными данными. Они также помогают снизить риск утечки учетных данных.

Вот как работают управляемые удостоверения в реальных сценариях:

  • Azure автоматически управляет созданием и удалением учетных данных, используемых управляемым удостоверением.
  • Служба Azure, оснащенная управляемым удостоверением, может безопасно получить доступ к другим службам, таким как Azure Key Vault, Azure SQL Database, Azure Blob Storage и т. д., с помощью токенов Microsoft Entra.
  • Это идентификатор управляется непосредственно в Azure без необходимости дополнительного предоставления.

Управляемые удостоверения упрощают модель безопасности, избегая необходимости хранить учетные данные и управлять ими, и они играют важную роль в безопасных облачных операциях, уменьшая риск, связанный с обработкой секретов.

Идентификация, управляемая системой

Azure автоматически создает системно назначаемое управляемое удостоверение для экземпляра службы Azure (например, виртуальной машины Azure, службы приложений или функций Azure). При удалении экземпляра службы Azure автоматически очищает учетные данные и удостоверение, связанное со службой.

Следующий пример подключается с использованием управляемой идентичности, назначенной системой, в хостинговой среде. При выполнении на виртуальной машине с назначенным управляемым удостоверением код позволяет выполнить вход с помощью назначенного удостоверения.

 Connect-AzAccount -Identity

Управляемое удостоверение, назначаемое пользователем

Управляемое удостоверение, назначаемое пользователем, — это удостоверение, создаваемое и управляемое в Microsoft Entra. Его можно назначить одному или нескольким экземплярам службы Azure. Жизненный цикл управляемого удостоверения, назначаемого пользователем, управляется отдельно от экземпляров служб, которым он назначен.

При использовании управляемого удостоверения, назначаемого пользователем, необходимо указать параметры AccountId и Identity, как показано в следующем примере.

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

Следующие команды подключаются с помощью управляемого идентификатора myUserAssignedIdentity. Он добавляет удостоверение, назначаемое пользователем, в виртуальную машину, а затем подключается с помощью ClientId удостоверения, назначаемого пользователем.

$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

Дополнительные сведения см. в статье Настройка управляемых удостоверений для ресурсов Azure на виртуальной машине Azure.

Вход с помощью учетной записи службы

Чтобы выполнить вход с помощью служебного принципала, используйте параметр ServicePrincipal командлета Connect-AzAccount. Вам также потребуется следующая информация для служебного принципала:

  • AppId
  • Учетные данные входа или доступ к сертификату, используемому для создания служебного принципала
  • Идентификатор клиента

Способ входа с использованием учетной записи службы зависит от того, настроена ли учетная запись на проверку подлинности с использованием сертификатов или паролей.

Проверка подлинности на основе сертификатов

Сведения о создании субъекта-службы для Azure PowerShell см. в статье Создание субъекта-службы Azure с помощьюAzure PowerShell.

Для проверки подлинности на основе сертификатов Azure PowerShell требуется получить сведения из локального хранилища сертификатов на основе отпечатка сертификата.

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

При использовании субъекта-службы вместо зарегистрированного приложения укажите параметр ServicePrincipal и укажите идентификатор приложения субъекта-службы в качестве значения параметра ApplicationId.

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

В Windows PowerShell 5.1 хранилище сертификатов можно управлять и проверять с помощью модуля PKI. Для PowerShell 7.x и более поздних версий процесс отличается. В следующих сценариях показано, как импортировать существующий сертификат в хранилище сертификатов, доступном PowerShell.

Импорт сертификата в PowerShell 7.x и более поздних версий

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

Импорт сертификата в 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

Проверка подлинности на основе паролей

Создайте служебный принципал для использования с примерами в этом разделе. Дополнительные сведения о создании субъектов-служб см. в статье Создание субъекта-службы Azure с помощьюAzure PowerShell.

$sp = New-AzADServicePrincipal -DisplayName ServicePrincipalName

Осторожность

Предоставленный секрет учётной записи службы хранится в файле AzureRmContext.json в профиле пользователя ($env:USERPROFILE\.Azure). Убедитесь, что этот каталог имеет соответствующие защиты.

Чтобы получить учетные данные служебного принципала в качестве объекта, используйте командлет Get-Credential. Этот командлет запрашивает имя пользователя и пароль. Используйте AppId принципала службы для имени пользователя и преобразуйте его secret в текстовый формат для пароля.

# 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

Для сценариев автоматизации необходимо создать учетные данные из служебного принципала AppId и 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

При автоматизации подключений учетной записи службы используйте рекомендованные методики хранения паролей.

См. также