[openstack-dev] [tripleo][pre] removing default ssh rule from tripleo::firewall::pre

Alex Schultz aschultz at redhat.com
Fri Jul 13 13:47:17 UTC 2018

On Thu, Jul 12, 2018 at 8:17 PM, Lars Kellogg-Stedman <lars at redhat.com> wrote:
> I've had a few operators complain about the permissive rule tripleo
> creates for ssh.  The current alternatives seems to be to either disable
> tripleo firewall management completely, or move from the default-deny
> model to a set of rules that include higher-priority blacklist rules
> for ssh traffic.
> I've just submitted a pair of reviews [1] that (a) remove the default
> "allow ssh from everywhere" rule in tripleo::firewall:pre and (b) add
> a DefaultFirewallRules parameter to the tripleo-firewall service.
> The default value for this new parameter is the same rule that was
> previously in tripleo::firewall::pre, but now it can be replaced by an
> operator as part of the deployment configuration.
> For example, a deployment can include:
>     parameter_defaults:
>       DefaultFirewallRules:
>         tripleo.tripleo_firewall.firewall_rules:
>           '003 allow ssh from internal networks':
>             source: ''
>             proto: 'tcp'
>             dport: 22
>           '003 allow ssh from bastion host':
>             source: ''
>             proto: 'tcp'
>             dport: 22

I've commented on the reviews, but for the wider audience I don't
think we should completely remove these default rules. As we've
switched to ansible (and ssh) being the deployment orchestration
mechanism, it is important that we don't allow a user to lock
themselves out of their cloud via a bad ssh rule. I think we should
update the default rule to allow access over the control plane but
there must be at least 1 rule that we're enforcing exist so the
deployment and update processes will continue to function.


> [1] https://review.openstack.org/#/q/topic:feature/firewall%20(status:open%20OR%20status:merged)
> --
> Lars Kellogg-Stedman <lars at redhat.com> | larsks @ {irc,twitter,github}
> http://blog.oddbit.com/                |
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

More information about the OpenStack-dev mailing list