Aspire 9.2 迁移后 AZURE_CLIENT_ID 缺失问题解析

在将应用从 Aspire 9.1 迁移到 9.2.1 版本后，许多开发者遇到了一个关键问题：那些不依赖 Azure SQL 服务的应用突然无法获取 AZURE_CLIENT_ID 环境变量。这个问题尤其影响那些需要访问 Azure Key Vault 的应用，导致认证失败。

问题根源

在 Aspire 9.1 版本中，系统会为所有 Azure 容器应用(ACA)自动配置一个默认的托管身份(Managed Identity)，并将对应的 AZURE_CLIENT_ID 环境变量注入到应用中。这个身份通常用于访问 Azure 容器注册表(ACR)。

然而在 9.2 版本中，Aspire 团队引入了一个重大变更：托管身份现在按应用分配，而不是共享一个全局身份。这意味着：

1. 只有明确引用 Azure 资源的应用才会获得托管身份
2. 环境变量的设置逻辑发生了变化
3. 对于仅使用连接字符串(如 Key Vault 连接字符串)的应用，系统不会自动分配身份

解决方案

对于这个问题，Aspire 团队推荐了几种解决方案：

1. 使用 AsExisting 模式：这是目前推荐的解决方案。通过将现有 Azure 资源显式声明为项目依赖，Aspire 会自动为应用分配托管身份并设置必要的权限。

2. 等待未来更新：Aspire 团队正在考虑在 9.4 版本中改进这一行为，可能会为所有容器应用强制分配身份，或者提供更明确的错误提示。

3. 手动配置：作为临时方案，开发者可以手动通过 WithEnvironment 方法注入 AZURE_CLIENT_ID，但这会降低部署的自动化程度。

最佳实践

基于这一变更，建议开发者在迁移到 Aspire 9.2+ 时：

1. 审查所有依赖 Azure 服务的应用，包括那些通过连接字符串访问服务的应用
2. 将现有的 Azure 资源引用转换为 AsExisting 模式
3. 测试应用在缺少托管身份情况下的行为
4. 考虑为所有生产环境的应用显式分配托管身份，即使当前不需要

这一变更虽然带来了短期的适配成本，但从长远看，按应用分配身份的模式提供了更好的安全隔离和权限管理能力，是云原生应用发展的正确方向。