Network level

When we are moving to the cloud or opting for the cloud, network security is of the utmost importance. On the cloud, we can define the policy at our firewall level to allow and deny the traffic. In AWS, we use VPC to define the network. In VPC, we must create subnets to define the public, private, and management subnets. For SSH or RDP access, we must have either a jump server or bastion host. This will add one additional layer of security. The route table should be properly defined. We must define and configure network ACL to control the incoming and outgoing packets. In security, we only require the ports to be open and the source should be clearly specified. Do not open all the ports to the public.

For private subnet VMs, we can use the NAT service to enable internet access.

If you need to meet a specific compliance, you can use IPS and IDS to make the environment more secure.

To access resources from a management perspective, we should use a VPN connection. There are different types of VPN connections offered by AWS.

For a private and secure connection, we can use the Direct Connect connection between the customer site to AWS. 

In OpenStack, we must understand how the workflow process for the tenant instance creation needs to be mapped to security domains. There are a few services that directly communicate with neutron and these services must be mapped to security domains, as follows:

• OpenStack dashboard: Public and management
• OpenStack identity: Management
• OpenStack compute node: Management and guest
• OpenStack network node: Management, guest, and possibly public, depending upon the neutron plugin in use
• SDN services node: Management, guest, and possibly public, depending upon the product used

To isolate sensitive data communication between neutron and other OpenStack core services, we configure communication channels to only allow communication over an isolated management network.

We must restrict the neutron API connection to a specific interface using specifying details in the neutron configuration file.

Likewise, we must define the incoming and outgoing traffic using security groups.

When using flat networking, we cannot assume that projects that share the same layer 2 network (or broadcast domain) are fully isolated from each other. These projects may be vulnerable to ARP spoofing, risking the possibility of man-in-the-middle attacks.

To prevent this, we must enable prevent_arp_spoofing in the Open vSwitch configuration file.