Networking

The OpenStack Networking service (neutron) enables the end-user or tenant to define, utilize, and consume networking resources. OpenStack Networking provides a tenant-facing API for defining network connectivity and IP addressing for instances in the cloud, in addition to orchestrating the network configuration. With the transition to an API-centric networking service, cloud architects and administrators should take into consideration best practices to secure physical and virtual network infrastructure and services.

OpenStack Networking was designed with a plug-in architecture that provides extensibility of the API through open source community or third-party services. As you evaluate your architectural design requirements, it is important to determine what features are available in OpenStack Networking core services, any additional services that are provided by third-party products, and what supplemental services are required to be implemented in the physical infrastructure.

This section is a high-level overview of what processes and best practices should be considered when implementing OpenStack Networking.

• Networking architecture
  • OpenStack Networking service placement on physical servers
• Networking services
  • L2 isolation using VLANs and tunneling
  • Network services
  • Network services extensions
  • Networking services limitations
• Networking services security best practices
  • OpenStack Networking service configuration
• Securing OpenStack networking services
  • Project network services workflow
  • Networking resource policy engine
  • Security groups
  • Quotas
  • Mitigate ARP spoofing
• Checklist
  • Check-Neutron-01: Is user/group ownership of config files set to root/neutron?
  • Check-Neutron-02: Are strict permissions set for configuration files?
  • Check-Neutron-03: Is keystone used for authentication?
  • Check-Neutron-04: Is secure protocol used for authentication?
  • Check-Neutron-05: Is TLS enabled on Neutron API server?