[EKS] [bug]: Update VPC Endpoint Interface definition for the EKS Auth API

[daniel-rhoades]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Tell us about your request
Update the definition for the EKS Auth API (eks-auth) VPC Endpoint Interface:

• Service name: Consider updating from com.amazonaws.{{ Region }} .eks-auth to eks.{{ Region }}.api.aws (as documented)
• Certificate: Additional SANs for eks-auth.eu-west-2.vpce.amazonaws.com and eks-auth.eu-west-2.amazonaws.com

Also, consider updating the Pod Identity Agent to support both post and pre August 2024 DNS names eks.region.amazonaws.com and eks.region.api.aws (e.g. fallback behaviour).

Which service(s) is this request for?
EKS

Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?
When deploying a private EKS cluster into a private VPC, several VPC Endpoint Interfaces are required, specifically, if using Pod Identity - EKS Auth API (eks-auth).

The below was observed when creating the eks-auth endpoint in the eu-west-2 region with DNS disabled (as we manage DNS through a separate Route53 PHZ as all VPC endpoints are provisioned into a shared network). Accepting part of the below will be due to legacy reasons.

Noting https://docs.aws.amazon.com/eks/latest/userguide/vpc-interface-endpoints.html, endpoints created after August 2024 will be dual-stack. Our endpoint probably was created around that time, but even after re-creating it the certificate is still invalid against requests for curl -I https://eks-auth.eu-west-2.amazonaws.com which is inconsistent with other endpoints (such as the EKS API):

*.eks.eu-west-2.vpce.amazonaws.com
eks.eu-west-2.api.aws
eks.eu-west-2.vpce.amazonaws.com
eks.eu-west-2.amazonaws.com

vs.

{{ Ref }}.eks-auth.eu-west-2.api.aws
eks-auth.eu-west-2.api.aws
*.eks-auth.eu-west-2.vpce.amazonaws.com
lb-{{ Id }}-{{ Ref }}.eks-auth.eu-west-2.api.aws

For consistency, the following could be added: eks-auth.eu-west-2.vpce.amazonaws.com and eks-auth.eu-west-2.amazonaws.com.

This contributed to an issue that was hard to debug, there was no information (in the AWS Console) when creating this endpoint to suggest an alternative service DNS record was required.

The Pod Identity Service only seems to make requests for eks-auth.{{ region }}.api.aws, after timing out, there was no information in the EKS event logs to identify the hostname. Ideally it should support both pre and post August 2024 hostnames.

Are you currently working around this issue?
Route53 PHZs.

Additional context
None.

Attachments
None.

[yue9944882]

@daniel-rhoades just for clarification, there's no pre-2024-august domain for Pod Identity feature as it's launched at ~Nov 2024, hence the domainhttps://eks-auth.eu-west-2.amazonaws.com never existed. Additionally, the service name of our VPC endpoint com.amazonaws.{{ Region }} .eks-auth is an identifier following our naming convention but it doesn't imply the access service name to be exactly eks-auth.eu-west-2.amazonaws.com.

creating the eks-auth endpoint in the eu-west-2 region with DNS disabled

As you mentioned that you disabled DNS for the VPC endpoint, you can workaround and access the VPC ednpoint by a *.eks-auth.eu-west-2.vpce.amazonaws.com domain (this generated domain name can be found via describing the VPC endpoint)