Принцип обслуживания может быть создан без роли через az ad sp create-for-rbac --skip-assignment

Q1 . Какая польза от принципала службы без роли?

Q2 . Может ли участник службы завершить работу без подключения к какой-либо области / ресурсу? Если да, то какой толк от такого независимого сервисного принципа?

0
SLN 14 Ноя 2019 в 00:44

2 ответа

Лучший ответ

Q1 . Какая польза от принципала службы без роли?

Параметр --skip-assignment пропускает назначение субъекта службы подписке. Если быть точным, ваш вопрос должен быть without an RBAC role, потому что есть еще одна роль с именем Administrator role, о которой будет сказано ниже.

Некоторые примеры, на которые вы можете сослаться, есть много примеров использования приложения AD, здесь не будем вдаваться в подробности. Если вы хотите узнать о них, обратитесь к официальному документу Azure AD..

1. Субъект-служба может быть назначен как Administrator role в Azure AD, тогда он может делать то, что зависит от разрешений роли, например создать пользователя, удалить группу. Через Azure AD powershell, Microsoft Graph API, Azure AD Graph API или AAD part of the Az powershell module.

2. Субъект-служба также может вызывать API и использовать приведенную выше оболочку powershell без Administrator role, но вам необходимо указать application permission к нему. az ad sp create-for-rbac создаст приложение AD вместе с субъектом службы. В приложении AD на портале -> API permissions, вы можете добавить разрешение и согласие. Обратите внимание: когда мы добавляем разрешения и согласие в приложении AD, на самом деле разрешения будут предоставлены субъекту службы в вашем клиенте, субъект службы является экземпляром приложения AD в определенном клиенте .

Q2 . Может ли участник службы завершить работу без подключения к какой-либо области / ресурсу? Если да, то какой толк от такого независимого сервисного принципа?

Да, как уже упоминалось выше, он может делать много вещей, связанных с Azure AD, Graph API. Вот документ о приложении. и объекты субъекта службы в Azure Active Directory, вам будет очень полезно понять субъекта службы.

0
Joy Wang 14 Ноя 2019 в 02:38

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

A2-я так думаю, это будет назначенный системой управляемый идентификатор, который представляет собой особый тип управляемого идентификатора (субъект службы)

0
Thiago Custodio 13 Ноя 2019 в 22:21