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


Создание сервисного принципала Azure с помощью Azure PowerShell

Автоматические средства, использующие службы Azure, всегда должны иметь ограниченные разрешения. Instead of having applications sign in as a fully privileged user, Azure offers service principals.

An Azure service principal is an identity created for use with applications, hosted services, and automated tools to access Azure resources. Такой доступ ограничен ролями, назначенными служебному принципалу, что позволяет вам контролировать, к каким ресурсам можно получить доступ и на каком уровне. For security reasons, it's always recommended to use service principals with automated tools rather than allowing them to log in with a user identity.

This article shows you the steps for creating, getting information about, and resetting a service principal with Azure PowerShell.

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

При создании учетной записи службы с помощью команды New-AzADServicePrincipal в выходные данные включаются учетные данные, которые необходимо защитить. В качестве альтернативы можно использовать управляемые удостоверения, чтобы не работать с учетными данными.

Предпосылки

Создайте сервисного принципала

Create a service principal with the New-AzADServicePrincipal cmdlet. При создании учетной записи службы вы выбираете тип аутентификации для входа, который она использует.

Это важно

Начиная с модуля Az PowerShell версии 7.x, New-AzADServicePrincipal больше не назначает роль Contributor служебному принципалу по умолчанию. Чтобы назначить определенную роль сервисному принципалу, см. статью Действия по назначению роли.

Примечание.

Если у вашей учетной записи нет разрешения на создание субъекта-службы, New-AzADServicePrincipal возвращает сообщение об ошибке, которое содержит текст "Недостаточно привилегий для завершения операции". Чтобы создать сервисный принципал, обратитесь к администратору Microsoft Entra.

В каталоге Microsoft Entra ID, где для параметра Пользователи могут регистрировать приложения установлено значение Нет, вы должны быть членом одной из следующих встроенных ролей Microsoft Entra ID (которые имеют действие: microsoft.directory/applications/createAsOwner или microsoft.directory/applications/create):

Дополнительные сведения о параметрах пользователей в идентификаторе Microsoft Entra см. в разделе "Ограничение возможностей создания приложений".

Существует два типа проверки подлинности для субъектов-служб: аутентификация на основе паролей и проверка подлинности на основе сертификатов.

Аутентификация на основе пароля

Это важно

The default role for a password-based authentication service principal is Contributor. Эта роль имеет полные разрешения на чтение и запись в учетной записи Azure. Сведения о назначении ролей см. в разделе Управление ролями субъекта-службы.

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

$sp = New-AzADServicePrincipal -DisplayName ServicePrincipalName

Возвращаемый объект содержит свойство PasswordCredentials.SecretText, содержащее созданный пароль. Make sure that you store this value somewhere secure to authenticate with the service principal. Его значение не будет отображаться в выходных данных консоли. If you lose the password, reset the service principal credentials.

Следующий код позволяет экспортировать секрет:

$sp.PasswordCredentials.SecretText

The object returned from New-AzADServicePrincipal contains the Id and DisplayName members, either of which can be used for sign in with the service principal.

Это важно

Signing in with a service principal requires the tenant ID which the service principal was created under. Чтобы получить данные об активном клиенте при создании субъекта-службы, выполните следующую команду сразу же после создания субъекта-службы:

(Get-AzContext).Tenant.Id

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

Это важно

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

Service principals using certificate-based authentication are created with the CertValue parameter. Этот параметр принимает строку ASCII открытого сертификата в кодировке Base64 Это представлено PEM-файлом или текстовым кодом CRT или CER. Двоичные кодировки общедоступного сертификата не поддерживаются. В этих инструкциях предполагается, что у вас уже есть сертификат.

$cert = <public certificate as base64-encoded string>
$sp = New-AzADServicePrincipal -DisplayName ServicePrincipalName -CertValue $cert

The object returned from New-AzADServicePrincipal contains the Id and DisplayName properties, either of which can be used for sign in with the service principal. Clients which sign in with the service principal also need access to the certificate's private key.

Это важно

