puppetlabs-firewall rspec

[brian mancuso]

Hey guys,

My group has been working on deploying puppet to existing servers and newer servers. During this time practices have naturally changed and we're trying to write tests to ensure that when we migrate from one way of writing firewall rules to another, we don't miss any. So here's some background and an example of what we're trying to do.

Old rules:

 

 firewall { '018 accept TCP-1521 from 10.96.0.0/24':
    source => '10.96.0.0/24',
    dport  => [1521],
    state  => 'NEW',
    proto  => 'tcp',
    action => 'accept',
  }
  firewall { '018 accept TCP-1521 from 10.32.0.0/11':
    source => '10.32.0.0/11',
    dport  => [1521],
    state  => 'NEW',
    proto  => 'tcp',
    action => 'accept',
  }
  firewall { '018 accept TCP-1521 from 10.64.0.0/25':
    source => '10.64.0.0/25',
    dport  => [1521],
    state  => 'NEW',
    proto  => 'tcp',
    action => 'accept',
  }

To replace repetitive stuff like this amongst the classes, we have the following method:

define profiles::base::firewall_rule ($order = '030',
  $dport  = undef,
  $port   = undef,
  $proto  = 'tcp',
  $chain  = 'INPUT',
  $action = 'accept',
  $state  = undef,
)
{
  if ($dport) {
    if ($state) {
      firewall { "${order} ${action} ${dport} traffic from ${name}":
        source => $name,
        dport  => $dport,
        proto  => $proto,
        action => $action,
        chain  => $chain,
        state  => $state,
      }
    } else {
      firewall { "${order} ${action} ${dport} traffic from ${name}":
        source => $name,
        dport  => $dport,
        proto  => $proto,
        action => $action,
        chain  => $chain,
      }
    }
  } elsif ($port) {
    if ($state) {
      firewall { "${order} ${action} ${port} traffic from ${name}":
        source => $name,
        port   => $port,
        proto  => $proto,
        action => $action,
        chain  => $chain,
      }
    } else {
      firewall { "${order} ${action} ${port} traffic from ${name}":
        source => $name,
        port   => $port,
        proto  => $proto,
        action => $action,
        chain  => $chain,
        state  => $state,
      }
    }
  }
}

So now in the original class we can just have this:

  profiles::base::firewall_rule{ $db_access:
    dport => [1521],
    state => 'NEW',
  }

With the hiera file for the node:

profiles::banner::database::samplenode::db_access:
  - 10.96.0.0/24
  - 10.32.0.0/11
  - 10.64.0.0/25

Anyway, with the background information, we need to verify (preferably with rspec) that the node has a firewall rule given a certain port/protocol/state/etc. The rspec tests examples we've found and the original tests we had are all based on the firewall name. Sure we could change the new system to try and match the old names, but that kind of testing doesn't seem as effective since the name itself could be anything. We want to test the firewall rule's parameters.

Does anyone have an example of how we could do this? 

This is a snippet of what we have, but like I said, it tests via name, which is not what we want. This only tests that the new rule exists. We can't use it against both the new rules and the old rules. We want to have complete coverage on the old rules, then migrate to the new rules and verify that the new rules meet the tests.

require 'spec_helper'
describe "profiles::samplenode" do
  on_supported_os.each do |os, facts|
    context "on #{os}" do
      let(:facts) do
        facts.merge({
          :hostname => 'samplenode',
          :apptier  => 'production',
          :clientcert => 'samplenode.example.com',
        })
      end
      it { should create_firewall("030 accept 1521 traffic from 10.96.0.0/24") }
      it { should create_firewall("030 accept 1521 traffic from 10.32.0.0/11") }
      it { should create_firewall("030 accept 1521 traffic from 10.64.0.0/25") }
    end
  end
end

[Trevor Vaughan]

Hi Brian,

You can get ahold of the catalog directly by using the 'catalogue' object.

See the following for an example:

https://github.com/simp/pupmod-simp-auditd/blob/master/spec/classes/config/audit_profiles/simp_spec.rb#L85

Thanks,

Trevor

--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/2d1c3d33-4586-4f2d-bb53-265d45305058%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Trevor Vaughan
Vice President, Onyx Point, Inc

(410) 541-6699 x788

-- This account not approved for unencrypted proprietary information --

[brian mancuso]

Thanks Trevor! That was exactly the kind of thing we were looking for.

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/2d1c3d33-4586-4f2d-bb53-265d45305058%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.