Terraform轮换Azure AD应用注册密钥时 DevOps管道报Authorization_RequestDenied错误

核心逻辑校验 #

你怀疑的“服务主体尝试移除自身关联密钥触发权限不足”是完全准确的，这和本地CLI能跑通的身份差异直接相关：

• 本地CLI执行时使用的是个人Azure AD用户身份，租户默认配置下这类身份只要没有被全局策略限制应用注册操作，就可以对租户内应用执行密钥增删操作，和目标应用是不是自己关联的服务主体没有关系。
• 管道执行时使用的身份和待操作的Azure AD应用、DevOps服务连接是同一个对象，也就是当前跑Terraform的服务主体，就是被修改密钥的那个应用本身。
• Azure AD的默认权限规则明确限制：应用服务主体不存在对自身关联应用注册对象的默认写权限，哪怕被删除的密钥和当前认证用的密钥是相互独立的，只要没有显式授权，执行删除密码凭证的操作就会直接抛出Insufficient privileges的403错误，和密钥是否独立没有关系。

所需权限的具体定位 #

针对当前操作场景，不需要给全局级别的过高权限，最小权限集如下：

• 给目标应用分配Application.ReadWrite.OwnedBy类型的应用权限（应用权限而非委托权限），该权限允许服务主体对其作为所有者的应用注册对象执行读写操作，覆盖密码凭证增删改的全流程。
• 把服务主体自身添加为目标Azure AD应用的所有者列表成员，匹配上述权限的适用范围，避免权限因为所有者关系不匹配失效。
• 报错里显示调用的是旧版graphrbac接口，需要确保分配的权限是完成管理员同意状态的有效权限，不要因为权限类型不匹配出现“权限已分配但接口不识别”的问题。

现有架构的适配调整 #

结合当前30分钟密钥轮换的设计，两个关键调整可以避免后续运行报错：

• 给azuread_application_password资源增加生命周期配置，设置create_before_destroy = true，把轮换流程从“先删旧密钥、再建新密钥”调整为“先生成新密钥、确认密钥创建成功后再删除旧密钥”，降低权限校验节点的失败概率。
• 严格区分两类密钥的用途：DevOps服务连接用于Terraform认证的常驻密钥，不要纳入当前30分钟轮换的范围，避免轮换时删除了管道自身认证用的密钥，导致后续执行流程直接中断。
• 完成权限配置后，不需要给服务主体分配Application.ReadWrite.All这类全局应用读写权限，避免过度授权带来的安全风险。

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