-
Notifications
You must be signed in to change notification settings - Fork 40k
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
Additional subnet configuration options for AWS ELB #97431
Additional subnet configuration options for AWS ELB #97431
Conversation
@kishorj: This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the The Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Hi @kishorj. Thanks for your PR. I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/ok-to-test |
/label tide/merge-method-squash |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do we want to support this for ELB as well?
have we tested the annotation works with kops cluster?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/ok-to-test
/lgtm
I'm fine with this PR, given it improves security and avoids insecure configurations. Left a few comments. |
* support subnets without cluster tag for auto-discovery * add support for manual subnet configuration via service annotation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor question, lgtm otherwise
/approve Will leave lgtm for @nckturner or @M00nF1sh |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: andrewsykim, kishorj, M00nF1sh 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 |
/lgtm |
/retest |
1 similar comment
/retest |
/retest Review the full test history for this PR. Silence the bot with an |
3 similar comments
/retest Review the full test history for this PR. Silence the bot with an |
/retest Review the full test history for this PR. Silence the bot with an |
/retest Review the full test history for this PR. Silence the bot with an |
…31-upstream-release-1.19 Automated cherry pick of #97431: additional subnet configuration for AWS ELB
…31-upstream-release-1.20 Automated cherry pick of #97431: additional subnet configuration for AWS ELB
In Kubernetes v1.21, tagging subnets is not required to create load balancers. Keights will still support tagging them. See kubernetes/kubernetes#97431.
In Kubernetes v1.21, tagging subnets is not required to create load balancers. Keights will still support tagging them. See kubernetes/kubernetes#97431.
This is a breaking change for users who do have untagged subnets, don't want the cloud provider to use those untagged subnets, and upgrade to a version of Kubernetes with this change. Should this be behind a feature gate? |
What type of PR is this?
/kind bug
What this PR does / why we need it:
This fix fulfills the security requirements of choosing specific set of subnets per load balancer on the same cluster.
We need this PR to support the following use-cases-
Prior to this change, the AWS cloudprovider would auto discover subnets only with the cluster tags when provisioning NLB/CLB for service resources. We want to modify this behavior to include the subnets without any cluster tags, in addition to the ones previously matched by auto-discovery. After the changes, the auto-discovery will consider all subnets except the ones tagged explicitly for other cluster. If there are multiple subnets per AZ, the ties are broken in the following order
kubernetes.io/role/elb
for public andkubernetes.io/role/internal-elb
for private accesskubernetes.io/cluster/<Cluster Name>
This PR also introduces an additional annotation to manually configure the subnets.
The default behavior is to auto-discover the subnets. The annotation is a comma separated list of subnet IDs or the Name tag of the subnets. The subnets specified on this annotation must exist on the same VPC and must be from different AZs.
For NLB, due to current limitations, subnet configuration is applied during load balancer creation only.
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Verified the following on a kops cluster -
Does this PR introduce a user-facing change?:
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.: