managing firewall rules in an auto-scale world

[Jason Price]

Problem statement:

I have a Database server, and I have an arbitrary number of clients.  I wish to collect the client IP addresses, and build out a set of firewall rules on the DB server to allow the client IPs to connect.

Bonus points if something can be purged out if it hasn't called home to puppet in 48 hours (or something similar)

(technically, I need to do it both directions, since the DB is Cassandra, and the number of nodes can grow there too, and the clients need to be able to have firewall rules for each of those, but one problem at a time)

Does puppet offer a canonical solution for this problem?

In searching around, using Exported Resources with puppetdb seems like a good start, but there are numerous challenges with this approach: mostly in leveraging those IP addresses in an ERB (to drive the firewall rules). 

Other searching lead to the ConCat module, but that seems to only work within the context of a single client and doesn't seem to be queryable by other clients.

Thanks for any insights;

Jason

[Jonathan Gazeley]

I have done exactly this with a MariaDB cluster. Each client that needs to access the database includes a class called mariadb::client which includes this snippet:

  # Auto-add a firewall rule in the MySQL and MariaDB server just for us
  @@firewall { "100-mariadb-${::fqdn}":
    proto  => 'tcp',
    dport  => '3306',
    tag    => 'mariadb',
    source => $::ipaddress,
    action => 'accept',
  }

And then the MariaDB server realises all of those resources in its server class:

  # MariaDB firewall rules for clients
  Firewall <<| tag == 'mariadb' |>>

It works nicely, but the only flaw is that when you build a new system, it is not immediately able to use the database, and you have to wait until after the database server has also checked in with Puppet.

Cheers,
Jonathan

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAChvjRC-t90oYDZJyFztkRX2J9E3riC-Ns2%3DQjJuNucfV%2BDEtg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Jason Price]

Thank you. That looks interesting, but two questions:

1) When you state: "Firewall <<| tag == 'mariadb' |>>" does that leverage the puppetforge firewall module from puppetlabs? ( https://docs.puppetlabs.com/puppet/latest/reference/subsystem_catalog_compilation.html ) or something else?

2) How does this handle a client instance going away?

-Jason

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/54C608BA.9070300%40bristol.ac.uk.

[Jonathan Gazeley]

Comments inline...

On 26/01/15 15:11, Jason Price wrote:

Thank you. That looks interesting, but two questions:

1) When you state: "Firewall <<| tag == 'mariadb' |>>" does that leverage the puppetforge firewall module from puppetlabs? ( https://docs.puppetlabs.com/puppet/latest/reference/subsystem_catalog_compilation.html ) or something else?

Yes, this uses a firewall resource from the puppetlabs/firewall module.

2) How does this handle a client instance going away?

Every server that has its firewall managed by this module will normally be set up with the 'purge' option. This means that any firewall rule not in the catalogue will be removed from the firewall config.

https://forge.puppetlabs.com/puppetlabs/firewall#beginning-with-firewall

How soon the firewall rule will actually disappear depends on the deactivation timeout for exported resources in PuppetDB, and whether you properly decommission nodes when you shut them down. I think by default if a node is destroyed, its exported resources are deactivated after 30 days, after which time your server will remove the firewall rule next time it checks in. You can speed up the process by issuing 'puppet node deactivate xyz.example.com' on your puppetmaster.

If your database client checks in and doesn't declare the exported resource (i.e. if you edit the manifest), it will disappear from the database server on the next run anyway.

Our experience is that the system works absolutely fine in our site of about 80 nodes, provided we remember to issue 'puppet node deactivate' when we kill off an old server.

Cheers,
Jonathan

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAChvjRDZc0FOZccAqacD%3D9-kPNwJsAj2A_aCjBiZZZXc3a8c8Q%40mail.gmail.com.