Networking service

Networking service

Recommendations:

  • Use an isolated management network to provide communication between the OpenStack Networking services and other OpenStack core services to mitigate spoofing and tampering attacks.

  • Enable security groups to specify the type of traffic and a direction (ingress/egress) that is allowed to pass through a virtual interface port. Disable security groups in Compute service and proxy all security group calls to Networking API. To do that, set firewall_driver to nova.virt.firewall.NoopFirewallDriver to prevent nova-compute from performing iptables-based filtering; security_group_api to neutron to have all security group requests proxied to Networking service.

  • Secure Networking API endpoint through TLS 1.2 or later. Use TLS 1.2 or later with available stack of ciphers. For example, you can use DHE-RSA-AES256-GCM-SHA384 cipher with DH public key size 3072 bit and private key size 256. In case of ECC, use TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 cipher with a 256 bits DH key length using elliptic curves. SP800-131A approves AES-128, 192, 256 bits encryption to mitigate information disclosure threat. See the Cryptography introduction section above.

  • Keep private keys secure on API endpoints by using appropriate file permissions and other controls to mitigate information disclosure threat.

  • Define a network policy enforcement (RBAC) to Networking-related actions, depending on customer’s requirements, policy, and use case to mitigate EoP threat. Customize the Networking policy.json file.

  • Networking service separates projects by utilizing iptables along with ebtables rules. These rules prevents MAC and ARP spoofing attacks on virtual or NFV L2 layer.

  • Configure per-tenant quotas for L2 and L3 resources and security groups for projects to avoid overconsumption of network resources and mitigate DoS attacks. See OpenStack Admin Guide for basic quotas configuration.