-
Notifications
You must be signed in to change notification settings - Fork 457
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
Puppetlabs-firewall vs Kubernetes takes 10-20+ minutes to parse and add rules #1053
Comments
Hey! Thanks for raising this. It's certainly an interesting issue you are seeing. Having worked on this module I understand what George describes in the MODULES ticket and something I think we should investigate. I can't guarantee a quick fix but I can raise the profile of this ticket within our team. I'll talk to @Aaron-Rob and get this bumped for community day. With regards to tracking bugs - here is the right place. We are currently working through some steps to direct our contributors to GitHub issues in the future. |
Great thanks Craig! |
Any update on this? We're suffering too. |
Hello! 👋 This issue has been open for a while and has had no recent activity. We've labelled it with If you are waiting on a response from us we will try and address your comments on a future Community Day. Alternatively, if it is no longer relevant to you please close the issue with a comment. |
Was this rolled out? I don't see the change in https://forge.puppet.com/modules/puppetlabs/firewall/changelog , which as pf today goes up to v4.0.0. |
To anyone who is interested in this issue, as part of our investigation into this, the team has decided that a major rework of the module is needed. |
For the record: I had originally created anissue at https://tickets.puppetlabs.com/browse/MODULES-10983 , but that issue never gained traction. So instead, I created an issue here on GitHub. |
dirty hack we've been using for a year -- just make the module skip rules in Kubernetes chains: change this regex:
to this (adjust as needed, we're using calico, kube-proxy and cilium, so we're ignoring their chains):
it only ignores rules in these chains, but doesn't mess with jumps to them or any other rules they might be mentioned it |
@breca Ignore doesn't stop this module from parsing whole iptables output every time when checking/adding/removing rules |
We're starting to run into this too fully managing system firewalls, and the k8s manifests easily take 5-10m depending on the system. I'm was curious if there is any hope of an
We're a little behind on the latest 7.x update, so I'm going to try and fork this for our 6.x version and try it out in the meantime... |
This small change makes a huge difference in compilation and catalog times btw
Would just be nice if it was configurable as one of the options. I may try and tear this apart some more and see if I can come up with something unless someone more familiar with it has the time. |
Describe the Bug
I'm hoping to get some attention for the bug described at https://tickets.puppetlabs.com/browse/MODULES-10983 . I've been running into it for a couple years. Another person, George Campbell, wrote the bug report MODULES-10983 a year ago, but there hasn't any movement.
In my case, I use Puppet to manage about 150 custom rules (Such as "Allow SSH from the management server to this node" or "Allow the internet to access port 443"). These nodes are part of a Kubernetes cluster. The CNI used by Kubernetes keeps it's routing rules in IPtables-- there are thousands of rules on every node.
Here's the problem:
Let's say that I have a new node, or that I delete all of the rules on my node and run
puppet agent --test
to re-add them. Because of the behavior seen in MODULES-10983, Puppet can take upwards of 30 minutes to write all of the rules.It would be great to find a way to fix that.
Is https://tickets.puppetlabs.com/browse/MODULES-10983 a valid place to file bugs or should we file them here instead? If the former, can someone take a look at https://tickets.puppetlabs.com/browse/MODULES-10983?
The text was updated successfully, but these errors were encountered: