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

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

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

Субъект-служба Azure — это удостоверение, созданное для использования с приложениями, размещенными службами и автоматизированными средствами для доступа к ресурсам Azure. Этот доступ ограничен ролями, назначенными субъекту-службе, что позволяет контролировать доступ к ресурсам и на каком уровне. По соображениям безопасности всегда рекомендуется использовать субъекты-службы с автоматизированными средствами, а не разрешать им войти с помощью удостоверения пользователя.

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

Caution

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

Предпосылки

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

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

Это важно

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

Замечание

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

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

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

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

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

Это важно

Роль по умолчанию для субъекта-службы проверки подлинности на основе паролей — участник. Эта роль имеет полные разрешения на чтение и запись в учетную запись Azure. Сведения об управлении назначениями ролей см. в разделе "Управление ролями субъекта-службы".

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

$sp = New-AzADServicePrincipal -DisplayName ServicePrincipalName

Возвращаемый объект содержит PasswordCredentials.SecretText свойство, содержащее созданный пароль. Убедитесь, что вы храните это значение где-то безопасно для проверки подлинности с помощью субъекта-службы. Его значение не будет отображаться в выходных данных консоли. Если пароль потерян, сбросьте учетные данные субъекта-службы.

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

$sp.PasswordCredentials.SecretText

Объект, возвращаемый из New-AzADServicePrincipal объекта, содержит Id элементы и DisplayName элементы, из которых можно использовать для входа с помощью субъекта-службы.

Это важно

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

(Get-AzContext).Tenant.Id

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

Это важно

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

Субъекты-службы, использующие проверку подлинности на основе сертификатов, создаются с параметром CertValue . Этот параметр принимает строку ASCII в кодировке Base64 общедоступного сертификата. Это представлено PEM-файлом или текстовым кодом CRT или CER. Двоичные кодировки общедоступного сертификата не поддерживаются. В этих инструкциях предполагается, что у вас уже есть сертификат.

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

Объект, возвращаемый из New-AzADServicePrincipal объекта, содержит Id и DisplayName свойства, из которых можно использовать для входа с помощью субъекта-службы. Клиентам, которые входят в систему с помощью субъекта-службы, также требуется доступ к закрытому ключу сертификата.

Это важно

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

(Get-AzContext).Tenant.Id

Получение существующего субъекта-службы

Список субъектов-служб для активного клиента можно получить с помощью Get-AzADServicePrincipal. По умолчанию эта команда возвращает все субъекты-службы в клиенте. Для крупных организаций может потребоваться много времени для возврата результатов. Вместо этого рекомендуется использовать один из необязательных аргументов фильтрации на стороне сервера:

  • DisplayNameBeginsWith запрашивает субъекты-службы, имеющие префикс , соответствующий предоставленному значению. Отображаемое имя субъекта-службы — это значение, DisplayName заданное во время создания.
  • DisplayName запрашивает точное совпадение имени субъекта-службы.

Управление ролями субъекта-службы

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

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

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

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

Это важно

Командлеты назначения ролей не принимают идентификатор объекта субъекта-службы. Они принимают связанный идентификатор приложения, который создается во время создания. Чтобы получить идентификатор приложения для субъекта-службы, используйте Get-AzADServicePrincipal.

Замечание

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

Добавление роли не ограничивает ранее назначенные разрешения. При ограничении разрешений субъекта-службы роль участника должна быть удалена.

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

Get-AzRoleAssignment -ServicePrincipalName ServicePrincipalName

Вход с помощью субъекта-службы

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

Чтобы войти с помощью субъекта-службы с помощью пароля:

# 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, см. в разделе "Проверка подлинности на основе сертификатов"

Сброс учетных данных

Если вы забыли учетные данные для субъекта-службы, используйте New-AzADSpCredential , чтобы добавить новые учетные данные со случайным паролем. Этот командлет не поддерживает пользовательские учетные данные при сбросе пароля.

Это важно

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

Remove-AzADSpCredential -DisplayName ServicePrincipalName

$newCredential = New-AzADSpCredential -ServicePrincipalName ServicePrincipalName

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

Если вы получите сообщение об ошибке "New-AzADServicePrincipal: другой объект с тем же значением для идентификатора свойстваUris уже существует". Убедитесь, что субъект-служба с тем же именем еще не существует.

Get-AzAdServicePrincipal -DisplayName ServicePrincipalName

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

Remove-AzAdServicePrincipal -DisplayName ServicePrincipalName

Эта ошибка также может возникать при создании субъекта-службы для приложения Azure Active Directory. Если удалить субъект-службу, приложение по-прежнему доступно. Это приложение предотвращает создание другого субъекта-службы с тем же именем.

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

Get-AzADApplication -DisplayName ServicePrincipalName

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

Remove-AzADApplication -DisplayName ServicePrincipalName

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

  • Last updated on