Chapter 18. Security enhancements
The following sections provide some suggestions to harden the security of your overcloud.
18.1. Using secure root user access
The overcloud image automatically contains hardened security for the root user. For example, each deployed overcloud node automatically disables direct SSH access to the root user. You can still access the root user on overcloud nodes.
Procedure
-
Log in to the undercloud node as the
stackuser. -
Each overcloud node has a
heat-adminuser account. This user account contains the undercloud public SSH key, which provides SSH access without a password from the undercloud to the overcloud node. On the undercloud node, log in to the an overcloud node through SSH as theheat-adminuser. -
Switch to the
rootuser withsudo -i.
18.2. Managing the overcloud firewall
Each of the core OpenStack Platform services contains firewall rules in their respective composable service templates. This automatically creates a default set of firewall rules for each overcloud node.
The overcloud heat templates contain a set of parameters that can help with additional firewall management:
- ManageFirewall
-
Defines whether to automatically manage the firewall rules. Set this parameter to
trueto allow Puppet to automatically configure the firewall on each node. Set tofalseif you want to manually manage the firewall. The default istrue. - PurgeFirewallRules
-
Defines whether to purge the default Linux firewall rules before configuring new ones. The default is
false.
If you set the ManageFirewall parameter to true, you can create additional firewall rules on deployment. Set the tripleo::firewall::firewall_rules hieradata using a configuration hook (see Section 4.5, “Puppet: Customizing hieradata for roles”) in an environment file for your overcloud. This hieradata is a hash containing the firewall rule names and their respective parameters as keys, all of which are optional:
- port
- The port associated to the rule.
- dport
- The destination port associated to the rule.
- sport
- The source port associated to the rule.
- proto
-
The protocol associated to the rule. Defaults to
tcp. - action
-
The action policy associated to the rule. Defaults to
accept. - jump
-
The chain to jump to. If present, it overrides
action. - state
-
An Array of states associated to the rule. Defaults to
['NEW']. - source
- The source IP address associated to the rule.
- iniface
- The network interface associated to the rule.
- chain
-
The chain associated to the rule. Defaults to
INPUT. - destination
- The destination CIDR associated to the rule.
The following example demonstrates the syntax of the firewall rule format:
ExtraConfig:
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
This applies two additional firewall rules to all nodes through ExtraConfig.
Each rule name becomes the comment for the respective iptables rule. Each rule name starts with a three-digit prefix to help Puppet order all defined rules in the final iptables file. The default Red Hat OpenStack Platform rules use prefixes in the 000 to 200 range.
18.3. Changing the Simple Network Management Protocol (SNMP) strings
Director provides a default read-only SNMP configuration for your overcloud. It is advisable to change the SNMP strings to mitigate the risk of unauthorized users learning about your network devices.
When you configure the ExtraConfig interface with a string parameter, you must use the following syntax to ensure that heat and Hiera do not interpret the string as a Boolean value: '"<VALUE>"'.
Set the following hieradata using the ExtraConfig hook in an environment file for your overcloud:
SNMP traditional access control settings
- snmp::ro_community
-
IPv4 read-only SNMP community string. The default value is
public. - snmp::ro_community6
-
IPv6 read-only SNMP community string. The default value is
public. - snmp::ro_network
-
Network that is allowed to
RO querythe daemon. This value can be a string or an array. Default value is127.0.0.1. - snmp::ro_network6
-
Network that is allowed to
RO querythe daemon with IPv6. This value can be a string or an array. The default value is::1/128. - tripleo::profile::base::snmp::snmpd_config
-
Array of lines to add to the snmpd.conf file as a safety valve. The default value is
[]. See the SNMP Configuration File web page for all available options.
For example:
parameter_defaults:
ExtraConfig:
snmp::ro_community: mysecurestring
snmp::ro_community6: myv6securestringThis changes the read-only SNMP community string on all nodes.
SNMP view-based access control settings (VACM)
- snmp::com2sec
- An array of VACM com2sec mappings. Must provide SECNAME, SOURCE and COMMUNITY.
- snmp::com2sec6
- An array of VACM com2sec6 mappings. Must provide SECNAME, SOURCE and COMMUNITY.
For example:
parameter_defaults:
ExtraConfig:
snmp::com2sec: ["notConfigUser default mysecurestring"]
snmp::com2sec6: ["notConfigUser default myv6securestring"]This changes the read-only SNMP community string on all nodes.
For more information, see the snmpd.conf man page.
18.4. Changing the SSL/TLS cipher and rules for HAProxy
If you enabled SSL/TLS in the overcloud, consider hardening the SSL/TLS ciphers and rules that are used with the HAProxy configuration. By hardening the SSL/TLS ciphers, you help avoid SSL/TLS vulnerabilities, such as the POODLE vulnerability.
Create a heat template environment file called
tls-ciphers.yaml:touch ~/templates/tls-ciphers.yaml
Use the
ExtraConfighook in the environment file to apply values to thetripleo::haproxy::ssl_cipher_suiteandtripleo::haproxy::ssl_optionshieradata:parameter_defaults: ExtraConfig: tripleo::haproxy::ssl_cipher_suite: 'DHE-RSA-AES128-CCM:DHE-RSA-AES256-CCM:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-CCM:ECDHE-ECDSA-AES256-CCM:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-CHACHA20-POLY1305' tripleo::haproxy::ssl_options: 'no-sslv3 no-tls-tickets'NoteThe cipher collection is one continuous line.
Include the
tls-ciphers.yamlenvironment file with the overcloud deploy command when deploying the overcloud:openstack overcloud deploy --templates \ ... -e /home/stack/templates/tls-ciphers.yaml ...
18.5. Using the Open vSwitch firewall
You can configure security groups to use the Open vSwitch (OVS) firewall driver in Red Hat OpenStack Platform director. Use the NeutronOVSFirewallDriver parameter to specify firewall driver that you want to use:
-
iptables_hybrid- Configures the Networking service (neutron) to use the iptables/hybrid based implementation. -
openvswitch- Configures the Networking service to use the OVS firewall flow-based driver.
The openvswitch firewall driver includes higher performance and reduces the number of interfaces and bridges used to connect guests to the project network.
Multicast traffic is handled differently by the Open vSwitch (OVS) firewall driver than by the iptables firewall driver. With iptables, by default, VRRP traffic is denied, and you must enable VRRP in the security group rules for any VRRP traffic to reach an endpoint. With OVS, all ports share the same OpenFlow context, and multicast traffic cannot be processed individually per port. Because security groups do not apply to all ports (for example, the ports on a router), OVS uses the NORMAL action and forwards multicast traffic to all ports as specified by RFC 4541.
The iptables_hybrid option is not compatible with OVS-DPDK. The openvswitch option is not compatible with OVS Hardware Offload.
Configure the NeutronOVSFirewallDriver parameter in the network-environment.yaml file:
NeutronOVSFirewallDriver: openvswitch
-
NeutronOVSFirewallDriver: Configures the name of the firewall driver that you want to use when you implement security groups. Possible values depend on your system configuration. Some examples arenoop,openvswitch, andiptables_hybrid. The default value of an empty string results in a supported configuration.
