“ az aks create”为每个AKS集群重用服务主体。这样安全吗？

Question

共享多个AKS群集的服务主体是否允许一个群集弄乱另一个AKS群集的资源？一个目标应该为每个AKS群集创建一个服务主体吗？ Azure CLI和Terraform之类的工具似乎都鼓励这种做法。

下面的长话：

我们需要为每个客户创建一个AKS集群，以确保另一级别的数据隔离。具体来说，假设攻击者可以某种方式闯入Pod，逃避Pod隔离，访问群集的Kubernetes API和群集的Service Principal（SP），则说攻击者不应访问另一个群集的持久卷声明。

Azure CLI一次创建一个服务主体，并将其重新用于下一个群集（documentation，source code）：

  

当您使用az aks create命令自动生成服务主体时，服务主体凭据将被写入用于运行该命令的机器上的文件〜/ .azure / aksServicePrincipal.json。

由于不确定群集的SP可以（或应该）执行多少操作，我发现以下相当混乱的信息：

1. 文档说：

     

   要与Azure API进行交互，AKS群集需要Azure Active Directory（AD）服务主体。需要服务主体来动态创建和管理其他Azure资源，例如Azure负载平衡器或容器注册表（ACR）。 [重点]

   这表明群集SP必须有权访问群集的资源组（RG）-即由群集创建的所有资源所在的RG，而不是在其中创建群集的RG。 这很糟糕，因为这意味着要在AKS群集之间共享SP，则要求该SP有权访问所有群集RG。

2. 稍后的文档表明，没有任何作用的SP就是足够的：

     

   az ad sp create-for-rbac --skip-assignment --name terraform-aks-ng-sp

   我还可以通过从Cloud Shell中进行检查来确认这一点：

   PS Azure:\> az role assignment list --assignee http://terraform-aks-ng-sp
   []
   Azure:/
   

   空白列表表明SP没有角色。 这很好（或可能会更好），因为只能授予共享SP访问真正共享的资源（例如容器注册表）的权限。

3. 但是，Azure门户建议SP确实可以访问群集的RG：

   

   这就像回到第1平方。这很糟糕，因为共享SP似乎隐式地允许访问所有群集RG。

更新：即使Terraform，似乎也鼓励在AKS群集之间共享SP。

Answer 1

这里的问题在哪里？只需在创建每个AKS时为其指定一个特定的服务主体。您不应该使用Azure CLI创建资源，还是应该使用某种工具（pulumi，ansible等）