-
Notifications
You must be signed in to change notification settings - Fork 578
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
Allow customization of ingress rules in control plane LB security group #4304
Allow customization of ingress rules in control plane LB security group #4304
Conversation
Welcome @fiunchinho! |
Hi @fiunchinho. Thanks for your PR. I'm waiting for a kubernetes-sigs 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. |
Adding @richardcase and @alexander-demicev as we talked about this in Slack. |
/ok-to-test |
/test pull-cluster-api-provider-aws-e2e-eks |
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.
The logic itself looks okay to me. However, the API field name AdditionalIngressRules
might be confusing to users since the change is not only defining new ingress rules but also overriding already defined rules. We haven't released this API field yet, so it can still be changed to something like CustomIngressRules
. What do you think?
Also, what about the IPv6 rules below?
277eb0b
to
7fb8bd1
Compare
I've changed the logic so that when no additional rules are defined and we want to use the default rules, we either use IPv6 or IPv4 depending on whether IPv6 is enabled or not. |
7fb8bd1
to
35cc1af
Compare
I pushed a new change to rename the field from |
/retest |
/test pull-cluster-api-provider-aws-e2e-eks |
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.
Looks good to me, there is also a small piece of documentation that needs to be updated https://cluster-api-aws.sigs.k8s.io/topics/bring-your-own-aws-infrastructure.html?highlight=ingress#control-plane-load-balancer
35cc1af
to
9241ebc
Compare
/lgtm Just needs approval from a maintainer :) /assign @richardcase @Ankitasw @Skarlso |
Looks okay except for that small refactor. :) Then it should be fine. :) |
a72a71d
to
b4928b2
Compare
/retest |
Pfff... Now we have to find out if we actually created that many, or there is a problem on the account. I've seen sometimes that when there is an error it kept creating security groups when it eventually reached the limit withing a couple seconds haha. |
What should I do now? I think the only thing I can do is to re-trigger and hope for the best 😄 |
Nah, don't re-trigger. If the account has a problem we are just adding to it. So let's leave it for a little while and hope it cleans up. 🤷 |
/test pull-cluster-api-provider-aws-e2e |
All green now 😸 |
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: Skarlso 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 |
/milestone v2.2.0 |
What type of PR is this?
/kind feature
What this PR does / why we need it:
We would like to customize the ingress rules that are included in the security group created for the control plane Load Balancer. Currently, capa always adds an ingress rule to allow traffic towards the k8s api from everywhere (
0.0.0.0/0
). But we would like to have more control over this. We would like to only allow traffic coming from our VPNs.With the changes in this PR, when no additional ingress rules are defined, we add the ingress rule to allow traffic from everywhere. That way we are backwards compatible. But when additional rules are defined, these will be used instead.
Checklist:
Release note: