我已经从门户设置了一个AKS集群。启用了Kubernets RBAC，但没有与AAD集成。x1c 0d1x
当我用我的用户（也是集群管理员）登录并执行az aks get-credentials --name <cluster-name> --resource-group <resource-group>时，上下文被添加到./kube/config文件中，我从那里复制了客户端证书数据字段，解码后发现CN = masterclient O = system:masters是我的证书所拥有的。在AKS中，有一个现有的ClusterRoleBinding，允许组系统为masters的用户访问所有集群。
现在，我添加了一个ServicePrincipal，并仅在AKS集群上将其分配到以下角色。
当我执行az login --service-principal --username <sp_name> --password <pwd> --tenant <tenant_id>和
az aks get-credentials --name <cluster-name> --resource-group <resource-group>我发现同一个system:masters被设置为client-certificate-data中的组，并且对集群具有完全访问权限。
这种行为是否正确？证书数据中的CN和Group不应该是不同的master，然后我们需要额外的角色/群集角色绑定来管理它们吗？
1条答案
按热度按时间3zwtqj6y1#
我猜如果启用了“使用Kubernetes RBAC的本地帐户”选项，则“Azure Kubernetes服务群集用户角色”或“Azure Kubernetes服务群集管理员角色”这两个角色的行为是相同的。如果我们执行
az aks get-credentials，我们将获得这两个角色的相同证书，这在下面的文章中的注解中也提到了。我们需要将AKS与Azure AD集成，以实现我所期望的特定行为。https://learn.microsoft.com/en-us/azure/aks/control-kubeconfig-access
编辑日期：2023年1月1日
即使使用本地帐户，也可以为单个用户执行RBAC。我们需要确保为每个用户/组提供单独的证书，并且需要在kubernetes群集中创建相应的角色/角色绑定。有关证书自动化，请参阅
https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/
P.S：证书中的- CN是RoleBinding中对应的User主题，而证书中的O代表角色绑定中的组。