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

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

  • Статья

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

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

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

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

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

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

Создание субъекта-службы

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

Важный

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

Заметка

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

В каталоге Microsoft Entra ID, где у пользовательского параметра "Пользователи могут зарегистрировать приложения" установлено значение "Нет", вы должны быть членом одной из следующих встроенных ролей 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: Другой объект с тем же значением для свойства identifierUris уже существует.", убедитесь, что субъект-служба (service principal) с тем же именем еще не существует.

Get-AzAdServicePrincipal -DisplayName ServicePrincipalName

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

Remove-AzAdServicePrincipal -DisplayName ServicePrincipalName

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

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

Get-AzADApplication -DisplayName ServicePrincipalName

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

Remove-AzADApplication -DisplayName ServicePrincipalName

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