Fixes issuedĪmiga told The Daily Swig that the vulnerability was difficult to locate, and that it was also tricky to notice that values can be overridden while STS ignores unexpected additional request parameters. The exploitation of the username through the AccessKeyID was possible since September 2020. As such, both the changing action and unsigned cluster ID tokens were exploitable since day one. The vulnerable root cause was present since the first commit in October 2017. Read more of the latest news about security vulnerabilitiesĪmiga wrote: “Because the for loop is not ordered, the parameters are not always overridden in the order we want, therefore we might need to send the request with the malicious token to the AWS IAM Authenticator server multiple times. “The cool thing is that AWS STS will ignore the parameter it does not expect, in this case AWS STS will ignore the action parameter. Researcher Gafnit Amiga of Lightspin detailed in a blog post how an attacker can send two different variables with the same name but with different uppercase and lowercase characters – for example, they are able to send both ‘Action’ and ‘action’.Īmiga explained: “Since both are… ‘ ToLower’, the value in the queryParamsLower dictionary will be overridden while the request to AWS will be sent with both parameters and their values. Tracked as CVE-2022-2385, the now-patched vulnerability could allow an attacker to impersonate other users and escalate privileges in Elastic Kubernetes Service (EKS) clusters configured with AccessKeyID template parameter.Īn attacker could craft a malicious signed request to Security Token Service (STS) GetCallerIdentity endpoint that includes the same parameter multiple times with different values. I hope this will help everyone using AWS EKS.Flaw in Amazon’s Kubernetes service has since been fixedĪ vulnerability in AWS IAM Authenticator for Kubernetes could allow a malicious actor to impersonate other users and escalate privileges in Kubernetes clusters, a security researcher has discovered. The above steps should get you to onboard your EKS cluster into lens but please note, the steps will be different if you are not using AWS EKS. Once you have selected the kubeconfig file, it will ask you to select the context, select the required context and then click on button at the bottom "Add cluster(s)" which will then start the authentication and add the objects into lens for your consumption. kube folderĬlick on + button on the top left corner which will give you an option to upload kubeconfig or paste it manually.
Please replace the path "C:\Users" with the that of the current logged in user to get to the. The kubeconfig should be located under C:\Users.kube\config. Region-code = Region where EKS cluster is located such as ap-southeast-1Ĭluster_name = Name of the cluster in that region Note: replace the following with your desired values:
Aws iam authenticator install#
Install aws-iam-authenticator on Windows using chocolateyĪws eks -region region-code update-kubeconfig -name cluster_name I will describe the steps performed below even though they are documented to ensure you do not have to move between different documentation pages:ġ. Even though I just tried Lens for Windows but I have authenticated kubectl client running on Linux servers numerous time to say confidently that it should work. The process is well documented in AWS under Cluster Authentication section along with the steps and they work fine for both Windows and Linux.
Aws iam authenticator download#
You will need to download the kubeconfig file and save it in ~/.kube folder so lens can read the file and then contact the Kube-ApiServer and aws-auth get the access to the EKS cluster. Therefore, I decided to document the steps to make it easier for Lens users.įor AWS EKS, Lens can be treated as just another client which requires kubectl access. Although it only requires a kubeconfig - whether you paste it or upload it, the outcome is that it will connect to your cluster and authenticate with it to load all the objects into the Lens. I decided to onboard one of my AWS EKS clusters on it but I was not able to find any documentation for Lens with AWS EKS. I felt daily administration and interaction with the EKS cluster can really be simplified with these 2 features. Built-In terminal which will ensure that it matches the Kube APIServer version with the version of kubectl.Built-In Prometheus monitoring setup with RBAC maintained for each user so users will see only the permitted resources visualizations.Today, while working on a personal kubernetes project, I came across Lens - The Kubernetes IDE and was impressed by a couple of its features:
0 kommentar(er)
