The following sections describe the process of how the Testbed was built and provide a discussion of the options and the configurations used to support this research.
3.2.1
Cloud Environment Preparation
First the cloud was built on two nodes, Controller and Compute, running Ubuntu OS. Following the online guidelines [141][142], the two nodes were connected to the management network (Tables 3.1 and 3.2), which manages the cloud communication between the nodes. The switch
Compute Node Controller Node Tunnel/manegment Switch 192.168.137.0/24 VBOX-nat Switch 10.0.0.0 Gorman Server Internet 10.0.0.1 10.0.3.15 10.0.4.15 192.168.137.11 192.168.137.10 External Switch 192.168.100.0/24 eth1 192.168.100.1
Figure 3.3:OpenStack Mitaka Cloud 2-Nodes.
ext-net was specified to provide instances (VMs) with an external connection to the Internet and the NAT network was specified for cloud packages installation and update.
Cloud Network:
Switch Name Network Gateway
Management 192.168.137.0/24 192.168.137.1 ext-net 192.168.100.0/24 192.168.100.1
NAT 10.0.0.0/24 10.0.0.2
Cloud Node:
Node Controller Compute
RAM 4GB 8GB
CPU 2 cores 6 cores
Hard Disk 300 GB 200 GB
Network eth0:Static(Management)=192.168.137.10 eth0:Static(Management)=192.168.137.11 eth1:Manual(Ext-net) eth1:Internet access(NAT)=10.0.3.15 eth2:Internet access(NAT)=10.0.4.15
OS Ubuntu-14.04.2-server-amd64.iso LTS Ubuntu-14.04.2-server-amd64.iso LTS
Table 3.2: OpenStack Nodes Configuration Details.
Table 3.2 shows that the Compute node has a higher RAM and CPU as is required to support the hypervisor to create tenant instances. However, the Controller Node has an extra connection in eth1 that is set to manual as the Controller implements the Neutron service, which provides the external connections to the instances.
3.2.2
OpenStack Environment
In Appendix A, Table A.1 demonstrates the number of necessary packages to run the Mitaka version of CloudStack and shows the building process.
3.2.3
Cloud Network Configuration
In Appendix A, Table A.2 lists the most vital cloud configuration files that define the cloud network infrastructure. Due to the presence of Neutron as a network service in the controller node, the amount of files to be configured is significantly more than the Compute files. Moreover, Open vSwitch (OVS) plugins are extensively used as the configuration files indicate.
In the controller node, Neutron runs three main agents[143]:
• L3 agent: when a tenant creates a router, this agent employs the "Linux network namespace" to build the tenant vRouter using the configuration in the file l3_agent.ini.
• DHCP agent: another "Linux network namespace" is used to build up the DHCP server of the private tenant network based on the DHCP_agent.ini configuration file.
• L2 (OVS) agent: openvswitch_agent.ini provides all the configuration necessary to facilitate OVS within the cloud networking environment.
Namespaces and OVS are defined later in the next section. The explanations as to why and where they occur in our cloud is also presented.
All the noted options above, except for the networks and instances created by users other than the Admin, are controlled by the cloud provider and not the cloud users or tenants. In other words, all the configurations that define the VN structures are controlled by the configuration set by the cloud provider and the tenants are not aware of them.
3.2.4
External connection
Tables 3.1 and 3.2 list ext-net as an external network used by Neutron to provide the instance external connection. However, OpenStack designed the interconnection between the inner side of the cloud to the external side of the cloud through an OVS bridge called br-ex and it is configured as shown in the commands below. The command add-br adds the br-ex bridge to the cloud infrastructure. The commandadd-port links the controller node physical network eth1 -which is the exit path to the Internet – to the br-ex, which is the last edge of the cloud inner network connection.
The commands used were:
sudo ovs-vsctl add-br br-ex
sudo ovs-vsctl add-port br-ex eth1
3.2.5
Preparing the Testing Scenario
The following section outlines the steps taken to build the OpenStack testbed scenarios.
3.2.5.1 Tenants and Users
Cloud Consumers, users, roles are confusing terminology especially when it is referenced within the cloud systems. Openstack used similar terminologies for its implementation.
OpenStack uses the terminologies projects, roles and users. A project is described as an isolated resource container and is the new name of the Tenant where users are grouped within to share the resources and quotas. A user is the digital identity that can login to access the is OpenStack cloud services, is assigned to a specific project (tenant) and is then given specific privileges based on the role defined with (admin, standard, etc) [85] [142].
In this research we refer to the project as a Tenant and the user assigned to a project is a user. All users are given a standard role except for Admin, which had administrative privileges.
The OpenStack Mitaka cloud operates on two Ubuntu nodes (the Controller and Compute Nodes) as seen in Figure 3.3 earlier. Other than the Admin and the Test tenants which were created per the cloud installation guide [141][142], and which contained an Admin and Test user respectively, another tenant (Tenant1) was created as shown in Table 3.3. A private Virtual Network with a private router, see Table 3.4, was connected to a public router to allow instances to be connected from outside using SSH. Tenant 1 has two users (T1user1 & T1user2) each with a VM (instance), see Table A.3 in Appendix A. Tenant users provide credentials to access their instance and find more details about their assets in the cloud through the O enStack Horizon webpage, sometimes called the Horizon dashboard, (http://192.168.137.10/horizon).
Project Users
Admin Admin Test Test Tenant1 T1user1
T1user2
Table 3.3: Projects (Tenants) Listed With Their Corresponding Users.
3.2.5.2 Network and Routers
The two networks– see Table 3.4- under the Admin are created by the provider, while the Test user did not create any. Users T1user1 and T1user2 create their own networks. Unlike the Admin
Network Details Admin Test T1user1 T1user2
Network Name ext-net Network1 - t1user1net t1user2net
Router external Router1 - t1u1R t1u2R
Router Networks - Subnet1
ext-net -
t1u1subnet1 ext-net
t1u2subnet ext-net
Physical network br-ex - - - -
Network type flat vxlan - - -
shared Yes Yes - - -
Subnet Name ext-subnet Subnet1 - t1u1subnet1 t1u2subnet
subnet IP 192.168.100.0/24 10.190.0.0/24 - 192.168.10.0/24 192.168.20.0/24 Subnet range start=192.168.100.10 ,
end=192.168.100.200
start=10.190.0.5,
end=10.190.0.254 - - -
DHCP Disable Enabled - Enabled Enabled
Gateway 192.168.100.1 10.190.0.1 - 192.168.10.1 192.168.20.1
user, the two users did not provide the details of network configuration. However, they are assigned default values by the system based on the original configurations from the cloud setup files, as defined earlier in Table A.2. For example, the networks created by tenants are not shared by default and the network type is vxlan by default as configured in the file ml2_conf.ini above.
3.2.5.3 Instances
Table A.3 in Appendix A shows instances and configurations. My_first_instance is the only instance created by command line to test the cloud functionality. However, all the remaining instances were created from the dashboard using the Admin account. It is worth mentioning that each tenant can view only the information about elements they have created except for the Admin, which can view all elements. However, it was discovered that T1user1 and T1user2 could view all the elements from both users, which is of concern. Allowing tenants to create users if there is no privacy between them. In addition, all users can use Network1 not because it is created by the Admin but because the Admin set it to be shared. Therefore we decided that a test tenant should use Network1 to connect to its instances, and planned to make the Test tenant the cloud attacker.
All the above information and terminologies are essential and play significant roles in the VN created by the clouds. Relevant concepts and terminologies are defined in the following sections.