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

Make pod firewall nflog rate-limiting configurable #1078

Closed
wants to merge 1 commit into from

Conversation

bnu0
Copy link
Contributor

@bnu0 bnu0 commented May 4, 2021

For compliance reasons, it might be desired to tune the nflog rate-limits for packets that are rejected from pod firewalls. This PR makes it possible to tune the limit/burst parameters, or remove limiting entirely if you know what you are doing.

The defaults remain at burst=10, limit=10/minute as before.

@aauren
Copy link
Collaborator

aauren commented May 13, 2021

@bnu0 I definitely understand the motivation for this PR. However, I'm hesitant to add more CLI flags for kube-router for something this obscure (at least IMO).

One of the benefits to kube-router is that it is easy to understand and configure when compared to the other offerings available. So we try to police how many flags we add to the interface so as to only highlight major features and try to choose sane defaults rather than potentially overwhelming the end-user with configuration options for every knob that could be turned.

I'll likely wait and see if @murali-reddy has any opinions on whether or not to include this feature.

@aauren
Copy link
Collaborator

aauren commented May 13, 2021

Also, thanks for the stabilizing that unit test, I actually cherry-picked that commit and pushed it to master ahead of this PR so regardless of the action here, unit tests will be more stable in the future: fce90b0

If you can, please rebase your PR so that commit gets taken out.

@aauren
Copy link
Collaborator

aauren commented Mar 12, 2022

Thanks for creating this, and sorry that it has taken so long to come back around to this. However, adding 2 additional parameter flags isn't worth what this feature brings to the table.

I definitely see how it could be useful in certain situations, but given that its been posted for almost a year and no one else has chimed in, I don't think that it would be widely used.

Maybe in the future, if we create more ways of configuring kube-router, maybe expose some conf like mechanism for more advanced options or some such, then we could revisit this.

@aauren aauren closed this Mar 12, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants