-
Notifications
You must be signed in to change notification settings - Fork 537
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
⚠️ ELB uses separate security group #1456
⚠️ ELB uses separate security group #1456
Conversation
Took a first stab at this in response to #1452. Interested in feedback if this is the preferred approach. Also added Path MTU Discovery. This is already done for each new ELB that the AWS cloud provider adds for services of type LoadBalancer. See: kubernetes/kubernetes#24254 |
@aaroniscode we'll need an additional new Security Group for this change, the existing LB that you are re-purposing here is meant for use by the AWS cloud-provider integration (hence the different ownership tag used). |
@detiber I noticed the comment that it was meant for use by the AWS cloud-provider integration but it didn't appear to be used. When testing the AWS cloud-provider it created new security groups for each load balancer. So I can learn, can you point to me where I missed how this is used by the AWS cloud provider? And I can look at creating a new k8s API load balancer security group. |
It was introduced in #706, there might be additional context as to why in the comments on that PR |
@detiber I updated the PR based on your feedback. I left the LB that we create for the AWS cloud-provider integration alone and created a new LB just for the K8s API Server. |
I believe all review comments have been resolved. Thanks all! Removed the Path MTU for now as it probably belongs in more than just the k8s LB security group and wanted to keep this PR focused. Will open a separate PR for Path MTU shortly. Also tested both Internet-facing and internal ELB. |
@aaroniscode what port did you test for the ELBs? |
6443 |
Ok. Think there'd be any issue with 443? |
I tested with 443 a week or so back by setting in
|
/lgtm |
/lgtm too |
Note for later: given that we're now adding a new security group for the ELB, we should probably consider changing this line https://github.com/kubernetes-sigs/cluster-api-provider-aws/pull/1456/files#diff-b0ffc0997fd2bffcad9bd812a56adccbR382 that allows everyone to access the control plane port, regardless of network. We can probably make sure that the control plane security group is allowed to talk to the hardcoded port 6443, and the new ELB security group. /approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: aaroniscode, vincepri The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
@vincepri we'll never come back to your note unless we file an issue - will you do that? |
Will do yeah |
What this PR does / why we need it:
Currently the ELB provisioned for the Kubernetes API server shares the security group with the control plane nodes. This leverages the existing LB security group that was created but never used. It also exposes the external port as set in
Clusters
'sspec.clusterNetwork.apiServerPort
Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close the issue(s) when PR gets merged):Fixes #1452