Add support for endpoint access control and custom cluster securitygroup

[lukehoban]

Expose these options through to the aws.eks.Cluster.

Fixes #86.

[metral]

Per https://docs.aws.amazon.com/eks/latest/userguide/cluster-endpoint.html#modify-endpoint-access, when endpointPrivateAccess = true and endpointPublicAccess = false we have no internet access to the cluster. This means that to test this in tests requires a VM in the same VPC issuing the commands to the APIserver - either via kubectl or client-go. We should consider adding VM + test to our test suite.

Also per the defaults here of undefined for both if not provided - this does not match the state of what EKS defaults to (public: true, private: false) - do you foresee any issues with this mismatch?

[lukehoban]

This means that to test this in tests requires a VM in the same VPC issuing the commands to the APIserver - either via kubectl or client-go

It's actually even worse than that - we won't even be able to successfully deploy resources into the Kubernetes cluster from the machine running pulumi up as needed to complete initialization - so the deployment will fail. I was just about to reply with some options on this on #86 (comment).

[lukehoban]

Also per the defaults here of undefined for both if not provided - this does not match the state of what EKS defaults to (public: true, private: false) - do you foresee any issues with this mismatch?

It passes through the underlying defaults - we'll pass undefined (not present) which will trigger the underlying default value. Right?

[metral]

It passes through the underlying defaults - we'll pass undefined (not present) which will trigger the underlying default value. Right?

Ya you're correct - I initially skipped over the undefined more than I should've and that's what caused me confusion. Ignore this comment 👍

[metral]

From #86 (comment):

Ensure that users can provide a custom Cluster security group so that they can configure ingress with the CIDR blocks, IPs or other SGs they want to have access (and document that deployments will only be possible if done from an IP within one of these).

It'd be really great to see new examples added to the examples directory of privateAccess clusters with an accompanying VM in the same the VPC, for each of the config scenarios of the custom secgroup you list out (CIDR, IP, and other SGs).

[lukehoban]

It'd be really great to see new examples added to the examples directory of privateAccess clusters with an accompanying VM in the same the VPC

Yeah - I'll add a test before merging this. It's more involved that I initially expected unfortunately - it'll require setting up VPN endpoints inside the AWS VPC and creating a VPN connection from the test machine (or Travis). That's going to add non-trivial complexity to the test environment.

[metral]

LGTM. We'll want to rebase this PR off master once #162 get's merged.

[lukehoban]

@metral After spending some time thinking about this - it's actually going to be exceedingly hard to test private-only endpoint access - as it will require VPN'ing the test machine into the VPC - or running the pulumi deployment from a bastion host in the VPC - neither of which is going to be easy to do in our current test/CI setup.

Given that this is mostly just passing flags through to EKS, I'm inclined to merge this to unblock all the usage scenarios here (including private+public) - and to open a follow-up issue to add test coverage (and examples) of private-only endpoint access.

Thoughts?

[metral]

Given that this is mostly just passing flags through to EKS, I'm inclined to merge this to unblock all the usage scenarios here (including private+public) - and to open a follow-up issue to add test coverage (and examples) of private-only endpoint access.

That SGTM @lukehoban. I feel like the follow-up issue for test coverage & examples applies to not only pulumi/eks, but generally speaking, @pulumi/pulumi also for testing updates & flow from a bastion + VPC + private subnets client or CI setup.