默认情况下，创建 AKS 群集时会为该群集创建服务主体。
然后可以在其他 Azure 资源(VM？)的级别上设置该服务主体，以便它们能够建立网络连接并能够进行通信(当然常规网络设置除外) )
我真的不确定也无法理解什么时候需要这样做，什么时候不需要。例如，如果我在 VM 级别上有数据库，我是否需要授予 AKS 服务主体对 VM 的访问权限，以便能够通过网络与其进行通信？
有人可以为此提供一些指导，而不是一般文档。何时需要在其他 Azure 资源级别上使用/设置，何时不需要？ 我对此找不到正确的解释。 谢谢
最佳答案
关于您有关数据库的问题，您不需要向服务主体授予对该虚拟机的任何访问权限。鉴于数据库在 Kubernetes 外部运行，不需要以任何方式访问该虚拟机。数据库甚至可以位于不同的数据中心或完全托管在另一个云提供商上，只要防火墙等允许流量，在 kubernetes 内运行的应用程序仍然能够与其通信。
我知道您没有要求通用文档，而是要求 Kubernetes Service Principals 上的文档说得好:
To interact with Azure APIs, an AKS cluster requires either an Azure Active Directory (AD) service principal or a managed identity. A service principal or managed identity is needed to dynamically create and manage other Azure resources such as an Azure load balancer or container registry (ACR).
换句话说，服务主体是 Kubernetes 集群在与其他 Azure 资源交互时进行身份验证的身份，例如:
- Azure container registry :创建容器的镜像必须来自某个地方。如果您将自定义镜像存储在私有(private)注册表中，则必须授权集群从注册表中提取镜像。如果私有(private)注册表是 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
关于Azure Kubernetes 服务 - 何时需要在其他 Azure 资源上设置 AKS 服务原则才能建立连接？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/65954507/