Powered by OpenStack [Version 11.07.11]
An OpenStack cloud is using perimeter security on networks and traffic as well as controlling access by assigning security groups.
By default, there are several networks set up as part of an OpenStack installation. These networks include:
A private management network for monitoring, PXE boot, and Compute intercommunications
A private network for exposing API endpoints
A VM network for private VM IPs
A public network for VM floating IPs
Typically, the private and management networks are isolated from the Internet. Should it be desirable to connect these networks to the Internet or to internal enterprise networks, network administrators should set up VLANs and layer 3 ACLs. In addition, it is possible to set up routing and/or public NAT to the API endpoints per the security policy of the organization.
By default, no services are listening on the public network or on the VM network (with the exception of dnsmasq in the case of a FlatDHCP configuration). Ideally, VM-net traffic is configured on the firewall to allow outbound Internet access through a NAT pool, but firewall rules can be put in place at the firewall as necessary.
Inbound traffic is designed to be unfiltered, with access controls via API using floating IP addresses and security groups. Floating IP addresses are implemented (in the multi-node configuration) by static 1:1 NAT from the public IP to the private VM-net IP on the hypervisor running the instance. This allows the ability to apply a public IP on a VM through API interaction. Security groups, detailed in the next section, control your firewalls on inbound traffic.
Security groups are used to programmatically apply IP table rules to interfaces that are exposed to the public Internet via floating IPs. By default, no traffic is allowed to IP addresses made publicly accessible via floating IP API. To allow access to public services, simple IP table rules can be saved as a set, and later referenced to apply rules to virtual machines. These sets are called security groups.
For example, a "mysql server" security group could be created to allow traffic from 0.0.0.0/0 to port 3306/tcp. By associating a new VM instance with this security group, global Internet access to the mysql service would be allowed. A VM instance can belong to zero or more security groups, with the rules applying cumulatively.
Security groups can allow incoming port ranges from specific CIDR ranges over both TCP and UDP. In addition to TCP and UDP, ICMP can be enabled or disabled on a CIDR basis, although without the ability to specify subtype.