使用 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 訂閱還沒。