Azure - 使用托管标识对 KeyVault 和其他资源的 AKS 进行身份验证

Question

我刚刚在我的 AKS 群集中设置了一个托管标识，以使用以下指南对 Azure Key Vault 资源进行身份验证：https://dev.to/vivekanandrapaka/access-secrets-from-akv-using-managed-identities-for-aks-91p

在指南中，我们在 VMSS 中设置了系统分配的托管标识。然后，我们将 VMSS 应用程序添加到 keyvault 中的访问策略中，这很有效，我的 AKS 群集中的 pod 现在可以访问我的 KeyVault 资源。

我的问题是，我计划使用托管标识来设置与 AKS 的其他连接。示例 AKS -> Blob 存储，AKS -> 认知服务。为了做到这一点，我是否会向这些其他服务中的每一个添加相同的 AKS VMSS 应用程序，让我们说一个“贡献者”角色。或者我会将创建为“贡献者”角色的托管身份对象分配给这些其他服务中的每一个吗？本质上我在问，为什么我要将此 VMSS 分配为角色而不是实际的托管身份对象？

任何澄清都会非常有帮助 - 谢谢，

Answer 1

当您创建 AKS 集群时，即使您没有指定任何内容，它也会默认创建 kubelet_identity。 Kubelet identity 是一个用户分配的身份。如果你去VMSS >> Identity，你会看到两个标签 System-Assigned 和 User-Assigned ，System-Assigned 默认是No 但在用户定义中，您会发现分配给它的aks-agentpool。因此，即使您不分配 System-Identity ，您也可以将贡献者角色分配给 Agentpool 托管身份。

示例：

我使用命令 az aks create -g ansumantest -n MyAKSansuman --location uksouth --generate-ssh-keys 创建了一个 AKS 集群。

如果我转到节点资源组的 MC_ 资源组，我会看到那里存在托管标识：

在 VMSS 的 Identity Blade 中，您可以看到如下所示系统分配的身份不存在，但用户分配的身份存在：

现在，如果我想在 Keyvault 中为 AKS 添加访问策略，那么我可以参考 Managed-Identity：

通常仅使用上述方法，您可以为密钥保管库或 AKS 访问其他 Azure 服务所需的任何 RBAC 角色分配访问策略。因为 AKS 默认使用它。

Answer 2

当您分配 VMSS 时，实际上是在将角色分配给系统分配的托管标识。 “MyAKS 代理池”是与您创建的不同的托管身份。

我们正在处理多个身份概念，不幸的是，所有这些概念都不是很清楚。 （您可以阅读几篇有所启发的文章：https://docs.microsoft.com/en-us/azure/aks/concepts-identity、https://docs.microsoft.com/en-us/azure/aks/use-managed-identity）

让我们了解一些基础知识，这样答案就更有意义了：

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

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

#3：当您在 VMSS 上使用“系统分配的托管标识”时，会导致在所有这些 VM 上部署系统分配的托管标识。系统分配的托管标识的概念是它是原始 azure 资源本身的一部分：它不会显示为另一个实体。因此，当您为某事赋予角色时，您就是在选择 VMSS（即使在幕后，访问权限被授予系统分配的托管标识）。您不会在门户中找到它作为单独的“托管身份”。

因此，希望这能解答您为什么必须将该角色授予 VMSS 而不是您在门户中看到的托管身份。

说了这么多：我通常认为进行这种分配是个坏主意：因为系统分配的身份对节点上运行的每个 pod 都可用，而与命名空间无关。而且您可能需要比这更好的粒度，在这种情况下，更好的方法是使用https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity