ansible-role-for-splunk icon indicating copy to clipboard operation
ansible-role-for-splunk copied to clipboard

Feat: Add tasks to allow splunk ports through local firewall

Open zyphermonkey opened this issue 3 years ago • 6 comments
trafficstars

zyphermonkey avatar Feb 25 '22 16:02 zyphermonkey

@zyphermonkey I have wanted to do this so many times, but I never got around to it, because of the way I wanted to implement it. What I was thinking is automatic detection of the type of FW (ufw, firewalld etc.), and have them all in a single config with a conditional on the service name. Another thing that may be important, is to enable the firewall service if it is not enabled yet, if configure_firewall is set to true.

dtwersky avatar May 10 '22 15:05 dtwersky

These should really be Firewalld service files and not just firewalld one-off open ports, that way you can manage them with all the features of services including applying the rules to specific zones

arcsector avatar Jun 09 '22 03:06 arcsector

These should really be Firewalld service files and not just firewalld one-off open ports, that way you can manage them with all the features of services including applying the rules to specific zones

That's an even better idea. This PR has a few commits unrelated to FW, and @zyphermonkey seems to have abandoned the PR. You can create another PR for this, or maybe actually create a splunk firewalld services file for splunk, something like

<?xml version="1.0" encoding="utf-8"?>
<service>
  <short>Splunk Indexer</short>
  <description>Splunk Indexer ports.</description>
  <port protocol="tcp" port="8088"/>
  <port protocol="tcp" port="9997"/>
</service>

We can maybe have another general splunk full install that will include the other ports like 8089 and 8000 etc.

dtwersky avatar Jun 27 '22 13:06 dtwersky

It almost would be easier to have services be on a per-port basis - 1 service for mgmt, 1 service for web, etc... so that they can be disabled as one-offs if necessary.

This would also be fairly elegant with templating, whereas just using the ports doesn't allow dynamic configuration of service attributes at the per-port level.

arcsector avatar Aug 18 '22 21:08 arcsector

One of my gripes with the service method is that for some reason the support for services OOTB with the firewalld ansible task is slim: https://docs.ansible.com/ansible/latest/collections/ansible/posix/firewalld_module.html Firewalld supports configuring these services via the CLI, but for some reason ansible does not... Really sad state of affairs there: https://firewalld.org/documentation/howto/add-a-service.html

TODO

  • [ ] Defaults set which firewall software to use
  • [ ] Single firewall task file with configs depending on the type of firewall
  • [ ] Ports defined in group_vars
  • [ ] Firewalld creates services (via CLI or files)

arcsector avatar Aug 18 '22 21:08 arcsector

It almost would be easier to have services be on a per-port basis - 1 service for mgmt, 1 service for web, etc... so that they can be disabled as one-offs if necessary.

That's also an approach, but I don't see many cases where someone would need to disable a single port within a service just for a one-off.

Firewalld supports configuring these services via the CLI, but for some reason ansible does not... Really sad state of affairs there: https://firewalld.org/documentation/howto/add-a-service.html

I know about this, but I try to avoid having commands in a task, hence putting it in a service file.

I would maybe suggest to have in default a single boolean like configure_firewall, and set in vars/RedHat.yml the service name and other variables that may differ from distro to distro, and then include_vars with the ansible_os_family in there?

In general I don't like it when the tasks are huge and have many conditionals, I would rather use ansible facts to determine the appropriate task to run.

The way it is currently laid out, the tasks are way too large and complex with many conditionals that makes it very difficult to test every scenario, and I would rather have them use much more vars, instead of many checks. One example is the whole init.d and systemd for boot-start, which can be accomplished by just using ansible_service_mgr, which may be easier on the eyes. But as the saying goes, There are many ways to skin a cat.

dtwersky avatar Aug 19 '22 16:08 dtwersky

@dtwersky I think this can be closed with the merging of https://github.com/splunk/ansible-role-for-splunk/commit/e6d5ab3286748a7c922b0398b025761dd4c4d13a

arcsector avatar Dec 08 '22 22:12 arcsector