同时使用--enable-azure-rbac与--aad-admin-group-object-IDs的作用解析

• 核心定位：AKS集群的超级管理员权限载体
  不管开不开Azure RBAC，这个参数指定的AAD组都会拿到AKS集群的cluster-admin权限——这是Kubernetes原生的最高权限，能操作集群内所有资源。启用Azure RBAC后，这个权限不会失效，因为它是直接绑定在Kubernetes的ClusterRoleBinding上的，和Azure RBAC是两套并行的权限体系。

• 启用Azure RBAC时的特殊作用
  当你开启Azure RBAC（--enable-azure-rbac）时：

  • 如果创建集群时同时指定--aad-admin-group-object-IDs，这个组会同时拥有两个层面的最高权限：一是Kubernetes的cluster-admin，二是Azure RBAC层面的Azure Kubernetes Service Cluster Admin Role（能操作AKS集群本身的Azure资源配置，比如升级集群、修改节点池）。
  • 如果只开Azure RBAC不指定这个参数，AKS会自动把集群创建者设为Azure RBAC的集群管理员，但不会自动创建Kubernetes层面的cluster-admin绑定——这时候你要么通过Azure RBAC手动分配Kubernetes权限，要么后续用az aks update加管理员组来补上Kubernetes的超级权限。

• 你的场景解析
  你先建了没开Azure RBAC但指定了管理员组的AKS，这时候这个组已经绑定了Kubernetes的cluster-admin。之后开Azure RBAC时，AKS不会删掉已有的Kubernetes权限绑定，所以aadProfile.adminGroupObjectIDs会保留，这个组依然有Kubernetes的最高权限，同时Azure RBAC会自动给集群创建者（或者你后来配的Azure RBAC管理员）分配Azure层面的集群管理权限。

• 不同创建场景的差异

  • 同时用--enable-azure-rbac和--aad-admin-group-object-IDs创建：目标组一步到位拿到双体系的最高权限，不用后续再补配置。
  • 仅启用Azure RBAC创建：只有集群创建者有Azure层面的管理员权限，Kubernetes层面没有默认的超级管理员组，得自己手动配置权限。

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