拥有Azure Key Vault及订阅所有者权限仍遇RBAC未授权问题求助

错误核心分析 #

从错误日志里的Assignment: (not found)可以明确：Azure RBAC系统未识别到当前调用身份（appid/oid对应的主体）在目标Key Vault资源上的任何角色分配，这是导致Forbidden错误的直接原因——即使你认为自己拥有订阅或Key Vault的所有者权限。

排查与解决步骤 #

1. 验证调用身份的实际角色分配

   • 用Azure CLI执行以下命令，检查目标Key Vault层级的角色分配：

     az role assignment list --assignee <错误日志中的OID> --scope "/subscriptions/subs_id/resourcegroups/networkwatcherrg/providers/microsoft.keyvault/vaults/vickyskeyvault001"
     

   • 如果结果为空，说明该身份确实没有被分配任何角色到Key Vault资源。此时需要手动添加所有者或Key Vault Secrets Officer角色到该主体，作用域选择目标Key Vault。
   • 注意：如果调用身份是服务主体（日志中有appid），要确保角色分配给的是这个服务主体，而非你的用户账号。

2. 检查Key Vault的权限模型

   • Azure Key Vault支持两种权限控制模型：RBAC和传统访问策略。如果Key Vault使用的是访问策略模式，即使你有订阅所有者权限，也需要在访问策略中明确配置秘钥的Set权限：
     1. 进入Azure门户的目标Key Vault
     2. 切换到「访问策略」页面
     3. 查看是否有对应主体的条目，且权限包含「密钥权限」下的「设置」
     4. 若没有，添加新的访问策略，选择对应主体并勾选Set权限

3. 排查隐式拒绝规则

   • 虽然日志中DenyAssignmentId为null，但仍可执行以下命令确认是否存在隐藏的拒绝分配：

     az deny-assignment list --scope "/subscriptions/subs_id/resourcegroups/networkwatcherrg/providers/microsoft.keyvault/vaults/vickyskeyvault001"
     

   • 如果存在拒绝分配，需要移除或调整其作用范围。

4. 确认身份上下文正确性

   • 如果你使用CLI/PowerShell执行操作，确保当前登录的是错误日志中对应的身份：

     az account show
     

   • 若上下文不符，重新登录对应的服务主体或用户账号：

     # 服务主体登录示例
     az login --service-principal -u <错误日志中的appid> -p <服务主体密钥> --tenant <租户ID>
     

5. 强制刷新RBAC缓存

   • 若角色分配已正确添加但仍报错，尝试注销后重新登录，或等待30分钟以上（极端情况下RBAC缓存同步可能延迟）。

内容的提问来源于stack exchange，提问作者Vaishnavi Vaishu