New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

EKS PrivateLink Support #22

Open
pauncejones opened this Issue Dec 5, 2018 · 13 comments

Comments

@pauncejones
Copy link
Contributor

pauncejones commented Dec 5, 2018

Provide customers with private endpoint access to EKS.

@pauncejones pauncejones created this issue from a note in containers-roadmap (We're Working On It) Dec 5, 2018

@pauncejones pauncejones added the EKS label Dec 5, 2018

@uprightvinyl

This comment has been minimized.

Copy link

uprightvinyl commented Dec 11, 2018

Could you clarify if this for the EKS API or the Kubernetes API, or both? If its the Kubernetes API, that is great. Currently, having to reach out over the internet from worker nodes in private subnets to EKS masters is whats stopping us from using EKS.

@sriv1211

This comment has been minimized.

Copy link

sriv1211 commented Dec 12, 2018

When you create a VPC endpoint, a record resolving to a VPC IP address is generated in the private DNS.
In principle, this should just mean that nodes inside the VPC will resolve to the VPC endpoint, and all internal traffic will be internal to the VPC, whilst external nodes will resolve to the public IP address?

If the system was designed this way then the internal and external endpoints wouldn't need to know about each other and can coexist. Is this not how all other VPC endpoints work?

@micahhausler

This comment has been minimized.

Copy link
Member

micahhausler commented Dec 17, 2018

This roadmap item is specifically for the Kubernetes cluster API endpoint, not the EKS API.

@uprightvinyl

This comment has been minimized.

Copy link

uprightvinyl commented Dec 17, 2018

This roadmap item is specifically for the Kubernetes cluster API endpoint, not the EKS API.

Great news, thats what we need. Thanks for the update.

@senyan

This comment has been minimized.

Copy link

senyan commented Jan 9, 2019

What is the estimated timeline for this? Seems this will be a major security improvements.

@NickLarsenNZ

This comment has been minimized.

Copy link

NickLarsenNZ commented Jan 16, 2019

this would be super helpful as we have to limit worker exposure to the internet for some clusters.

@kplimack

This comment has been minimized.

Copy link

kplimack commented Jan 18, 2019

I cannot use EKS at all if the api is exposed to the internet, its a non-starter. This feature is a must for me

@sonykus

This comment has been minimized.

Copy link

sonykus commented Jan 24, 2019

Same as above. To us, this is a complete showstopper.

@pwdebruin1

This comment has been minimized.

Copy link

pwdebruin1 commented Jan 28, 2019

Doesn't this blog article already suggest it exists? I don't see a way to forward your PrivateLink NLB to the EKS API endpoint though? Or the actual endpoint being listed under AWS services as with ECS.

@kzwang

This comment has been minimized.

Copy link

kzwang commented Feb 11, 2019

It seems this is partially supported? I saw there are 2 ENI created in my EKS VPC, if I modify the worker node manually (changing hosts file to point the EKS API Server DNS to the private IP of the ENI or change the kubeconfig file to use the private IP for the server address), it can connect to the master through private IP address successfully. Just the EKS master's DNS resolves to public IP addresses currently.

@micahhausler

This comment has been minimized.

Copy link
Member

micahhausler commented Feb 11, 2019

@pwdebruin1 that blog is incorrect, we'll get that corrected.

@kzwang the approach you suggest does not transit the internet, but those IPs are subject to change as API servers are upgraded or undergo routine change.

@tdmalone

This comment has been minimized.

Copy link

tdmalone commented Feb 13, 2019

This roadmap item is specifically for the Kubernetes cluster API endpoint, not the EKS API.

Just to clarify (k8s newbie here), docs state that:

Worker nodes also require outbound internet access to the Amazon EKS APIs for cluster introspection and node registration at launch time.

Do those docs actually mean the Kubernetes cluster API? I'm assuming worker nodes would not need to access the EKS API for any standard sort of deployment (just working out whether I want the roadmap item specified by this issue, or separately PrivateLink support for the EKS API as well).

@nrdlngr

This comment has been minimized.

Copy link

nrdlngr commented Feb 13, 2019

https://github.com/awslabs/amazon-eks-ami/blob/master/files/bootstrap.sh#L86

By default, the worker node bootstrap script calls the Amazon EKS API to get the API server endpoint and cluster's certificate authority data.

If you launch your node group by following the steps here, you can bypass this call by specifying the API server endpoint and cluster certificate authority data as BootstrapArguments when you launch the node group.

https://github.com/awslabs/amazon-eks-ami/blob/master/files/bootstrap.sh#L20

@tabern tabern moved this from We're Working On It to Coming Soon in containers-roadmap Feb 15, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment