Skip to content
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

Enable management of access to public/private API endpoints #1149

Merged
merged 26 commits into from
Oct 9, 2019

Conversation

D3nn
Copy link
Contributor

@D3nn D3nn commented Aug 15, 2019

Description

Enable the ability to allow/deny access to the API server endpoint publicly (from the Internet) or privately (from Worker nodes, Direct Connect networks, VPN networks, etc).

Resolve #649

Checklist

  • Code compiles correctly (i.e make build)
  • Added tests that cover your change (if possible)
  • All unit tests passing (i.e. make test)
  • Added/modified documentation as required (such as the README.md, and examples directory)
  • Manually tested

@D3nn D3nn self-assigned this Aug 15, 2019
@D3nn D3nn added this to the 0.5.0 milestone Aug 15, 2019
Copy link
Contributor

@martina-if martina-if left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only a change to the site?

@D3nn
Copy link
Contributor Author

D3nn commented Aug 16, 2019 via email

Copy link
Contributor

@rndstr rndstr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

documentation is easy to understand 👍 i would want to know what the default is, though.

Edit: or is the default going to stay as is (Public=true, Private=false)?

@D3nn D3nn force-pushed the toggle-public-private-endpoint-access branch 2 times, most recently from b4d0eea to bb1aca5 Compare August 21, 2019 17:57
@errordeveloper
Copy link
Contributor

errordeveloper commented Aug 30, 2019

I think we will need document considerations around using private-only. E.g. it should be doable if you are managing the VPC externally.

The main challenge is that aside from AWS API calls we do need to make calls to Kubernetes API, e.g. to update kube-system:ConfigMap/aws-auth. It's possible to design it in a way that lets you create a cluster from any machine and disable public right at the very end. The reason we'd have to do it that way is that we create the VPC, we could explore shared VPC more (#892), but in any case there are a few things to think about.

@errordeveloper
Copy link
Contributor

I opened #1230.

@errordeveloper errordeveloper modified the milestones: 0.5.0, 0.6.0 Aug 30, 2019
@D3nn
Copy link
Contributor Author

D3nn commented Aug 30, 2019

I think we will need document considerations around using private-only. E.g. it should be doable if you are managing the VPC externally.

The main challenge is that aside from AWS API calls we do need to make calls to Kubernetes API, e.g. to update kube-system:ConfigMap/aws-auth. It's possible to design it in a way that lets you create a cluster from any machine and disable public right at the very end. The reason we'd have to do it that way is that we create the VPC, we could explore shared VPC more (#892), but in any case there are a few things to think about.

I'll remove that as an option until we can address the kubernetes API calls.

@D3nn
Copy link
Contributor Author

D3nn commented Sep 3, 2019

I think we will need document considerations around using private-only. E.g. it should be doable if you are managing the VPC externally.

The main challenge is that aside from AWS API calls we do need to make calls to Kubernetes API, e.g. to update kube-system:ConfigMap/aws-auth. It's possible to design it in a way that lets you create a cluster from any machine and disable public right at the very end. The reason we'd have to do it that way is that we create the VPC, we could explore shared VPC more (#892), but in any case there are a few things to think about.

I'll remove that as an option until we can address the kubernetes API calls.

I think we will need document considerations around using private-only. E.g. it should be doable if you are managing the VPC externally.

The main challenge is that aside from AWS API calls we do need to make calls to Kubernetes API, e.g. to update kube-system:ConfigMap/aws-auth. It's possible to design it in a way that lets you create a cluster from any machine and disable public right at the very end. The reason we'd have to do it that way is that we create the VPC, we could explore shared VPC more (#892), but in any case there are a few things to think about.

As it stands currently, the vpc endpoint updates happen as a separate task after the other tasks have completed since it is an AWS API call and not a CloudFormation configuration item. That means that a cluster creation wouldn't be affected by this issue but it would then subsequently block access to the "writekubeconfig" functionality (as well as any other calls that rely on K8s API access to function properly).

@InAnimaTe
Copy link

Just wanted to stop by and say awesome work @D3nn and others involved in making this happen! Been wanting this feature for a while and glad to see some awesome people are pushing it forward.

@D3nn D3nn force-pushed the toggle-public-private-endpoint-access branch 2 times, most recently from 3ae9ad2 to d508d86 Compare September 17, 2019 19:20
@D3nn D3nn changed the title (WIP) Enable management of access to publc/private API endpoints Enable management of access to publc/private API endpoints Sep 17, 2019
D3nn and others added 17 commits October 8, 2019 17:47
1. Removed True/False in favor of Enabled()/Disabled
1. Updated api.IsSet to take interfaces and expanded it's use
1. Added 'WithoutArg' to runner to allow removing region, which
interfered with use of the configfile for creating clusters
1.  Reset values of create/delete/updateCluster to make output more
readable
1. Changed integration test EndpointAccessCases to EndpointAccessCase
to reflect how it was being used.
1. Refactored tests to make deleteCluster a separate test case
1. No need to export EndpointAccessCase structs in tests (fixed)
1. Revert IsSet changes in favor of foo != nil
1. Rewording messages to not use Cluster API since it is possibly
confusing
1. Renamed utils subcommand to update-cluster-endpoints
1. Refactoring in vpc_test.go
1. Renamed some functions to match how others are named
1. Changed the way `eksctl utils update-cluster-endpoints` shows what
will be upated
1. Fixed issue that would cause tasks to not run in certain cases
1. Fixed example command in 06-vpc-networking.md
1. Using -test.v -ginkgo.v rather than printing test headers manually
1. Updated testcase descriptions to better reflect the test.
1. Change public/private message output to be consitent throughout all
messages
1. Compare cluster endpoints using json.Marshal instead of
json.MarshalIndent
- values not explicitly passed will get current values
- moved validation checks further down to not cut off display of new values
- remove `--approve` from sample (to prevent accidental execution)
- remove non-value example to prevent confusion
@D3nn D3nn force-pushed the toggle-public-private-endpoint-access branch 2 times, most recently from 253e213 to dc11d25 Compare October 9, 2019 00:27
@D3nn D3nn merged commit 37106d3 into master Oct 9, 2019
@D3nn D3nn deleted the toggle-public-private-endpoint-access branch October 9, 2019 00:47
ota42y added a commit to ota42y/eksctl that referenced this pull request Dec 23, 2019
`update-cluster-endpoints` command changes API endpoint settings (eksctl-io#1149)

But this command doesn't read config file.
So when we use `-f` option, `eksctl` doesn't change settings.
ota42y added a commit to ota42y/eksctl that referenced this pull request Dec 23, 2019
`update-cluster-endpoints` command changes API endpoint settings (eksctl-io#1149)

But this command doesn't read config file.
So when we use `-f` option, `eksctl` doesn't change settings.
ota42y added a commit to ota42y/eksctl that referenced this pull request Dec 23, 2019
`update-cluster-endpoints` command changes API endpoint settings (eksctl-io#1149)

But this command doesn't read config file.
So when we use `-f` option, `eksctl` doesn't change settings.
ota42y added a commit to ota42y/eksctl that referenced this pull request Jan 10, 2020
`update-cluster-endpoints` command changes API endpoint settings (eksctl-io#1149)

But this command doesn't read config file.
So when we use `-f` option, `eksctl` doesn't change settings.
ota42y added a commit to ota42y/eksctl that referenced this pull request Jan 21, 2020
`update-cluster-endpoints` command changes API endpoint settings (eksctl-io#1149)

But this command doesn't read config file.
So when we use `-f` option, `eksctl` doesn't change settings.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support Private/Public Endpoints
6 participants