使用 MS Graph API，如何强制我以编程方式创建的服务主体、MSI 和 IaC 代码仅限于我的订阅？

Question

Active Directory Graph API 现已完全弃用，取而代之的是 MS Graph API。

我的公司为我提供了自己的 Visual Studio Professional 订阅。 我还有一个 DevOps 组织。 我是两者的所有者角色。

使用 AADG API，我可以使用 Terraform，例如，创建服务主体和管理角色。 DevOps 中的服务连接仅限于我的订阅。

例子：

## These are in my resource group
...
resource "azuread_service_principal" "example" {
  application_id               = azuread_application.example.application_id
  app_role_assignment_required = false
  owners                       = [data.azuread_client_config.current.object_id]
}

...

resource "azurerm_role_assignment" "kubweb_to_acr" {
  scope                = azurerm_container_registry.acr.id
  role_definition_name = "AcrPull"
  principal_id         = azurerm_kubernetes_cluster.kubweb.kubelet_identity[0].object_id
}

这曾经很好用。 现在它没有。 现在我收到如下错误：

Error: authorization.RoleAssignmentsClient#Create: Failure responding to request: StatusCode=403 -- Original Error: autorest/azure: Service returned an error. Status=403 Code="AuthorizationFailed" Message="The client '3520c717-e1cc-4d0b-b021-2f93a1b05d80' with object id '3520c717-e1cc-4d0b-b021-2f93a1b05d80' does not have authorization to perform action 'Microsoft.Authorization/roleAssignments/write

和

ApplicationsClient.BaseClient.Post(): unexpected status 403 with OData
│ error: Authorization_RequestDenied: Insufficient privileges to complete the
│ operation.

尽管我拥有我的订阅，但在我之上有一个上级组织。 我的 SP 仅限于我无法管理的 AD。 我无法通过 MS Graph API 使用“Grant Admin Consent”。另外，在 DevOps 中，当我创建 ARM 服务连接时，例如，我将它 scope 到我的订阅。 它从不限定我的订阅范围，而是父订阅的范围，我无法更改其权限。

我如何改变我的发展或 scope 我的资源，这样我就不必服从上级组织？

他们需要给我什么角色，这样我就不必让他们参与进来？

我已经是订阅的所有者。 我如何以完全控制再次管理它们的方式创建这些类型的资源？

旁注，这很有趣。 我可以使用 Azure CLI 并通过终端运行相同的命令，而且我可以毫无问题地创建或更改资源。 相同的命令az ad sp create-for-rbac根本不会引发任何错误，并且它使用相同的权限和管道中定义的 scope。

Answer 1

您显示的两个错误都是由于 Terraform 正在运行的服务主体未被授权执行相关操作。 （从Azure角色分配错误，我们可以知道这是object ID为“3520c717-e1cc-4d0b-b021-2f93a1b05d80”的服务主体。）

• 要将 Azure 角色分配给用户、组或服务主体（您的第一个错误），需要为 Terraform 使用的服务主体授予一个角色，该角色包括“Microsoft.Authorization/roleAssignments/write”操作，作用域为（至少）scope 您正在尝试授予角色（例如特定的 Azure 资源、它所在的资源组或它所在的订阅）。 通常，如果您需要创建 Azure 角色分配，这就是“所有者”角色。 来自 Terraform 的更多详细信息允许服务委托人管理订阅。 如果您是 Azure 订阅的“所有者”，那么您将能够自己完成此操作。
• 要创建 Azure AD 应用程序和服务主体（您的第二个错误）：需要向 Terraform 使用的服务主体授予在相关 Azure AD 租户中执行此操作的权限。 例如，应用程序角色（应用程序权限）Application.Read.All 和 Application.ReadWrite.OwnedBy 在许多情况下就足够了。 这些是在 Azure AD 租户中发生的操作，因此 Azure AD 管理员将需要授予此访问权限——如果您不是 Azure AD 租户的管理员，则您无法自行执行此操作。 来自 Terraform 的更多详细信息配置用于管理 Azure Active Directory 的用户或服务主体。

我如何改变我的发展或 scope 我的资源，这样我就不必服从上级组织？

您可以拥有一个完全独立的 Azure AD 租户（您将成为管理员），并将 Azure 订阅指向信任该租户。 这可能符合也可能不符合您组织的政策和惯例。

我已经是订阅的所有者。 我如何以完全控制再次管理它们的方式创建这些类型的资源？

Azure AD 应用程序和服务主体不是您的 Azure 订阅的一部分，它们在“父”Azure AD 租户中。 您（用户）可能确实拥有这些对象的权限（例如，您在 Azure AD 时是它们的所有者），但是 Terraform 并不像您一样运行——它作为单独的服务主体运行。

旁注，这很有趣。 我可以使用 Azure CLI 并通过终端运行相同的命令，而且我可以毫无问题地创建或更改资源。 相同的命令 az ad sp create-for-rbac 根本不会引发任何错误，并且它使用相同的权限和管道中定义的 scope。

您可能以您自己的身份（即您的用户帐户）连接到 Azure CLI，而不是 Terraform 正在使用的服务主体。 如果您使用相同的服务主体（例如az login --service-principal... ）连接到 Azure CLI，您可能会遇到相同的错误，因为该服务主体尚未被授予对 Azure AD 租户的特权，并且Azure 订阅还没。