[EKS] [request]: Hosname Alias in Cluster CA

[lkishalmi]

Tell us about your request An optional parameter which can add a custom hostname in the cluster CA during the cluster creation.

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? This issue is slightly related to #221 as we are trying to make use of the private endpoints in a heavily routed, multi data center and cloud environment. Our idea is to place an inbound resolver endpoint to our VPC where we have a private DNS zone and set up the dns resolution in the corporate network to route name resolving of .example.com domain names through this resolver. Then we jsut would place a CNAME record to the api endpoint as api..example.com. Actually this works pretty well till we get to the real HTTPS requests.

We get:

Unable to connect to the server: x509: certificate is valid for ip-172-16-37-253.us-west-2.compute.internal, kubernetes, kubernetes.default, kubernetes.default.svc, kubernetes.default.svc.cluster.local,  <endpoint>.us-west-2.eks.amazonaws.com, not api.<cluster name>.example.com

It would be nice, that during the creation of the cluster an alias hostname could be added to the certificate.

Are you currently working around this issue? We mark the cluster insecure using: insecure-skip-tls-verify: true in the kubeconfig

[adammw]

+1 for this feature, our use case is similar in that we would like to use a more user-friendly DNS name for the cluster that is CNAME'd to the "real" hostname, as well as giving us the option to switch out the underlying cluster to a new one if needed down the track.

Currently when we do that we see the same TLS error because the certificate is only valid for the hostname that the API server expects. Adding additional custom domains to the certificate would solve the issue.

[fv-ian]

What can we do to upvote this?

[dilipsthapa]

+1 for this feature.

[farhatmihalko]

Hello folks! Are there any plans to work on this request?

Thank you.

[Eugst]

+1 pretty please

[Jufik]

+1

[sudharsanpunniyakotti]

+1

[rr-paras-patel]

+1

[cespo]

+1

[nomadramanujan]

+1

[grandwizard28]

+1

[userhas404d]

probably not a comprehensive solution for all workflows but I just fronted an EKS cluster api endpoint with privatelink and wasn't keen on insecure-skip-tls-verify: true. I was able to get around this by defining the KUBE_TLS_SERVER_NAME env var with a hostname provided in the cluster ca cert and setting the cluster endpoint to the "friendly", privatelink backed hostname.

Being able to add additional host names to the cluster api endpoint cert would def be ideal here though.