I have some questions regarding Suricata’s multi-tenancy configuration management:
When a tenant’s configuration is modified, does Suricata require a complete service restart to load the new configuration?
If a service restart is required, how does this affect traffic analysis for other tenants? Are there any ways to avoid impacting other tenants during configuration changes?
Specifically, for tenant-specific configurations, which changes require a full service restart versus just a configuration reload:
Modifying classification-file
Changing reference-config-file
Updating address-groups variables
Other tenant-specific parameters
I’m trying to understand the best practices for managing tenant configurations while minimizing service disruption in a production environment.
The basic tenet of multi-tenancy (pun intended :-)) is to provide different rules, reference and classification config files, and rule variables for each tenant.
suricatasc supports reloading individual tenants when the rules, config files, and/or rule variables change.
Thank you for your response. As Jeff Lucovsky mentioned, multi-tenancy is what we’re referring to. Additionally, I have also practiced the relatively lossless rule reloading that you described.
I understand after reading the post again, also interested in this topic did not know this was even possible.
From my understanding having a quick view at the Multi-Tenancy documentantion is that every VLAN can have its own ruleset, would be something to test for me in the future.
@ aaaaaaarror I was a little bit too fast when not fully awake
I understand after reading the post again, also interested in this topic did not know this was even possible.
From my understanding having a quick view at the Multi-Tenancy documentation is that every VLAN or device (IPS not supported here, device looks like a network interface in the example) can have its own ruleset, would be something to test for me in the future.