我的AKS群集配置了enableAzureRBAC=true
我试图通过通量安装ingress-nginx Helm 图
它抛出错误
reconciliation failed: failed to get last release revision: query: failed to query with labels: secrets is forbidden: User "system:serviceaccount:nginx:flux-applier" cannot list resource "secrets" in API group "" in the namespace "default": Azure does not have opinion for this user.
我可以看到flux设置了一个clusterrolebinding,以使flux应用程序成为群集管理员,我已经验证了这一点
Name: flux-applier-binding
Labels: <none>
Annotations: <none>
Role:
Kind: ClusterRole
Name: cluster-admin
Subjects:
Kind Name Namespace
---- ---- ---------
ServiceAccount flux-applier flux-system
因此,我假设我的问题是Azure不识别此ServiceAccount,并且它没有回退到内置角色?
https://github.com/kubeguard/guard/blob/master/authz/providers/azure/rbac/checkaccessreqhelper.go
Azure RBAC for AKS上的Azure文档明确指出:
如果发出请求的标识存在于Azure AD中,Azure将与Kubernetes RBAC协作对请求进行授权。如果该标识存在于Azure AD之外(即Kubernetes服务帐户),则授权将遵从正常的Kubernetes RBAC。
https://learn.microsoft.com/en-us/azure/aks/concepts-identity
但这似乎不是真的?或者也许Flux正在对ServiceAccounts做一些奇怪的事情?我这么说是因为在默认名称空间中没有flux-applier服务帐户,只有在flux-system名称空间中。然而,如果我通过Kubectl将cluster-admin分配给“ghost”服务帐户,事情就开始工作了。
kubectl create clusterrolebinding flux-nginx-cluster-admin --clusterrole=cluster-admin --serviceaccount=nginx:flux-applier
我想避免这样做,虽然,似乎不像是我应该负责的事情。
1条答案
按热度按时间g6ll5ycj1#
我尝试在我的环境中重现相同的问题,结果如下
我已经创建了配置了RABC的AKS群集
将此链接用于reference files
***注意:**如果Azure无法识别服务帐户,则必须给予默认服务的权限 *
有关详细信息,请参阅此url