We are using AWS EKS, we came to know about the recent CVE( Kubernetes API Server JSON/YAML parsing vulnerable to resource exhaustion attack). The recommendation is to make the RBAC policies strict as much as we can. From application level, we have a very strict RBAC control, but external services like metrics server, cluster-autoscaler and few more were creating role, rolebinding, clusterrole, clusterrolebinding for their service account. we don’t know whether these things(cluster-autoscaler & metrics server)will really work if we change the role and cluster roles since we download these chart and apply. Is there any recommended approach for RBAC on these autoscaling parts.
2 Likes
Hi Dinesh,
May I know which version of Kubernetes you are using in your AKS. The vulnerability currently effects version 1.14.5 and all all previous ones ( 1.13, 1, 1.9, 1.8)
Regarding remediation, their can be two approach in this problem;
a) Rather than ensuring unauthenticated users are not granted any privileges via RBAC, you can disable anonymous access completely by passing the --anonymous-auth=false flag to both the API server and the Kubelets.
b) You can continue with your RBAC policies as defined by Service accounts for metrics server and other resources. Any role bindings that grant privileges to the system:anonymous user or the system:unauthenticated group should be thoroughly reviewed or removed if deemed unnecessary.
1 Like
Thanks Suman for the response. I am using AWS EKS version 1.14. I will try to put this option --anonymous-auth=false
Thanks Suman. Currently we give service account a particular role, but any pod can pretend to be that service account right, means any pod I can mention that service account name right so that pod can get all the access given to that service account. Is there a way I can mention that only a particular deployment or pod should use that service account