The Auth Template That Trusted Its Caller: AccessKeyID Injection in EKS

When users authenticate to an Amazon EKS cluster via a kubectl command, a series of components work together to transform an AWS identity into a Kubernetes user. The aws-iam-authenticator client generates a signed STS GetCallerIdentity request and passes the URL to the cluster as a presigned bearer token. The cluster's webhook authenticator extracts the AWS principal's identity from the URL, verifies the signature, and maps the identity to a Kubernetes user using an identity-mapping template.

An existing bug allowed AccessKeyID injection in this process. The identity-mapping template previously supported the {{AccessKeyID}} substitution, intended to correlate AWS access key IDs with Kubernetes usernames for auditing purposes. However, the webhook parsed the AccessKeyID from client-supplied URL query parameters (X-Amz-Credential) instead of the STS response.

This created an HTTP parameter pollution vulnerability, where an attacker could add a case-variant duplicate query parameter, causing the parsers to interpret different values for the same parameter.

As a result, the AWS STS authenticated the request as a valid AWS principal (VICTIM_KEY), while the aws-iam-authenticator substituted the attacker-supplied ATTACKER_KEY, granting the attacker a different Kubernetes user than authorized by AWS. The fix requires using server-derived values, such as SessionName or role ARN, instead of client-influenced values like AccessKeyID.

Alternatively, using an ARN-based mapping eliminates the potential for client-supplied value injection. The remediation involves updating the identity-mapping template to use {{SessionName}} or {{SessionArn}} instead of {{AccessKeyID}}.