Signing in with a service principal requires the tenant ID which the service principal was created under. Чтобы получить данные об активном клиенте при создании субъекта-службы, выполните следующую команду сразу же после создания субъекта-службы:

(Get-AzContext).Tenant.Id

Get an existing service principal

Список сервисных принципалов для текущего арендатора можно получить с помощью Get-AzADServicePrincipal. By default this command returns all service principals in a tenant. Получение результатов для больших организаций может занять много времени. Вместо этого рекомендуется использовать один из необязательных аргументов фильтрации на стороне сервера:

  • DisplayNameBeginsWith requests service principals that have a prefix that match the provided value. Отображаемое имя сервиса-принципала — это значение, заданное при создании с помощью параметра DisplayName.
  • DisplayName  — запрашивает точное совпадение имени принципала службы.

Управление ролями сервисного принципала

Azure PowerShell has the following cmdlets to manage role assignments:

Дополнительные сведения об управлении доступом на основе ролей (RBAC) и ролях см. в RBAC: Встроенные роли.

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

New-AzRoleAssignment -ApplicationId <service principal application ID> -RoleDefinitionName 'Reader'
Remove-AzRoleAssignment -ObjectId <service principal object ID> -RoleDefinitionName 'Contributor'

Это важно

Role assignment cmdlets don't take the service principal object ID. They take the associated application ID, which is generated at creation time. To get the application ID for a service principal, use Get-AzADServicePrincipal.

Примечание.

Если у вашей учетной записи нет разрешения на назначение роли, появится сообщение об ошибке о том, что у вашей учетной записи нет авторизации для выполнения действия "Microsoft.Authorization/roleAssignments/write". Чтобы управлять ролями, обратитесь к администратору Microsoft Entra.

Добавление роли не ограничивает назначенные ранее разрешения. When restricting a service principal's permissions, the Contributor role should be removed.

Изменения можно проверить, перечислив назначенные роли:

Get-AzRoleAssignment -ServicePrincipalName ServicePrincipalName

Sign in using a service principal

Войдите в систему, чтобы протестировать учетные данные и разрешения нового служебного принципала. To sign in with a service principal, you need the applicationId value associated with it, and the tenant it's created under.

To sign in with a service principal using a password:

# Use the application ID as the username, and the secret as password
$credentials = Get-Credential
Connect-AzAccount -ServicePrincipal -Credential $credentials -Tenant <tenant ID>

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

Connect-AzAccount -ServicePrincipal -Tenant <TenantId> -CertificateThumbprint <Thumbprint> -ApplicationId <ApplicationId>

Инструкции по импорту сертификата в хранилище учетных данных, доступное из PowerShell, см. в разделе аутентификация на основе сертификатов.

Reset credentials

If you forget the credentials for a service principal, use New-AzADSpCredential to add a new credential with a random password. This cmdlet doesn't support user-defined credentials when resetting the password.

Это важно

Перед назначением новых учетных данных может потребоваться удалить существующие учетные данные, чтобы запретить вход с ними. Для выполнения этой задачи используйте командлет Remove-AzADSpCredential:

Remove-AzADSpCredential -DisplayName ServicePrincipalName
$newCredential = New-AzADSpCredential -ServicePrincipalName ServicePrincipalName

Устранение неполадок

Если вы получаете ошибку New-AzADServicePrincipal: Another object with the same value for property identifierUris already exists (New-AzADServicePrincipal: другой объект с таким же значением свойства identifierUris уже существует), убедитесь, что субъект-служба с таким же именем не существует.

Get-AzAdServicePrincipal -DisplayName ServicePrincipalName

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

Remove-AzAdServicePrincipal -DisplayName ServicePrincipalName

Эта ошибка также может возникнуть, если вы ранее создали служебный принципал для приложения Azure Active Directory. If you remove the service principal, the application is still available. This application prevents you from creating another service principal with the same name.

В следующем примере можно убедиться, что приложение Microsoft Entra с тем же именем не существует:

Get-AzADApplication -DisplayName ServicePrincipalName

Если приложение с тем же именем существует и больше не требуется, его можно удалить с помощью следующего примера.

Remove-AzADApplication -DisplayName ServicePrincipalName

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