如何通过Azure Bicep正确配置App Service托管身份与Key Vault集成

你调整后的实现逻辑可以解决当前的依赖冲突问题，符合Azure资源部署的基本规范。先创建带系统分配托管身份的Web App、获取其Principal ID后再配置Key Vault访问策略的思路，确实能解决Key Vault无法提前获取Web App身份标识的问题。

• 修正Key Vault授权模式冲突：你当前的Key Vault配置同时开启了enableRbacAuthorization: true和传统accessPolicies，二者互斥，开启RBAC授权后访问策略会直接失效。你可以二选一：
  • 保留RBAC模式：删除accessPolicies配置，额外为Web App的托管身份分配「Key Vault 机密用户」内置RBAC角色即可
  • 保留访问策略模式：将enableRbacAuthorization改为false，原有访问策略配置即可生效
• 优化Secret URI写法：避免硬编码vault.azure.net域名，可通过Key Vault模块输出的properties.secretUri属性拼接完整的秘钥引用地址，降低手动拼写错误概率
• 缩短部署依赖链路：你当前AI、SQL服务的创建都依赖Key Vault，Key Vault又依赖Web App，全链路串行部署耗时较长。可以拆分Web App部署为两个阶段：先创建仅开启托管身份的空Web App，等Key Vault、AI、SQL全部部署完成后，再更新Web App的应用配置，实现非核心逻辑的并行部署

如果不想调整原有先建Key Vault再建Web App的部署顺序，可以使用用户分配托管身份实现：

1. 提前创建用户分配托管身份资源
2. 创建Key Vault时直接为该托管身份授予秘钥访问权限
3. 创建Web App时直接绑定该预先创建的托管身份即可
   该方案不需要调整原有资源部署顺序，是企业级场景下更常用的托管身份权限配置方案。

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