Azure AKS使用Managed Identity访问KeyVault等资源的角色分配疑问

操作本质澄清 #

你此前给VMSS配置系统分配托管身份、并将VMSS添加到Key Vault访问策略的操作，本质上是给与该VMSS绑定的系统分配托管身份（System-assigned Managed Identity, SMI） 授权。系统分配托管身份是依附于宿主资源（此处为VMSS）存在的，生命周期与宿主完全一致，Azure后台会自动将VMSS资源的授权映射到其关联的SMI，二者作为授权主体的效果完全等价。

后续对接其他服务的授权方案 #

方案1：沿用当前VMSS的系统分配托管身份 #

如果你允许集群内所有Pod共享同一个身份访问云服务，直接将该VMSS（或其关联的SMI对象）添加为对应服务的角色即可。注意遵循最小权限原则，无需统一授予Contributor角色：

• 访问Blob存储可授予存储 Blob 数据参与者角色
• 访问Cognitive Services可授予认知服务用户角色
  权限范围越小，安全风险越低。

方案2（推荐）：使用独立的用户分配托管身份 #

如果不同业务Pod需要不同的访问权限，建议创建独立的用户分配托管身份（User-assigned Managed Identity, UMI）：

1. 为不同业务场景创建独立的UMI，仅给UMI分配对应服务所需的最小权限
2. 将UMI与Pod绑定的ServiceAccount关联
   这种方案实现了权限隔离，避免单身份权限过大引发的安全风险，更符合生产环境最佳实践。

核心疑问解答：为什么看起来是给VMSS而非托管身份分配角色？ #

这是系统分配托管身份的特性导致的：

1. 系统分配托管身份没有独立的资源生命周期，随VMSS创建自动生成、随VMSS删除自动销毁，不属于用户可直接在资源组里查看的独立资源，所以大部分场景下直接选择宿主资源（VMSS）作为授权对象操作更简便。
2. 如果你需要单独操作托管身份对象，可在Azure AD的企业应用列表中，筛选“应用程序类型=托管身份”，就能找到与VMSS同名的SMI对象，给该对象授权和给VMSS授权效果完全一致。

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