Add support for cluster endpoint access control

[rjkernick]

I know the feature is recent, but I would like to set the cluster endpoint access control as shown here: https://docs.aws.amazon.com/eks/latest/userguide/cluster-endpoint.html

I may be wrong, but I don't see the option currently

[janwillies]

This feature would be helpful for enterprise adoption

[Josh-Tilles]

Something to consider when implementing this: it would be great if the library accounted for ensuring that the machine that it’s running on has access to the cluster API, probably via an additional extra security group rule or assertion. (See https://docs.aws.amazon.com/eks/latest/userguide/sec-group-reqs.html)

[lukehoban]

Something to consider when implementing this: it would be great if the library accounted for ensuring that the machine that it’s running on has access to the cluster API, probably via an additional extra security group rule or assertion. (See https://docs.aws.amazon.com/eks/latest/userguide/sec-group-reqs.html)

This is a great point. If public=false,private=true then the @pulumi/kuberentes API calls we make will not succeed by default. The two options I can think of are:

1. Automatically add a SG ingress rule targetting the IP of the current machine (potentially NATed?)
2. 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).

(2) would require some slightly non-trivial manual configuration - but should otherwise be reliable.

(1) is "automatic" but doesn't feel reliable - for one its subtly defeating security best-practices by default. But then also if deployments happen from different IPs (even different IPs within a single CI system), there will be unexpected churn in the deployment.

I think I'll solve for (2) for now, and we could explore (1) or some variant of it as an ease-of-use addon in the future if really needed (though I suspect that ease-of-use will not be aligned with private-only endpoint access :-)).

Thoughts?

[metral]

I agree that option 2 is the best path forward.

I've added some comments in #154 (comment).