Firewall Update - Converted to the resource_api

Firewall Update - Converting to the resource_api

What has changed and what will I need to update?

While there have been significant changes to the module, when it comes to the users experiance, there are only six that I would deem backwards incompatible:

1. The provider attribute for the Firewall type, which sets whether the rule is for iptables or ip6tables, has been renamed to protocol. This is for two reasons; firstly due to the resource_api specifically forbidding the use of provider as an attribute name as it is deemed bad practice and secondly to bring it in line with its Firewallchain counterpart.
   • Of note, the attribute has also been updated to allow IPv4 or IPv6 to be passed in place of iptables or ip6tables as it is with Firewallchain, though either style is accepted as valid.
2. The action attribute has been removed as it was merely a restricted version of the jump attribute, with both of them managing the same function. Though this was reasoned as a way to enforce the use of generic parameters I found it to be needlesly complex and so jump should now be used in all situations.
3. Strict types have been declared for all attributes, the type of information that can be passed to each attribute is now validated on a higher level.
4. The port attribute has been removed as it has been deprecated for several years now and is no longer relevant.
5. Attributes that allow both arrays and negated values have now been updated.
   • For attributes that require that all passed values be negated as one, you now merely have to negate the first value within the array, rather than all of them, though negating all is still accepted.
   • For attributes that allow passed values to be negated seperately this is not the case, with each value being negated, or not negated as it were, seperately. All attributes in this situation are noted within their personal description.
6. One last change, that while not backwards incompatible, I feel shoul be mentioned is that the sport and dport attributes have now been updated to allow ranges of values to be passed with the : symbol as a seperator, as this is how they are passed into the iptables command. The original form of the seperator -, is still accepted however.

Overall, while there may be some changes that you will have to make to you manifests in order to make them compliant with the new form of the module, I have done my best in order to keep them to a minimum and feel that, for the most part, I have succeeded.

Example manifest comparison

Some example manifest changes, pulled from the tests, are show below.

• An manifest applying a hoplimit on ip6tables:

firewall { '571 - hop_limit':
  ensure    => present,
  proto     => 'tcp',
  dport     => '571',
  action    => 'accept',
  hop_limit => '5',
  provider  => 'ip6tables',
}

firewall { '571 - hop_limit':
  ensure    => present,
  proto     => 'tcp',
  dport     => '571',
  jump      => 'accept',
  hop_limit => '5',
  protocol  => 'IPv6',
}

• A manifest blocking access to a pair of ports on iptables:

firewall { '560 - negated ports':
  proto  => `tcp`,
  sport  => ['! 560-570','! 580'],
  action => `accept`,
}

firewall { '560 - negated ports':
  proto  => `tcp`,
  sport  => '! 560:570','580',
  jump   => `accept`,
}

Main improvements

In regards to how these changes will improve the modules usage, I will be honest and say that they will mainly effect the maintanence and future improvement of the module, increasing the ease with which it can be debugged and with which requested fixes and improvements can be made. While there is some functional improvement, with the module now more efficiently parsing the returned/given values, it has been largely limited by the necessity of each change in rule being applied with it’s own command.

Future improvements

While this has been a large improvement to the module there are many more that can be made for the future:

• A community suggestion was made to implement the optparse ruby module in parsing the retrieved and applied rules from their correct form to the Puppet hash values that we set in or manifests. This could help to replace the most complex part of the updated module and reduce the overall amount of code within the providers and further simplify the module as a whole.
• Many of the currently implemented attributes can be negated but do not currently allow it, this is especially true of the boolean values, the code for which will need to be updated specifically to allow this.

Closing Thoughts

Implementing the resource_api into this module is something that I have long considered a vital improvement and one that I am happy that I was able to close of myself.

I have learned alot in the process and have thouroughly enjoyed the work with my hope being that everyone who utilises or works on the module going forward is appreciative of the changes made and find the module as a whole much easier to work with.

David

• ←Previous
Next→