Примечание
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Автоматические средства, использующие службы Azure, всегда должны иметь ограниченные разрешения, чтобы обеспечить безопасность ресурсов Azure. Поэтому вместо того, чтобы приложения входили в систему в качестве полностью привилегированного пользователя, Azure предлагает основные параметры службы. Субъект-служба Azure — это удостоверение, созданное для использования с приложениями, размещенными службами и автоматизированными средствами. Это удостоверение используется для доступа к ресурсам.
В этом руководстве описано следующее:
- Создание субъекта-службы
- Вход с помощью учетной записи службы и пароля
- Вход с помощью учетной записи службы и сертификата
- Управление ролями субъекта-службы
- Создание ресурса Azure с помощью служебного принципала
- Сброс учетных данных учетной записи службы
Требования
- Для создания учетной записи службы в подписке необходимо иметь разрешения
User Access Administrator
илиRole Based Access Control Administrator
. Для получения списка ролей, доступных для управления доступом, основанного на ролях Azure (Azure RBAC), см. Встроенные роли Azure.
Используйте среду Bash в Azure Cloud Shell. Дополнительные сведения см. в кратком руководстве по Bash в Azure Cloud Shell.
Если вы предпочитаете выполнять справочные команды CLI локально, установите Azure CLI. Если вы работаете в Windows или macOS, Azure CLI можно запустить в контейнере Docker. Дополнительные сведения см. в статье Как запустить Azure CLI в контейнере Docker.
Если вы используете локальную установку, выполните вход в Azure CLI с помощью команды az login. Чтобы выполнить аутентификацию, следуйте инструкциям в окне терминала. Сведения о других возможностях, доступных при входе, см. в статье Вход с помощью Azure CLI.
Установите расширение Azure CLI при первом использовании, когда появится соответствующий запрос. Дополнительные сведения о расширениях см. в статье Использование расширений с Azure CLI.
Выполните команду az version, чтобы узнать установленную версию и зависимые библиотеки. Чтобы обновиться до последней версии, выполните команду az upgrade.
Создание субъекта-службы
Используйте команду az ad sp create-for-rbac Azure CLI для создания субъекта-службы. В этом примере параметр не указан --name
, поэтому имя, содержащее метку времени, создается автоматически.
az ad sp create-for-rbac
Выходная консоль:
{
"appId": "myAppId",
"displayName": "myServicePrincipalName",
"password": "myServicePrincipalPassword",
"tenant": "myTentantId"
}
Если вы не придерживаетесь соглашений об именовании ресурсов и планируете создать роль и область для нового субъекта-службы позже, az ad sp create-for-rbac
команда без параметров является приемлемым решением. Однако без роли и области новый субъект-служба не имеет доступа к ресурсам. Это просто существует.
При создании субъекта-службы без параметров выполните следующие действия:
- Запишите пароль, назначенный системой, так как вы не сможете получить его снова. Если вы потеряли пароль, сбросьте его с помощью az ad sp credential reset, как описано в "Сброс учетных данных субъекта-службы".
- Задайте назначение ролей для нового субъекта-службы с помощью az role assignment create , как описано в разделе "Управление ролями субъекта-службы".
Примечание.
Если у вашей учетной записи нет разрешения на создание учетной записи службы, az ad sp create-for-rbac
возвращает сообщение об ошибке с текстом "Недостаточно привилегий для завершения операции". Чтобы создать сервисный принципал, обратитесь к администратору Microsoft Entra.
В каталоге идентификатора Microsoft Entra ID, где пользователи могут зарегистрировать приложения , установлено значение No, необходимо быть членом одной из следующих встроенных ролей Microsoft Entra ID (которые имеют действие: microsoft.directory/applications/createAsOwner
или microsoft.directory/applications/create
):
- Разработчик приложений
- Администратор приложений
- Администратор облачных приложений
- Глобальный администратор
- Администратор гибридной идентичности
Дополнительные сведения о параметрах пользователей в идентификаторе Microsoft Entra см. в разделе "Ограничение возможностей создания приложений".
Создание субъекта-службы с ролью и областью
Рекомендуется всегда назначать конкретные --role
и --scopes
при создании учетной записи службы. Выполните следующие действия:
Определите правильную роль.
При определении роли всегда используйте принцип наименьшей привилегии. Например, не предоставляйте служебному принципалу
contributor
разрешения на подписку, если ему нужно только получить доступ к хранилищу Azure в группе ресурсов. Рассмотрим специализированную роль, такую как вкладчик данных объектов BLOB-хранилища. Полный список доступных ролей в Azure RBAC см. в статье Встроенные роли Azure.Получите значение параметра scopes.
Найдите и скопируйте Resource ID ресурса Azure, к которому должна получить доступ новая учетная запись. Обычно эта информация находится на странице Свойства или Конечные точки каждого ресурса в портале Azure. Вот распространенные
--scopes
примеры, но опирайтесь на ваш идентификатор ресурса, чтобы получить фактический формат и значение.Область Пример Подписка /subscriptions/mySubscriptionID
Группа ресурсов /subscriptions/mySubscriptionID/resourceGroups/myResourceGroupName
Виртуальная машина /subscriptions/mySubscriptionID/resourceGroups/myResourceGroupName/providers/Microsoft.Compute/virtualMachines/myVMname
Служба файлового хранилища учетной записи /subscriptions/mySubscriptionID/resourceGroups/myResourceGroupName/providers/Microsoft.Storage/storageAccounts/myStorageAccountName/fileServices/default
Фабрика данных /subscriptions/mySubscriptionID/resourceGroups/myResourceGroupName/providers/Microsoft.DataFactory/factories/myDataFactoryName
Дополнительные примеры областей см. в статье "Общие сведения о области" для Azure RBAC.
Создайте субъект-службу.
В этом примере создается новый субъект-служба с именем myServicePrincipalName1 с разрешениями читателя для всех ресурсов в группе ресурсов RG1.
# Bash script az ad sp create-for-rbac --name myServicePrincipalName1 \ --role reader \ --scopes /subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/myRG1
Параметр
--scopes
принимает список областей, разделенных пробелами. В этом примере создается новый служебный принципал с именем myServicePrincipalName2, который получает разрешения читателя на все ресурсы в группе ресурсов myRG1. Этот субъект-служба также получает разрешения читателя на myVM, расположенного в myRG2.# Bash script az ad sp create-for-rbac --name myServicePrincipalName2 \ --role reader \ --scopes /subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/myRG1 /subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/myRG2/providers/Microsoft.Compute/virtualMachines/myVM
Если вы решите, что вы предоставили слишком мало или слишком много разрешений новому субъекту-службе, измените разрешения, управляя ролями субъекта-службы.
Создание сервисного принципала с помощью переменных
Вы также можете создать сервис-принципал с помощью переменных.
# Bash script
let "randomIdentifier=$RANDOM*$RANDOM"
servicePrincipalName="msdocs-sp-$randomIdentifier"
roleName="azureRoleName"
subscriptionID=$(az account show --query id --output tsv)
# Verify the ID of the active subscription
echo "Using subscription ID $subscriptionID"
resourceGroup="myResourceGroupName"
echo "Creating SP for RBAC with name $servicePrincipalName, with role $roleName and in scopes /subscriptions/$subscriptionID/resourceGroups/$resourceGroup"
az ad sp create-for-rbac --name $servicePrincipalName \
--role $roleName \
--scopes /subscriptions/$subscriptionID/resourceGroups/$resourceGroup
Чтобы получить полный список свойств субъекта-службы, используйте az ad sp list и обратитесь к разделу Получение существующего субъекта-службы.
Предупреждение
При создании субъекта-службы Azure с помощью команды az ad sp create-for-rbac
в выходные данные включаются учетные данные, которые необходимо защитить. Убедитесь, что эти учетные данные не включены в код, или проверьте учетные данные в системе управления версиями. В качестве альтернативы можно использовать управляемые удостоверения (если они доступны), чтобы не работать с учетными данными.
Следующие шаги
Теперь, когда вы узнали, как создать основной объект службы Azure, перейдите к следующему шагу, чтобы узнать, как использовать основные объекты службы с аутентификацией с использованием паролей.