Azure App Service的SystemAssigned托管标识无法通过Bicep部署启用

1. 验证API版本兼容性 #

你当前使用的Microsoft.Web/sites@2022-09-01版本虽支持系统分配标识，但部分旧版本存在已知的标识配置同步延迟问题。建议升级到最新稳定API版本（如2023-12-01）重新部署，仅需修改资源定义的API版本，其余配置保持不变：

resource appService 'Microsoft.Web/sites@2023-12-01' = {
  // 原有配置保留
}

2. 处理资源状态不一致问题 #

若该App Service曾通过其他渠道（门户、CLI）部署过，可能存在配置状态冲突：

• 先部署一次移除标识的Bicep配置（将identity.type设为'None'），完成后再重新部署启用SystemAssigned的版本；
• 或在Azure门户手动启用系统分配标识，再导出Bicep模板对比，排查是否有遗漏的隐式配置项。

3. 检查App Service Plan SKU限制 #

确认你的App Service Plan SKU支持托管标识：免费（F1）、共享（D1）及以上常规SKU均支持，但部分特殊旧版SKU可能存在限制。可临时切换到标准SKU（如S1）测试是否能正常启用标识。

4. 排查部署权限与资源锁定 #

• 部署账号需具备Microsoft.Web/sites/write权限，确保能修改App Service配置；
• 检查资源组或App Service是否存在只读锁定，锁定会阻止标识配置变更。

5. 隔离Key Vault引用配置的影响 #

你设置了keyVaultReferenceIdentity: 'SystemAssigned'，该配置依赖已启用的系统分配标识。可先移除这一配置，部署启用标识后，再重新添加该属性。

6. 用CLI验证标识可用性 #

若以上步骤无效，通过Azure CLI手动尝试启用标识，验证是否为Bicep部署特定问题：

az webapp identity assign --name <你的App Service名称> --resource-group <资源组名称>

如果CLI能成功启用，说明是Bicep部署过程中的异常，需收集部署日志联系微软支持；若CLI也失败，可能是资源本身状态异常，需直接联系微软排查。

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