我有一个受 Azure AD 保护的 Web API。我为 Web API 创建了一个应用程序注册，它只允许来自该 Azure AD 的用户访问 API（即单租户）。此过程还在该租户中创建了一个服务主体。
我想知道的是，此服务主体是否可以在信任此 Azure AD 的 Azure 订阅中自行分配自己的 RBAC 角色（任何 RBAC 角色）？或者这将是用户启动的操作，其中具有适当权限（如Owner或User Access Administrator）的用户必须为此服务主体分配适当的角色？
无论我的理解是什么，我相信它是后者（即另一个用户必须执行此操作）。但是，它看起来应该是可能的。
我这么说的原因是，当我创建一个新的 Azure 订阅时，我会自动Owner在该 Azure 订阅中分配一个角色（我是我的 Azure AD 中的全局管理员）。我想知道这是如何实现的。
如果确实有可能，那么应该为服务主体分配什么 Azure AD 角色？
对此的任何见解都将受到高度赞赏。
当然可以，但是服务主体也需要Microsoft.Authorization/roleAssignments/write权限，例如Owner，或者User Access Administrator为自己分配另一个 RBAC 角色。
如果您的意思是服务主体当前没有 RBAC 角色，那么它不能，即使它是租户中的全局管理员，它也无法直接将 RBAC 角色分配给自己。
此外，用户帐户与服务主体不同，如果用户是租户中的全局管理员，他可以简单地Elevate access to manage all Azure subscriptions and management groups为自己（这仅适用于用户，而不是服务主体），然后他将获得范围内的User Access Administrator角色root，然后他可以将任何 RBAC 角色分配给自己。
如果您的服务主体是全局管理员并且想要将 RBAC 角色分配给自己，您可能需要先将全局管理员角色分配给另一个用户帐户，然后提升访问权限以管理所有 Azure 订阅，然后使用该用户帐户分配 RBAC服务主体的角色。
您是正确的，委托人只有在有权这样做时才能授予自己权限。因此，一个全新的 MSI 主体不会是任何组的成员，也不会被分配任何 RBAC 角色，因此无法授予自己额外的权限。
对于 Azure 订阅，创建订阅的主体要么有权在现有租户中执行此操作，要么正在创建新租户和订阅，并且系统将权限授予作为创建者/所有者的用户。
自动授予新 MSI 权限的一种可能方法是使用 Azure 函数，调用 Microsoft Graph 以查询匹配搜索条件的新 MSI，然后授予 MSI 主体所需的权限。该功能必须分配一个 MSI，该 MSI 需要许可才能在所需范围内向新 MSI 授予所需的权限。