[FEED] Issue with default `checkmk_agent_server_ips` variable behavior

[gabrielgbs97]

ansible.general 5.7.0

Problematic Scenario

checkmk_agent_server is FQDN. No firewall related vars are overwritten.

Actual variables:

checkmk_agent_server = "my-checkmk-server.internal"
checkmk_agent_server_ips = [] # i.e. len == 0 # default
checkmk_agent_configure_firewall: 'true' # default

Experienced results:

No firewalld rule is applied, so agent-installed hosts remain unmonitorable if firewalld is active.

Expected results

We expect to obtain a local firewalld rule equivalent of performing following command on monitored host:

sudo firewall-cmd --permanent --add-port=6556/tcp
sudo firewall-cmd --reload

No rich rules would be needed.

Successful scenario(s)

checkmk_agent_server is an IP, or checkmk_agent_server_ips is populated with at least one IP.

This way a rich rule is applied.

Other notes

Tested with RHEL 9 agents, no Debian derivates were tested.

There is a problem with new checkmk_agent_server_ips variable behavior. If i do NOT want to set these IPs, like default behavior with defaults vars, firewall rule is not honored. Expected default behavior would be:

Let's say we have default vars like this:

checkmk_agent_server_ips = [] # i.e. len == 0
checkmk_agent_configure_firewall: 'true'

We expect to obtain a firewall rule on port of checkmk agent (6556) after role implementation.

BUT, with these conditions no firewall rule is performed because checkmk_agent_server_ips is not defined or empty ('[]'). Still, no rich rule is needed, a simple port opening is ok if no checkmk_agent_server_ips are applied.

If checkmk_agent_server_ips is populated with checkmk server IP or others (len > 1) rich rule may apply. Follow current behaviour.

I experienced this with RHEL derivates, Debian systems were not tested.

Originally posted by @gabrielgbs97 in #593

[robin-checkmk]

Hi @gabrielgbs97 and thanks for bringing this up!

I understand the issue you are facing, and I appreciate, that you would like to see the functionality in the collection.
However, I have one main concern at this point: I do not want the role to become a firewall management.
The existing feature was added back then with limited scope and even then did we discuss, how much we would want to dive into firewall management with our role. Especially, as it can (and probably will) collide with dedicated firewall management.
Of course, one can disable the feature in the role, but switching perspective: How far should we take it here?
Eventually we would need to look at IPv4 and IPv6, strict rules and rather open rules, probably more things we are not even considering yet, and we need to decide on sensible defaults and make it useable for all users.

I am open for discussion and looking forward to your thoughts on this.

[gabrielgbs97]

I agree with you, advanced firewall management may be out of scope. I would manage only the simplest and most common case: open checkmk agent tcp port. No rich rules, no IP-based, etc. This makes it much simpler. I think these high-security firewall rules have to be tailored to every environment, folks with narrow security requirements will be happy to add their custom firewall management task before executing this role.
Now it is not working as average user would expect and only handles a specific case: folks who add IP-based info get firewall mgmt by the role. I came from an older collection version, before checkmk_agent_server_ips was introduced and I think agent role port opening worked as expected.

I would not describe this as a feature, but as a bug. If this is a no-fix I would improve docs wording, specifying checkmk_agent_server (ip) or checkmk_agent_server_ips is needed to achieve firewall management by the role itself.

[robin-checkmk]

I am positive, that the IP-reliance was always there, but we are on the same page feature-wise.
I will prepare a PR and mention you on it for review.
We have to consider though, whether this is a breaking change to the collection, as users might end up left-over rules, which would require manual cleanup.

[gabrielgbs97]

Treating this case with a simple port rule application would be ok, without affecting IP-based behavior:

checkmk_agent_server = "my-checkmk-server.internal"
checkmk_agent_server_ips = [] # i.e. len == 0 # default
checkmk_agent_configure_firewall: 'true' # default

If a breaking change is expected (i.e. remove checkmk_agent_server_ips) it can be deprecated and warn its use during some minor releases.

[robin-checkmk]

Do you know whether roles can print deprecation messages as well?
But anyways, if we do a breaking release and add the release notes, users would be aware and could stick to the old version if necessary. So no problem there, other than making sure the release notes are on par.

I just started work on #755. Feel free to comment over there, otherwise I will ping you, once I feel it is ready for testing.

[rrinco]

Hi guys, I love the feature of rich rules and have my environments using role version 5.8.0 and checkmk_agent_server_ips set with all my checkmk servers IP, and current PR would just remove it! Why not instead of removing it just create a conditional for the cases where checkmk_agent_server_ips is empty and people still want "a generic rule for all" to just create the "open for all" instead of removing the current approach that for me works very well!

[robin-checkmk]

@rrinco I see your point and obviously the current state is convenient for you. However, back when the feature was introduced, we did not really consider, if it makes sense as part of the collection. And when you think about it, managing a firewall is well beyond the scope of this collection and/or role(s). There are plenty of dedicated roles out there, that manage firewalls.
Hence, the removal of the current feature set is already pretty much decided.
It is not just a question of principle, but actually tangible workload on our end, as you can see from this very issue.

[gabrielgbs97]

@rrinco You might write this rule yourself, as the logic is not overly complex, a security-tight scenario is only effective with tailored configurations. Also, different distros have different firewall management tooling (e.g., ufw, firewalld) and different backends (e.g., iptables, nftables). Which makes it more difficult to maintain and secure compatibility between major Linux vendors.