调用其他Azure Function时是否可使用当前Azure Function的托管标识

完全可以通过托管标识解决客户端凭证的管理风险，这也是Azure官方推荐的服务间调用安全最优实践，具体方案说明如下：

适用前提 #

只有当你的守护程序应用部署在支持Azure托管标识的Azure资源上时可以使用该方案，目前支持托管标识的常见Azure资源包括Azure VM、Azure Functions、Azure App Service、Azure Container Apps、AKS、Azure Automation等。

托管标识方案的核心优势 #

• 彻底消除人工凭证管理成本：托管标识对应的身份凭证由Azure后台自动生成、定期轮转，整个过程对运维、开发人员完全透明，不存在密钥泄露的可能性
• 代码集成更简洁：不需要开发者自行构造AAD /token 端点的请求逻辑，直接调用官方Azure Identity SDK的通用凭证类即可自动获取访问令牌
• 权限管控更灵活：支持基于角色的权限分配，可精确控制托管标识对目标服务的访问权限，符合最小权限安全原则

具体配置步骤 #

• 给运行守护程序的Azure资源启用托管标识：可选择系统分配托管标识（和资源生命周期绑定，资源删除时标识自动删除）或者用户分配托管标识（可独立创建、分配给多个资源使用）两种类型
• 给该托管标识分配目标服务的访问权限：在目标服务对应的AAD应用注册中，给托管标识授予所需的应用权限（注意不是委托权限，守护程序场景属于服务到服务的非用户上下文调用，必须使用应用权限）
• 代码中集成凭证获取逻辑：直接引用对应语言的Azure Identity SDK，使用 DefaultAzureCredential 类即可自动读取当前资源的托管标识身份，传入目标服务的应用ID URI作为Scope即可获取合法的OAuth2访问令牌，不需要在代码、配置文件中填写任何client id、client secret类的敏感信息，C#代码示例如下：

using Azure.Identity;

var credential = new DefaultAzureCredential();
// 替换为你要调用的目标服务的应用ID URI
var accessToken = await credential.GetTokenAsync(
    new TokenRequestContext(new[] { "https://contoso-target-service/.default" })
);

不适用场景说明 #

如果你的守护程序部署在非Azure环境（比如本地机房、其他云厂商服务器），则无法直接使用Azure托管标识，这类场景建议使用证书替代客户端密钥，或者将客户端密钥存储在Azure Key Vault中定期轮转，降低泄露风险。

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