Description of problem: OSP-Director installs the overcloud nodes with open firewall rules. This leaves the provisioning interface (which is typically the default gateway for Overcloud nodes) vulnerable to port scans and attacks on non-ssh ports and services. We should apply a basic deny all rule, and then add rules to allow connections to certain ports. We shouldn't be accepting all traffic by default. Generally the Overcloud is accessed via the Public API, and the APIs listening on the provisioning network are just for local access from the Undercloud. We might want to limit traffic to the control plane VIP on the provisioning network to the local subnet by default. Version-Release number of selected component (if applicable): OSP 7 OSP 8 Beta 1 Actual results: The firewall is completely open. I can open up and connect remotely to arbitrary ports: [heat-admin@overcloud-controller-0 ~]$ sudo nc -l -p 44 [stack@instack ~]$ nc 192.0.2.19 44 asdf ^C [heat-admin@overcloud-controller-0 ~] asdf Expected results: The ssh port and ICMP should be open to remote connections, but the rest of the ports should probably not be open by default. This should be configurable, however, as there will be deployments where the APIs need to be accessible from local networks outside the provisioning network. Another reasonable approach (though slightly less secure) is Additional info: There is a TripleO patch that has gone through many revisions. Once it merges, it may be possible to use Heat to configure the iptables firewall for the provisioning network. This will need to be documented and sane defaults developed. https://review.openstack.org/#/c/191195
(In reply to Dan Sneddon from comment #0) Unfinished sentence under Expected Results above: Another reasonable approach (although slightly less secure) is to leave the API ports open, but apply a default DENY policy so that other unknown ports are not left open.
*** This bug has been marked as a duplicate of bug 1274196 ***