c525c64f6a
The tripleo firewall module has fundamentally three pieces: 1) firewall::pre (allows existing connections/ssh/icmp) 2) firewall::rule (allows services traffic) 3) firewall::post (drops all traffic) One of the assumptions coded in the module is the following line: Service<||> -> Class['tripleo::firewall::post'] Which has been added so that (see also bug LP#1643575): """ use ordering to make sure we start all Services in catalog before post rules. It ensure that we don't drop all traffic before starting the services, which could lead to services errors (e.g. trying to reach database or amqp) """ The problem is that there is nothing specifying that the firewall rules created by tripleo services need to be implemented between the pre and post classes. So the following can happen: Jul 10 05:04:13 overcloud-controller-1 systemd: Started OpenSSH server daemon. Jul 10 05:04:13 overcloud-controller-1 puppet-user[32418]: (/Stage[main]/Ssh::Server::Service/Service[sshd]) Triggered 'refresh' from 2 events Jul 10 05:04:13 overcloud-controller-1 puppet-user[32418]: (/Stage[main]/Tripleo::Firewall::Pre/Tripleo::Firewall::Rule[000 accept related established rules]/Firewall[000 accept related established rules ipv4]/ensure) created ... Jul 10 05:04:13 overcloud-controller-1 puppet-user[32418]: (/Stage[main]/Tripleo::Firewall::Post/Tripleo::Firewall::Rule[998 log all]/Firewall[998 log all ipv4]/ensure) created ... Jul 10 05:04:14 overcloud-controller-1 puppet-user[32418]: (/Stage[main]/Tripleo::Firewall/Tripleo::Firewall::Service_rules[cinder_api]/Tripleo::Firewall::Rule[119 cinder]/Firewall[119 cinder ipv4]/ensure) created This means that we can actually open the traffic for our services *after* said traffic has been completely blocked. In order to fix this we tag the pre/post rules with a different tag and add resource collectors to actually enforce proper ordering. We now get: ... Jul 11 08:54:43 overcloud-controller-0 puppet-user[32554]: (/Stage[main]/Tripleo::Firewall::Pre/Tripleo::Firewall::Rule[000 accept related established rules]/Firewall[000 accept related established rules ipv4]/ensure) created ... Jul 11 08:54:43 overcloud-controller-0 puppet-user[32554]: (/Stage[main]/Tripleo::Firewall/Tripleo::Firewall::Service_rules[cinder_api]/Tripleo::Firewall::Rule[119 cinder]/Firewall[119 cinder ipv4]/ensure) created ... Jul 11 08:54:52 overcloud-controller-0 puppet-user[32554]: (/Stage[main]/Tripleo::Firewall::Post/Tripleo::Firewall::Rule[998 log all]/Firewall[998 log all ipv4]/ensure) created Tested this by doing 20 deploys of 1ctrl+1cmp and then scaling up the overcloud to 3ctrl+2cmp. The reason this change, besides being semantically correct, is needed for scaling up the controller role is the following: 1) When we detect a scaleup situation, we call 'pcs cluster node add <newnode>' from the bootstrap node 2) It can happen that 1) succeeds because the node still had no iptables at all, so pcs communication succeeds. So at this point the cluster has added a new node and all is well 3) Now we apply the pre and post rules and all traffic is blocked. And slowly we start adding rules to let services be accessible over the network. 4) pacemaker is unable to talk to other nodes and assumes a network split. Eventually it will start fencing node to guarantee the state of the remote nodes and so the deploy will fail. With this change if the 'pcs cluster node add' call succeeds we are guaranteed to not interrupt network traffic afterwards. Change-Id: I01e681a6305e2708bf364781a2032265b146d065 Closes-Bug: #1781147
182 lines
6.3 KiB
Puppet
182 lines
6.3 KiB
Puppet
#
|
|
# Copyright (C) 2015 eNovance SAS <licensing@enovance.com>
|
|
#
|
|
# Licensed under the Apache License, Version 2.0 (the "License"); you may
|
|
# not use this file except in compliance with the License. You may obtain
|
|
# a copy of the License at
|
|
#
|
|
# http://www.apache.org/licenses/LICENSE-2.0
|
|
#
|
|
# Unless required by applicable law or agreed to in writing, software
|
|
# distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
|
|
# WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
|
|
# License for the specific language governing permissions and limitations
|
|
# under the License.
|
|
#
|
|
# == Class: tripleo
|
|
#
|
|
# Configure the TripleO firewall
|
|
#
|
|
# === Parameters:
|
|
#
|
|
# [*manage_firewall*]
|
|
# (optional) Completely enable or disable firewall settings
|
|
# (false means disabled, and true means enabled)
|
|
# Defaults to false
|
|
#
|
|
# [*firewall_chains*]
|
|
# (optional) Manage firewall chains
|
|
# Default to {}
|
|
#
|
|
# [*firewall_rules*]
|
|
# (optional) Allow to add custom firewall rules
|
|
# Should be an hash.
|
|
# Default to {}
|
|
#
|
|
# [*purge_firewall_chains*]
|
|
# (optional) Boolean, purge all firewalli rules in a given chain
|
|
# Defaults to false
|
|
#
|
|
# [*purge_firewall_rules*]
|
|
# (optional) Boolean, purge all firewall resources
|
|
# Defaults to false
|
|
#
|
|
# [*firewall_pre_extras*]
|
|
# (optional) Allow to add custom parameters to firewall rules (pre stage)
|
|
# Should be an hash.
|
|
# Default to {}
|
|
#
|
|
# [*firewall_post_extras*]
|
|
# (optional) Allow to add custom parameters to firewall rules (post stage)
|
|
# Should be an hash.
|
|
# Default to {}
|
|
#
|
|
class tripleo::firewall(
|
|
$manage_firewall = false,
|
|
$firewall_chains = {},
|
|
$firewall_rules = {},
|
|
$purge_firewall_chains = false,
|
|
$purge_firewall_rules = false,
|
|
$firewall_pre_extras = {},
|
|
$firewall_post_extras = {},
|
|
) {
|
|
|
|
if $manage_firewall {
|
|
|
|
if $purge_firewall_chains {
|
|
resources { 'firewallchain':
|
|
purge => true
|
|
}
|
|
}
|
|
|
|
# Only purges IPv4 rules
|
|
if $purge_firewall_rules {
|
|
resources { 'firewall':
|
|
purge => true
|
|
}
|
|
}
|
|
|
|
# To manage the chains they must be named in specific ways
|
|
# https://github.com/puppetlabs/puppetlabs-firewall#type-firewallchain
|
|
# Example Hiera:
|
|
# tripleo::firewall::firewall_chains:
|
|
# 'FORWARD:filter:IPv4':
|
|
# ensure: present
|
|
# policy: accept
|
|
# purge: false
|
|
#
|
|
create_resources('firewallchain', $firewall_chains)
|
|
|
|
# anyone can add your own rules
|
|
# example with Hiera:
|
|
#
|
|
# tripleo::firewall::firewall_rules:
|
|
# '300 allow custom application 1':
|
|
# port: 999
|
|
# proto: udp
|
|
# action: accept
|
|
# '301 allow custom application 2':
|
|
# port: 8081
|
|
# proto: tcp
|
|
# action: accept
|
|
#
|
|
create_resources('tripleo::firewall::rule', $firewall_rules)
|
|
|
|
ensure_resource('class', 'tripleo::firewall::pre', {
|
|
'firewall_settings' => $firewall_pre_extras,
|
|
})
|
|
|
|
ensure_resource('class', 'tripleo::firewall::post', {
|
|
'firewall_settings' => $firewall_post_extras,
|
|
})
|
|
|
|
Class['tripleo::firewall::pre']
|
|
-> Firewall<|tag == 'tripleo-firewall-rule'|>
|
|
-> Class['tripleo::firewall::post']
|
|
|
|
Service<||> -> Class['tripleo::firewall::post']
|
|
|
|
# Allow composable services to load their own custom
|
|
# example with Hiera.
|
|
# NOTE(dprince): In the future when we have a better hiera
|
|
# heat hook we might refactor this to use hiera's merging
|
|
# capabilities instead. Until then rolling up the flat service
|
|
# keys and dynamically creating firewall rules for each service
|
|
# will allow us to compose and should work fine.
|
|
#
|
|
# Each service can load its rules by using this form:
|
|
#
|
|
# tripleo.<service name with underscores>.firewall_rules:
|
|
# '300 allow custom application 1':
|
|
# dport: 999
|
|
# proto: udp
|
|
# action: accept
|
|
$service_names = hiera('service_names', [])
|
|
tripleo::firewall::service_rules { $service_names: }
|
|
|
|
|
|
# puppetlabs-firewall only manages the current state of iptables
|
|
# rules and writes out the rules to a file to ensure they are
|
|
# persisted. We are specifically running the following commands after the
|
|
# iptables rules to ensure the persisted file does not contain any
|
|
# ephemeral neutron rules. Neutron assumes the iptables rules are not
|
|
# persisted so it may cause an issue if the rule is loaded on boot
|
|
# (or via iptables restart). If an operator needs to reload iptables
|
|
# for any reason, they may need to manually reload the appropriate
|
|
# neutron agent to restore these iptables rules.
|
|
# https://bugzilla.redhat.com/show_bug.cgi?id=1541528
|
|
exec { 'nonpersistent_v4_rules_cleanup':
|
|
command => '/bin/sed -i /neutron-/d /etc/sysconfig/iptables',
|
|
onlyif => '/bin/test -f /etc/sysconfig/iptables && /bin/grep -q neutron- /etc/sysconfig/iptables',
|
|
}
|
|
exec { 'nonpersistent_v6_rules_cleanup':
|
|
command => '/bin/sed -i /neutron-/d /etc/sysconfig/ip6tables',
|
|
onlyif => '/bin/test -f /etc/sysconfig/ip6tables && /bin/grep -q neutron- /etc/sysconfig/ip6tables',
|
|
}
|
|
|
|
# Do not persist ephemeral firewall rules mananged by ironic-inspector
|
|
# pxe_filter 'iptables' driver.
|
|
# https://bugs.launchpad.net/tripleo/+bug/1765700
|
|
# https://storyboard.openstack.org/#!/story/2001890
|
|
exec { 'nonpersistent_ironic_inspector_pxe_filter_v4_rules_cleanup':
|
|
command => '/bin/sed -i "/-m comment --comment.*ironic-inspector/p;/ironic-inspector/d" /etc/sysconfig/iptables',
|
|
onlyif => [
|
|
'/bin/test -f /etc/sysconfig/iptables',
|
|
'/bin/grep -v "\-m comment \--comment" /etc/sysconfig/iptables | /bin/grep -q ironic-inspector'
|
|
]
|
|
}
|
|
exec { 'nonpersistent_ironic_inspector_pxe_filter_v6_rules_cleanup':
|
|
command => '/bin/sed -i "/-m comment --comment.*ironic-inspector/p;/ironic-inspector/d" /etc/sysconfig/ip6tables',
|
|
onlyif => [
|
|
'/bin/test -f /etc/sysconfig/ip6tables',
|
|
'/bin/grep -v "\-m comment \--comment" /etc/sysconfig/ip6tables | /bin/grep -q ironic-inspector'
|
|
]
|
|
}
|
|
|
|
Firewall<| |> -> Exec['nonpersistent_v4_rules_cleanup']
|
|
Firewall<| |> -> Exec['nonpersistent_v6_rules_cleanup']
|
|
Firewall<| |> -> Exec['nonpersistent_ironic_inspector_pxe_filter_v4_rules_cleanup']
|
|
Firewall<| |> -> Exec['nonpersistent_ironic_inspector_pxe_filter_v6_rules_cleanup']
|
|
}
|
|
}
|