使用New-AzAksCluster指定托管身份仍创建Service Principal问题

问题描述 #

使用PowerShell cmdlet New-AzAksCluster 创建公共AKS集群时，已指定 -EnableManagedIdentity 和 -AssignIdentity 参数，但命令每次执行仍会尝试创建Service Principal（服务主体）。

预期行为 #

命令应直接使用指定的托管身份，依据如下：

• 使用AZ CLI以相同参数创建同一集群时，不会创建SP，而是将Azure AD角色分配给指定的身份
• 官方文档明确说明：AKS不会自动创建服务主体，需自行创建；使用托管身份可避免管理SP的复杂性，无需AKS自动生成SP

已做排查 #

• 在本地PowerShell、VSCode集成PowerShell、Azure CloudShell（不同账户、租户、订阅）中测试，结果一致
• 权限角色（如Owner、GlobalAdmin）不影响此问题
• 删除本地的acsServicePrincipal.json文件无效果

解决思路建议 #

1. 检查参数顺序与语法正确性：确认-EnableManagedIdentity和-AssignIdentity的参数位置是否正确，特别是-AssignIdentity是否传入了有效的托管身份资源ID或名称，避免因参数解析问题导致命令 fallback 到SP模式
2. 验证Az PowerShell模块版本：确保使用的Az.Aks模块是最新稳定版（或至少是文档对应的azps-10.4.1及以上版本），旧版本可能存在参数逻辑bug，可通过Get-Module -ListAvailable Az.Aks查看版本，用Update-Module Az.Aks更新
3. 检查托管身份的配置权限：确认指定的托管身份已具备AKS所需的基础权限（如对虚拟网络、节点资源组的访问权限），若身份权限不足，命令可能会尝试创建SP作为替代
4. 添加调试参数排查：执行命令时添加 -Debug 参数，查看详细的执行日志，定位到触发SP创建的具体步骤和原因，比如是否有某个依赖资源需要SP而未使用托管身份
5. 尝试简化命令参数：先使用最基础的参数组合创建托管身份集群（仅指定必要的名称、资源组、托管身份、启用托管身份参数），排除其他复杂参数（如自定义虚拟网络、附加组件）的干扰，确认是否是某类参数导致的冲突
6. 检查订阅的AKS资源提供商状态：确认订阅中Microsoft.ContainerService资源提供商已注册，若未注册可能导致托管身份逻辑无法正常执行，可通过Register-AzResourceProvider -ProviderNamespace Microsoft.ContainerService完成注册

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