如何通过Terraform为MC资源组下VMSS分配User Assigned managed Identity

直接修改MC_开头的AKS托管资源组内的VMSS属于临时方案，AKS做集群升级、节点镜像更新、扩容操作时会自动覆盖底层VMSS配置，导致绑定的托管标识丢失。正确的实现方式是直接在AKS节点池层面配置用户分配托管标识，配置会被AKS自动持久化同步到底层所有节点VMSS，不会出现配置漂移。

推荐实现（生产可用，无配置漂移） #

• 第一步：引用已创建好的用户分配托管标识（UAMI），如果需要通过Terraform新建UAMI，把数据源块替换为资源块即可
• 第二步：在AKS节点池配置块中绑定该UAMI，新建集群/节点池、更新现有节点池都可以用这个方式
• 第三步：给UAMI分配目标Key Vault的对应访问权限
• 配置完成后，集群内所有Pod都可以通过Azure实例元数据服务（IMDS）获取UAMI的访问令牌，直接访问Key Vault，和你之前PowerShell脚本实现的效果完全一致

对应Terraform代码如下：

# 引用已存在的用户分配托管标识
data "azurerm_user_assigned_identity" "aks_node_uami" {
  name                = "你的UAMI名称"
  resource_group_name = "UAMI所在资源组名称"
}

# 引用已存在的AKS集群
data "azurerm_kubernetes_cluster" "aks" {
  name                = "你的AKS集群名称"
  resource_group_name = "AKS所在资源组名称"
}

# 更新现有节点池绑定UAMI，新建节点池/集群直接把identity块放到对应资源的节点池配置里即可
resource "azurerm_kubernetes_cluster_node_pool" "default" {
  name                  = data.azurerm_kubernetes_cluster.aks.default_node_pool[0].name
  kubernetes_cluster_id = data.azurerm_kubernetes_cluster.aks.id
  # 以下参数保持和现有节点池配置完全一致，避免节点重建
  vm_size               = data.azurerm_kubernetes_cluster.aks.default_node_pool[0].vm_size
  node_count            = data.azurerm_kubernetes_cluster.aks.default_node_pool[0].node_count
  os_disk_size_gb       = data.azurerm_kubernetes_cluster.aks.default_node_pool[0].os_disk_size_gb
  # 省略其他和现有节点池一致的配置项，比如vnet_subnet_id、os_type等

  # 绑定用户分配托管标识
  identity {
    type         = "UserAssigned"
    identity_ids = [data.azurerm_user_assigned_identity.aks_node_uami.id]
  }
}

# 给UAMI分配Key Vault访问权限，以Key Vault访问策略模式为例
resource "azurerm_key_vault_access_policy" "uami_kv_access" {
  key_vault_id = "目标Key Vault的资源ID"
  tenant_id    = data.azurerm_user_assigned_identity.aks_node_uami.tenant_id
  object_id    = data.azurerm_user_assigned_identity.aks_node_uami.principal_id

  # 按实际需求分配权限，只读场景给Get、List足够
  secret_permissions      = ["Get", "List"]
  key_permissions         = ["Get", "List"]
  certificate_permissions = ["Get", "List"]
}

直接修改VMSS的实现（仅复现原PowerShell逻辑，不推荐生产使用） #

如果一定要完全复现你之前PowerShell直接改VMSS的逻辑，需要先把MC资源组里的现有VMSS导入Terraform状态，再修改其标识配置，参考代码如下：

# 查询MC资源组下的目标VMSS
data "azurerm_virtual_machine_scale_set" "aks_node_vmss" {
  name                = "VMSS名称"
  resource_group_name = "AKS托管MC资源组名称"
}

# 注意：执行apply前必须先执行import命令把现有VMSS导入状态
# terraform import azurerm_linux_virtual_machine_scale_set.aks_node_vmss <VMSS的完整资源ID>
resource "azurerm_linux_virtual_machine_scale_set" "aks_node_vmss" {
  name                = data.azurerm_virtual_machine_scale_set.aks_node_vmss.name
  resource_group_name = data.azurerm_virtual_machine_scale_set.aks_node_vmss.resource_group_name
  location            = data.azurerm_virtual_machine_scale_set.aks_node_vmss.location
  sku                 = data.azurerm_virtual_machine_scale_set.aks_node_vmss.sku
  instances           = data.azurerm_virtual_machine_scale_set.aks_node_vmss.instances
  # 这里必须补全VMSS的所有现有配置项，缺项会导致VMSS被重建或配置异常
  # 省略网络、OS、升级策略等几十项配置...

  identity {
    type         = "UserAssigned"
    identity_ids = ["你的UAMI资源ID"]
  }
}

该方案存在明显缺陷：你需要全量维护VMSS的所有配置，AKS对底层VMSS的任何自动更新都会导致Terraform出现配置漂移，且AKS的节点池同步逻辑随时可能覆盖你手动绑定的UAMI，导致权限失效。

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