Azure VM上运行的Docker容器如何使用Azure托管标识

核心结论 #

• 分配给Azure虚拟机的系统分配、用户分配托管标识，完全可以被虚拟机上运行的Docker容器正常调用
• 你之前在ACI中使用的DefaultAzureCredential鉴权代码无需任何修改，不需要配置存储密钥的环境变量，不需要手动编写令牌申请逻辑
• 你之前的推测存在偏差：托管标识并非只能绑定给虚拟机实例本身，只要将虚拟机本地的托管标识服务端点透传给容器，Azure Identity SDK就能自动完成鉴权流程，使用体验和ACI环境完全一致

具体配置步骤 #

你不需要做复杂改造，按下面操作即可：

1. 先给Azure VM完成托管标识配置：开启系统分配标识，或绑定你之前使用的用户分配托管标识，和你之前给ACI配置标识的权限逻辑完全一致，给存储队列、企业内部容器注册表分配对应访问权限即可
2. 直接启动Docker容器即可，默认配置下Docker的网络栈允许容器访问宿主的链路本地地址，不需要额外加启动参数：

docker run -d --name your-python-workload your-business-image:latest

3. 验证连通性：进入容器执行以下命令，如果能正常返回access token，就说明鉴权链路已经通了，你的Python代码可以直接运行

curl 'http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://storage.azure.com/' -H Metadata:true

关键注意事项（踩坑点） #

• 如果你的容器内配置了HTTP_PROXY/HTTPS_PROXY环境变量，必须将169.254.169.254加入NO_PROXY排除列表，否则IMDS请求会被代理拦截，导致SDK无法获取令牌
• 如果你的VM同时绑定了多个用户分配托管标识，只需要在容器启动时添加一个环境变量AZURE_CLIENT_ID=<你要使用的托管标识客户端ID>即可，这个环境变量仅用于指定SDK要选用的标识，不包含任何敏感信息，不存在密钥泄露风险
• 拉取企业内部私有容器注册表镜像时，可以直接在VM层面用托管标识完成ACR登录，不需要配置注册表永久账号密码：

az acr login --name your-enterprise-acr --identity

适配你当前落地场景的补充说明 #

• 你选择VM+Docker的临时方案完全可以解决之前ACI/容器应用遇到的私有链路连通问题：只要将VM部署到与企业容器注册表私有端点连通的VNET子网内，配好NSG放行规则，容器访问内网注册表、Azure队列等资源的链路不会有问题，配置复杂度远低于ACI的私有端点关联，适合快速上线的需求
• 后续你迁移到Kubernetes承载批处理负载时，这套鉴权逻辑依然可以复用：不管是节点级托管标识透传，还是用工作负载身份，你的业务Python代码不需要做任何修改，迁移成本极低
• 完全不需要退回到用环境变量存储连接字符串、访问密钥的方案，这类方案存在密钥泄露、轮换成本高的问题，用托管标识透传的方案安全性和易用性都更好。

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