集群上安装的非Azure资源服务如何使用Azure managed identity

托管标识不需要直接绑定到你部署的业务服务本身——你之前了解的「将标识配置到Azure资源上」这个步骤，只需要配置到承载集群的Azure底层计算资源即可，上层运行的服务通过Azure实例元数据服务（IMDS）就能拿到标识令牌完成鉴权，不需要服务本身是独立的Azure资源。

核心实现原理 #

Azure所有支持托管标识的计算资源（VM、虚拟机规模集、AKS节点等）都会在本地启动一个固定可达的元数据服务，监听地址为http://169.254.169.254，任何运行在该资源上的进程，只要能访问到这个地址，就可以按规范请求绑定到该资源的托管标识的访问令牌，用令牌访问已经给该标识授权的Azure资源，全程不需要手动管理密钥、证书。

分场景操作步骤 #

场景1：服务运行在AKS（Azure Kubernetes Service）集群 #

这是最常见的场景，有两种配置方式，按需选择即可：

• 节点级绑定（适合集群内服务权限统一的场景）
  1. 提前创建用户分配托管标识，给该标识授予待访问Azure资源的对应权限（比如存储读写、Key Vault读取等）
  2. 将创建好的托管标识分配给AKS集群对应的节点池虚拟机规模集
  3. 集群内所有服务只要能放通到节点本地169.254.169.254的访问，就可以直接请求元数据接口拿令牌
• 工作负载身份绑定（推荐，适合多服务权限隔离场景）
  1. 提前为不同服务创建对应的用户分配托管标识，分别授予最小必要权限
  2. 开启AKS集群的工作负载身份功能，创建K8s ServiceAccount时通过注解绑定对应的托管标识
  3. 业务Pod只要挂载对应ServiceAccount，就只能拿到绑定到该ServiceAccount的托管标识令牌，不会出现权限越界，Azure官方SDK还会自动完成令牌获取、续期，不需要业务代码写额外的请求逻辑

不管用哪种绑定方式，手动请求令牌的示例命令如下，替换对应参数即可：

curl 'http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=<待访问资源的受众标识>&client_id=<托管标识的客户端ID>' -H Metadata:true

拿到返回的access_token字段后，直接放到请求目标Azure资源的Authorization: Bearer <token>头里，就能完成身份校验。

场景2：服务运行在Azure VM/VMSS上自建的集群 #

如果是在Azure VM/虚拟机规模集上自己搭的集群（比如自建K8s、Service Fabric），配置逻辑更直接：

1. 将提前创建、授权好的用户分配托管标识，绑定到承载集群节点的VM/VMSS资源
2. 配置集群网络策略，放通业务Pod到节点本地169.254.169.254地址的访问（注意这个地址是节点本地链路地址，不会走公网）
3. 业务服务的令牌获取、使用逻辑和AKS场景完全一致。如果需要做细粒度权限隔离，可以在集群侧部署轻量代理，拦截业务服务的令牌请求，校验服务身份后再转发给元数据服务，避免所有服务都能拿到高权限标识的令牌。

注意事项 #

• 元数据服务本身没有额外的鉴权逻辑，只要能访问到169.254.169.254的进程都能拿到绑定到节点的托管标识令牌，不要把这个端点暴露到公网，同时严格限制集群内对该地址的访问权限
• 访问令牌默认有效期为24小时，不要长期缓存令牌，优先使用Azure官方SDK，内置了自动续期逻辑，能减少鉴权失败的问题
• 生产环境优先用细粒度的工作负载身份做权限分配，不要把高权限托管标识直接绑定到节点池，遵循最小权限原则

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