Version information
This version is compatible with:
- Puppet Enterprise 2017.2.x, 2017.1.x, 2016.5.x, 2016.4.x
- Puppet >= 4.1.0 < 5.0.0
- ,
Start using this module
Add this module to your Puppetfile:
mod 'zleslie-pf', '1.7.0'
Learn more about managing modules with a PuppetfileDocumentation
Puppet-pf
A Puppet module for managing PF rules on BSD. This module is pretty basic.
It only wraps the logic necessary to deploy a pf.conf
file and the necessary
parsing and loading of the rules deployed.
Usage
To use the PF module, you only need pass in a template.
For Puppet 3.x support, use the module version 0.1.x.
With Hiera
If you are using Hiera, the following items will take care of you.
include pf
Then set pf::template
to a value that you would pass to the template()
function, as you would on a file
resource. For example:
pf::template: 'site/mynodepf.conf.erb'
Then for each node that uses PF, simply build a template for each node where necessary.
Fun with templates
Templates are cool for many reasons. One of them is the fact that you can include templates from inside templates. As an example, you might keep pf options, macros, and tables each in a file that is common to all your hosts. Then only use differences where needed. For example, a firewall node template might look like the following.
<%= scope.function_template(['profile/network/firewall/pf/_options.erb']) %>
<%= scope.function_template(['profile/network/firewall/pf/_macros.erb']) %>
<%= scope.function_template(['profile/network/firewall/pf/_tables.erb']) %>
<%= scope.function_template(['profile/network/firewall/pf/_nat.erb']) %>
<%= scope.function_template(['profile/network/firewall/pf/_filter.erb']) %>
<%= scope.function_template(['profile/network/firewall/pf/_filter/_siteA_ipsec.erb']) %>
# Allow sasyncd in from peer
pass in on $ext_if proto tcp from $siteA_secondary_ext to $siteA_primary_ext port {isakmp}
This allows you to put the bulk of the code in common templates that can be distributed to multiple systems, which helps reduce the number of files that need modifying to make change to a potential large number of systems. This is environment dependent.
Dynamic tables with PuppetDB
Tables in PF hold groups of addresses for speedy lookup and simplified rule
sets. This combined with PuppetDB queries makes for some interesting code.
You can use the pf::table
defined type to specify a list of classes, who's IP
addresses should be in a table.
pf::table {'ldap_servers':
class_list => ['profile::ldap::servers'],
}
The above code will all a PF table entry to /etc/pf.d/tables.pf
that you can
simply include in your main template with a simple include "/etc/pf.d/tables.pf
. Now you can use the <ldap_servers>
table in your rule
set like you would with any other PF table.
pass in proto { tcp udp } from <local_nets> to <auth_servers> port 88
pass in proto tcp from <local_nets> to <auth_servers> port { 636 749 }
This table is populated by querying PuppetDB for all nodes who have the class
profile::ldap::servers
in their catalog, and returning returning the values
for ipaddress
and ipaddress6
from those nodes, and adding them to the
table. This doesn't work for all scenarios, for example, if the IP you want
to add to a table is not in either of those facts.
More flexible table data using a common class
In the case where a node's ipaddress
or ipaddress6
is not the desired value
to enter a table, this data can be referenced from another class. Consider the following resources
class profile::network::host ($default_address) {}
pf::table {'ldap_servers':
class_list => ['profile::ldap::servers'],
common_class => 'profile::network::host',
common_class_param => 'default_address'
}
In this case, the profile::network::host::default_address
can be set in
hiera, on a specific node. This will cause the pf::table
resource to first
look for nodes that have included the profile::ldap::servers
class, then from
each of those nodes, look up the value of default_address
on the
profile::network::host
class. This allows the default_address
to be
overridden with something more creative, like an array of facts like
[networking.lo1.ip6, networking.lo1.ip4]
or some such. This comes in quite
handy when nodes in the environment wish to be referenced by a fact that is not
the ipaddress
or ipaddress6
fact.
Dependencies
- puppetlabs/concat (>=2.0.0)
- puppetlabs/stdlib (>= 4.0.0)
- dalen/puppetdbquery (>= 1.3.0)