The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com

Feature #10166

Clean rules not defined by module except on CHAIN

Added by Pablo Iranzo Gómez almost 3 years ago. Updated over 1 year ago.

Status:ClosedStart date:10/19/2011
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:firewallSpent time:-
Target version:-
Keywords: Branch:

We've Moved!

Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com

This issue is currently not available for export. If you are experiencing the issue described below, please file a new ticket in JIRA. Once a new ticket has been created, please add a link to it that points back to this Redmine ticket.


Description

Everything from INPUT or FORWARD is sent to RH-Firewall rule, when we input all the rules required by system services.

On INPUT we add extra temporary rules to apply that we don’t want to clean if they are defined (as the temporary process that included them would take care for removal).

We would like to aply the

 resources { 'firewall':
   purge => false,
 }

But only on one CHAIN or to ALL BUT one Chain.

History

#1 Updated by Ken Barber over 2 years ago

  • Description updated (diff)
  • Status changed from Unreviewed to Accepted

#2 Updated by Steve Traylen about 2 years ago

Here is the openstack nova use case for this, nova creates jumps in INPUT, OUTPUT, .. which puppet could replicate to stop them being trashed by a purge.

Chain INPUT (policy ACCEPT)
target prot opt source destination 
nova-compute-INPUT all – 0.0.0.0/0 0.0.0.0/0

Chain FORWARD (policy ACCEPT)
target prot opt source destination 
nova-filter-top all – 0.0.0.0/0 0.0.0.0/0 
nova-compute-FORWARD all – 0.0.0.0/0 0.0.0.0/0

Chain OUTPUT (policy ACCEPT)
target prot opt source destination 
nova-filter-top all – 0.0.0.0/0 0.0.0.0/0 
nova-compute-OUTPUT all – 0.0.0.0/0 0.0.0.0/0

and then nova manages things in these extra chains very dynamically, e.g as VMs are created and deleted. reference.

Request #12916 mentions ‘unmanaged_chains’ are you thinking this could be an attribute to the firewall chain.

I think this is conceptually very similar to the purge attribute on the file type for a directory? so how about

firewallchain {'INPUT_LOCAL:filter:IPv4':
     ensure => present,
     purge => true    # or false for puppet to leave the chain untouched.
}

If this firewallchain purge was default false then the global

resources { 'firewall':
   purge => false,
}

could still delete everything but now the individual chains could be tuned, the following would probably have to be possible.

firewallchain {'INPUT:filter:IPv4':
     ensure => present,
     purge => true    # or false for puppet to leave the chain untouched.
}

so the built chains themselves could be tuned for purge or not.

#3 Updated by Ken Barber about 2 years ago

So I’ve done some testing, and I think this is entirely possible – but it introduces something new and scary that no providers I know of do yet, and thats catalog lookup.

I managed to get the values of properties from the firewall chain, inside the Puppet::Provider::Firewall#delete method:

def delete
  catalog = self.resource.catalog
  chain_resource = catalog.resource("Firewallchain[mychain]")
  chain_properties = chain_resource.properties
  chain_properties.each do |p|
    notice("  #{p.name} #{p.value}")
  end

  ... and the rest ...
end

So as you can see, this is entirely possible to do. In my mind, I would imagine a lookup to the firewallchain resource that the rule applies to, then skipping the delete if that firewallchain resource has purged => false or some such.

So technically possible yes – and a very interesting concept indeed :–).

#4 Updated by Anastasis Andronidis almost 2 years ago

I made an effort to add this feature.

https://github.com/puppetlabs/puppetlabs-firewall/pull/93

#5 Updated by Ken Barber over 1 year ago

  • Status changed from Accepted to Closed

Hiya … I’ve fall behind a bit on all this work, also the bug tracker is moving to here: https://github.com/puppetlabs/puppet-firewall/issues I’ve managed to move what I still think is relevant and merge up items that are related. Consider this a slight declaration of ‘ticket debt’. If you think you’re issue isn’t represented in the new tracker feel free to open a new one.

Apologies for any confusion :–).

Ken.

#6 Updated by Ken Barber over 1 year ago

Sorry – the new URL is actually: http://github.com/puppetlabs/puppetlabs-firewall/issues … thanks @Wolfspyre.

Also available in: Atom PDF