Question

问题陈述
目前，我正在借助azure terraform在不同的订阅中创建/修改azure资源。

错误

Principal <appid> does not exist in the directory {destination-tenant-id-for which contribution role required}

请考虑以下情形。
我们想要在一个订阅中创建Azure AKS群集，并且在同一执行中，我们想在另一个订阅中更新DNS定义。如果我们在同一个订阅中同时拥有DNS区域和aks群集，则此过程效果很好，但如果这两个资源位于不同的订阅中，则此过程将无法正常工作。

已采取的步骤
无需分配即可创建服务主体

az ad sp create-for-rbac -n sp-terraform-001 --skip-assignment

为当前sp分配当前订阅者的贡献者角色

az role assignment create --assignee <appid>  --role Contributor --scope /subscriptions/<sub-id>

*将贡献者角色分配给当前sp用于其他订阅。它会失败，并带有*

az role assignment create --assignee <appid>  --role Contributor --scope /subscriptions/<diff-sub-id>/<resource-group>....

请让我知道访问其他订阅中资源的正确步骤

Answer 1

您可以为多个订阅的服务主体分配权限，这不成问题，因为SP位于订阅之外，因此位于Azure AD中。

但是，您不能将不同的Azure AD租户中的资源的权限分配给服务主体所在的资源，这听起来像是您要在此处进行的操作。

Answer 2

首先在附加了“不同”订阅的租户中创建一个服务主体，传递分配给现有服务主体的 appid。我会尝试在命令中解释...

az login --tenant <tenant_requiring_new_sp> --subscription <diff-sub-id>
az ad sp create --id <appid>
az role assignment create --assignee <appid> --role Contributor --scope /subscriptions/<diff-sub-id>

是的，appid（最初）属于不同租户中的服务主体，但服务主体对于租户来说是唯一的（具有自己的 objectid），并且是为其分配角色的服务主体。但是，在创建服务主体时传递 appid 时，您是在指示 Azure AD 对新服务主体使用相同的 appid，然后使用新的唯一 objectid（最终用于角色分配，而不是appid）。

如果您是一名程序员，将服务主体视为应用注册的“实例”可能会有所帮助，其中应用注册更像是一个类定义。因此，服务主体“实例”具有可以分配角色的实质内容，而不是定义。

如何从不同的订阅向Azure服务主体分配角色？

2 个答案: