问题描述
默认情况下，在创建 AKS 群集时，会为该群集创建服务主体。
然后可以在其他一些 Azure 资源（VM？）的级别上设置该服务主体，以便它们能够建立网络连接并能够进行通信（当然一般网络设置除外)
我真的不确定，也不明白什么时候需要，什么时候不需要。例如，如果我在 VM 级别拥有数据库，是否需要授予 AKS 服务主体对 VM 的访问权限，以便能够通过网络与其进行通信？
有人可以为此提供一些指导，而不是一般文档。什么时候需要在其他 Azure 资源的级别上使用/设置，什么时候不需要？ 我找不到对此的适当解释。 谢谢
解决方法
关于您关于数据库的问题，您无需授予服务主体对该 VM 的任何访问权限。鉴于数据库在 Kubernetes 之外运行，不需要以任何方式访问该 VM。数据库甚至可以位于不同的数据中心或完全托管在另一个云提供商上，只要防火墙等允许流量，运行在 kubernetes 中的应用程序仍然可以与其通信。
我知道您没有要求提供通用文档，但 Kubernetes Service Principals 上的文档说得很好：
要与 Azure API 交互，AKS 群集需要 Azure Active Directory (AD) 服务主体或托管标识。一种 动态创建需要服务主体或托管标识 并管理其他 Azure 资源，例如 Azure 负载均衡器或 容器注册表 (ACR)。
换句话说，服务主体是 Kubernetes 集群在与其他 Azure 资源交互时进行身份验证的身份，例如：
- Azure container registry：创建容器的镜像必须来自某个地方。如果您将自定义映像存储在私有注册表中，则必须授权集群从注册表中提取映像。如果私有注册表是 Azure 容器注册表，则必须为这些操作授权服务主体
- Networking：Kubernetes 必须能够动态配置路由表并在负载均衡器中为服务注册外部 IP。同样，服务主体用作身份，因此必须对其进行授权
- Storage：访问磁盘资源并将它们挂载到 Pod 中
- Azure Container instances：如果您使用虚拟 kubelet 向集群动态添加计算资源，则必须允许 Kubernetes 管理 ACI 上的容器。
对于 delegate access to other Azure resources，您可以使用 azure cli 将角色分配给特定范围内的受理人：
az role assignment create --assignee <appId> --scope <resourceScope> --role Contributor