On Thu, Jul 12, 2018 at 8:17 PM, Lars Kellogg-Stedman <l...@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: '172.16.0.0/22' > proto: 'tcp' > dport: 22 > '003 allow ssh from bastion host': > source: '192.168.1.10' > 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. Thanks, -Alex > [1] > https://review.openstack.org/#/q/topic:feature/firewall%20(status:open%20OR%20status:merged) > > -- > Lars Kellogg-Stedman <l...@redhat.com> | larsks @ {irc,twitter,github} > http://blog.oddbit.com/ | > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev