创建AKS群集时，即使未指定任何内容，默认情况下也会创建kubelet_identity。Kubelet identity是用户分配的身份。如果转到VMSS >> Identity，您将看到两个选项卡系统分配的和用户分配的，默认情况下，系统分配为否，但在用户定义中，您将找到分配给它的aks-agentpool。因此，即使您不分配系统标识，也可以将参与者角色分配给代理池管理的标识。

• • 示例：**

我使用命令az aks create -g ansumantest -n MyAKSansuman --location uksouth --generate-ssh-keys创建了一个AKS群集。
如果我转到节点资源组MC_resource组，我会看到托管标识显示在那里：

在VMSS的Identity Blade中，您可以看到系统分配的标识不存在，但用户分配的标识存在，如下所示：
第一节第一节第一节第二节第一节
现在，如果我想在Keyvault中为AKS添加访问策略，那么我可以参考Managed-Identity：

一般来说，您只能使用上述方法为密钥保管库或AKS访问其他Azure服务所需的任何RBAC角色分配访问策略，因为AKS默认使用此策略。

当您分配VMSS时，它实际上是将角色分配给系统分配的托管身份。“MyAKS agentpool”是与您创建的托管身份不同的托管身份。
我们正在处理多个身份概念，不幸的是，它们并不都是超级清晰的。（你可以通读几篇文章，其中提供了一些启示：第一个电子0f1x，第一个电子1f 1x）
让我们来看看一些基本知识，这样答案就更有意义了：

1：当您创建AKS集群时，系统会为您创建一个系统分配的托管身份。集群使用此身份进行身份验证并执行需要执行的操作（例如管理VM）

2：当AKS创建VMSS时，它创建了一个“用户分配的托管身份”，该身份显示在门户的“MyAKS-agentpool”中。这是部署在VMSS上的身份，用于在该VMSS的上下文中对Kubelet进行身份验证。根据您尝试执行的操作，您可能会将其用于您的目的，而不是创建系统分配的托管身份。

3：当您在VMSS上使用“系统分配的托管身份”时，会导致在所有这些VM上部署系统分配的托管身份。系统分配的托管身份的概念是它是原始Azure资源本身的一部分：它不会显示为另一个实体。因此，当您为某个实体指定角色时，您选择的是VMSS（即使在幕后，系统分配的托管身份也会获得访问权限）。您不会在门户中发现它是一个单独的“托管身份”。

因此，希望这能回答您为什么必须将角色授予VMSS，而不是您在门户中看到的托管身份。
话虽如此：我一般认为做这种作业是个坏主意：因为系统分配的标识对于运行在节点上的每个pod都是可用的，而不管名称空间是什么。您可能需要比这更细的粒度，在这种情况下，更好的方法是使用https://learn.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity

我认为帖子中的步骤是错误的，用户分配的MSI是在默认情况下创建的，当你创建集群时，你可以使用这个MSI来验证其他服务。