azure - 为什么我的服务主体无权访问我的 key 保管库？

Question

我们有一个现有的 key 保管库(例如 kv1)和一个现有的广告安全组(例如 adg1)。

adg1 已设置访问策略，为组成员提供获取和列出访问权限。

使用 Azure DevOps 管道和 Arm 模板，我们正在部署多个资源，包括虚拟机规模集(例如 vmss1)

最后，我们调用一个具有广告管理员访问权限的 Azure 自动化作业，将 vmss1 添加到 adg1

vmss1 无法访问 kv1 中的 secret 。

如果我们直接将 vmss1 服务主体添加到 adg1，它将获得访问权限，如果我们删除直接添加，它将失去访问权限。

我们的 AD 结构不是很复杂，我们等了 2-3 个小时才传播，但仍然没有任何结果。

这是处理添加的 powershell:

$vmssid = (Get-AzureRMADServicePrincipal -DisplayName "$_scaleSetName").Id

if(!$vmssid){
    Write-Error 'Scale set did not exiset or was not a scale set'
    return 1
}

$groupId = (Get-AzureRMAdGroup -AzureRmContext $AzureContext -DisplayName "$webAppGroupName" ).Id 
if(!$groupId){
    Write-Error 'Group not found'
    return 1
}

$shouldAddMember = !(Get-AzureRMAdGroupMember -AzureRmContext $AzureContext -GroupObjectId $groupId | ?{$_.Id-eq $vmssid}) 
if($shouldAddMember ){
 Add-AzureRmAdGroupMember -AzureRmContext $AzureContext -MemberObjectId $vmssId -TargetGroupObjectId $groupId 
}
else{
Write-Output 'Member existed in group'
exit 0
}

第一次运行会导致用户被添加，后续运行打印“成员已存在”

Answer 1

看来 azure AD 的传播时间可能非常长。一天后，它开始仅使用分配给访问策略的 AD 组。所以我想答案就是极度的耐心。