CRITICAL REVIEW OF OPENSTACK SECURITY: ISSUES AND WEAKNESSES

The purpose of this study is to examine the state of both cloud computing security in general and OpenStack in particular. Conducting a reassessment of cloud computing security can provide a greater understanding of how cloud computing functions and what types of security issues arise therein. This study is divided into two parts; in the first part, the background of cloud computing and its different deployment models are discussed. This section also describes various security challenges that affect organizations’ decisions to adopt cloud computing. In the second part, an overview of the security issues in OpenStack is presented


INTRODUCTION
Cloud computing is a model for enabling convenient, on demand network access to a shared pool of configurable computing resources that can be rapidly provisioned and released with minimal management effort or service provider interaction (Kandukuri et al., 2009). Cloud computing utilizes three delivery models in which different types of services are delivered to the end user. The three delivery models are Software as a Service (SaaS), Platform as a Service (PaaS) and Infrastructure as a Service (IaaS), which provide infrastructure resources (Shey et al., 2009), application platforms and software as services to the consumer. These delivery models are shown in Fig. 1. These service models also place different levels of security requirements upon the cloud environment. IaaS is the foundation of all cloud services, PaaS builds upon IaaS and SaaS, in turn, builds on PaaS. As capabilities are inherited by successive models, so too are information security issues and risks.
There are important differences between each model in terms of merged features, complexity and security. Cloud service providers can provide the basic security architecture; consumers are responsible for implementing and managing the provided security features. Cloud Security Alliance (CSA) and Institute of Electrical and Electronics Engineers (IEEE) report that small-and medium-sized enterprises in the public sector are careful when adopting cloud computing, although those securities are needed together to accelerate cloud adoption on a broad scale and to respond to regulative drivers. Organizations using cloud computing IaaS prefer to examine security and confidentiality threats to their business as critical insensitive applications. In addition knowledge and its management is a foundation for creating competitive advantages in organizations (Mamaghani et al., 2011). However, ensuring the security of an enterprise's data in the cloud is difficult, but not impossible, if they supply services such as SaaS, PaaS and IaaS. Each of these services has its own security issues (Kandukuri et al., 2009). SaaS service providers ensure that services are available to customers on demand.
The SaaS model provides customers with important benefits, such as improved functional efficiency and reduced costs. SaaS is rapidly emerging as a powerful delivery model capable of meeting the needs of enterprises. Most enterprises are examining the security aspect of the SaaS model with respect to the lack of visibility of data, data storage and security. According to the Forrester study, security is the most common reason for enterprises to adopt SaaS Services (Shey et al., 2009). Therefore, enterprise security concerns have emerged as the biggest challenge to the acceptance of SaaS applications in the cloud (Subashini and Kavitha, 2011;Kaur, 2013). One issue that must be addressed directly is customer and vendor concerns about application and data security. There are strong concerns about insider divisions as well as vulnerabilities in application and system availability that could be causing the loss of money and sensitive data. These challenges can discourage enterprises from adopting SaaS applications within the cloud. IaaS completely changes the developers' perceptions. Rather than spending large amounts on infrastructure to build their own data centers or hiring host companies and renting operational staff to initiate the project, developers can go to Amazon Web Services or one of the other IaaS providers to gain access to a virtual server while paying only for the use of resources Amazon, 2013.
Cloud brokers could provide accurate scaling; they could easily expand without worrying about scaling and security (Buyya et al., 2009). In brief, IaaS and other related services have enabled start-ups and other businesses to focus on their strengths without worrying about the development and management of infrastructure. IaaS has fully abstracted the hardware underneath it and allows users to use infrastructure as a service without being concerned with the underlying difficulties. The cloud has a binding value hypothesis in terms of cost; although IaaS supplies infrastructure security and applications, activities within the cloud will require higher levels of security to be provided to consumers (Grivas et al., 2010).
PaaS provides a level above IaaS and abstracts out everything up to OS, middleware, this offers various development environments in which developers can build their applications without understanding what happens behind the scenes (Grivas et al., 2010). Furthermore, the developers offer a service that provides complete software development life-cycle management, from a to z (including planning, design, building applications, deployment, testing and maintenance). However, everything else is hidden from the developer's view.

Security Issues in SaaS
In SaaS, the client's security measures are dependent on the provider. The provider should ensure that each user's data are hidden from all other users. Security measures must be in place and the client must be confident that the application will be ready for use when needed. In SaaS, the cloud client will often replace old software applications with newer ones. Therefore, the focus lies not upon the portability of applications but rather upon protecting or developing the security functionality of legacy applications and attaining successful data migration (Subashini and Kavitha, 2011;Seccombe et al., 2009). Vendors of SaaS services may host applications on their own private servers or use cloud computing IaaS provided by a third-party (e.g., Amazon, Google). The use of cloud computing, along with the pay-and-go approach, helps application service providers reduce the cost of infrastructure services and allows them to focus on providing the best possible service to customers.

JCS
In the past decade, computers have grown more popular among enterprises as it services and computing have become commodities. Enterprises today can strategically view data and business processes (such as records, transactions and pricing information) themselves and protect these processes with compliance policies and access control. Furthermore, if the SaaS provider is leveraged as a public cloud computing service, the enterprise's data should be stored together with the data of other unconnected SaaS applications. In addition, the cloud providers should duplicate and store data in multiple locations across different countries for the purpose of maintaining high availability. Most enterprises are familiar with the traditional on-premise model, in which data are stored within the premises of the enterprise and are governed by the enterprise's policies. Thus, many businesses are uncomfortable with the lack of control over and knowledge of how their data are stored and whether it is secure in the SaaS model. There is great concern that problems involving data availability or data breaches could lead to financial and legal liabilities (Anding, 2010). Figure 2 depicts the layered stack for a classic SaaS vendor as well as important data security issues that span multiple layers. Security components should be considered essential parts of the SaaS application development and data deployment processes, including security, network security, locality, integrity, segregation, access, authentication and authorization, confidentiality, web application security, breaches, virtualization vulnerability, availability, backup, identity management and sign-on processes. The different security issues of SaaS are illustrated in Fig. 2.

Security Issues in PaaS
In PaaS, developers build applications on a computing platform controlled by the provider. In addition, any security issues beneath the application level, such as network and host intrusion prevention, are under the control of the provider, who must offer strong guarantees that the data cannot be accessed by other applications (Subashini and Kavitha, 2011). As a result, PaaS offers more flexibility than SaaS at the expense of customer-ready features. This trade-off extends to security features and capabilities, in that built-in capabilities are less complete, but, simultaneously, there is more flexibility to incorporate additional security. Applications which are sufficiently complex to take advantage of an Enterprise Service Bus (ESB), but which need to secure the ESB directly, benefit from protocols such as Web Service (WS) security (Oracle, 2013). In addition, is very beneficial to use PaaS for Successful Executive Information System Development for Education Domain (Kamaruddin, 2011). The capability to segment ESBS is not present in PaaS environments. Standards should be introduced to regulate the effectiveness of application security programs. Between direct application and security, specific metrics available patch coverage and vulnerability scores. These standards can indicate the quality of application coding. Attention should be paid to how malicious entities are adapting to new cloud application architectures that hide application components from their view. Hackers are likely to attack obvious code, although this is not necessarily restricted to code running in the context of the user. They are likely to attack the infrastructure and perform comprehensive black box testing. Service Oriented Architecture (SOA) applications, which are increasingly being distributed within the cloud (Cao et al., 2009).

Security Issues in IaaS
In IaaS, the developer has the best control over security, as long there is no security hole in the Virtualization Manager (VM). While in theory virtual machines might be able to address these issues as they arise, there are many security problems in practice. An additional factor is the reliability of the data stored in the provider's hardware. Due to the growing virtualization of the information society, enabling owners to maintain control over their data regardless of its physical location will become a topic of extreme interest. To obtain maximum trust and security on a cloud resource, several techniques need to be practiced (Descher et al., 2009). The security obligations of both the provider and the consumer vary greatly between cloud service models. Amazon's Elastic Compute Cloud (EC2) infrastructure presents an example in which the vendor's responsibility for security extends only to the hypervisor. This means that they can only address security controls such as virtualization security, physical security and environmental security. The consumer is responsible for the security controls corresponding to the system, including the applications, OS and data (Seccombe et al., 2009). IaaS gives rise to security issues whose severity depends on the cloud deployment model through which the services are delivered. The physical security of the infrastructure is extremely important; disaster management plans are necessary to prevent damage, either natural or intentional, to the infrastructure.
Infrastructure includes not only the hardware in which data are computed and stored but also the paths by which it is obtained or transmitted. In a standard cloud environment, data will be transmitted from source to destination through numerous third-party infrastructure devices (Ristenpart et al., 2009). However, the complexities arising from the various service deployment models of IaaS are illustrated in Table 1.
Cloud architectures are built upon underlying technology. A cloud built over the Internet inherits all of the internet's inherent security risks. The foundations of cloud technology force consumers and providers with different physical locations to virtually access resources over the Internet (Prautzsch and Graves, 2011;Sehgal et al., 2011). Even if an enormous amount of security is established in the cloud, data must still be transmitted via the underlying internet technology. Therefore, the security concerns threatening the internet also threaten the cloud. However, the risks to cloud computing are especially great. The vulnerability consideration and asset value of the resources and asset value of the resources and their nature of them settling together. Cloud systems still use normal internet protocols and security standards but require greater levels of security. Although secure protocols and encryption cater to current needs to a certain extent, they are not context oriented (Mell and Grance, 2009). A strong set of policies and protocols is necessary to secure data transmission within the cloud. Concerns regarding the intrusion of external non-users into cloud databases should also be considered. Standards should be established to construct a secure, private and isolated cloud environment in the internet that is capable of avoiding attacks by cyber criminals.
The focus of this study is to inspect and evaluate the possibility of implementing cloud computing using OSS technology and, in particular, OpenStack, the pioneer product of OSS. Moreover, this study contributes to the swift project, which is part of the OpenStack project, by strengthening its security arsenal. Swift is the OpenStack object storage project, the purpose of which is to offer cloud storage software in which users can store and retrieve large amounts of data in virtual containers.

OpenStack
This section gives an overview of OpenStack, its components and the nature of its security mechanisms.

Overview on OpenStack
In October 2010, the initial "austin" release of OpenStack was published. It consisted of only two projects: Object storage and compute. Object storage was ready for production and compute was intended for testing. In February 2010, an updated version of OpenStack was released under the name "bexar". With bexar's release came a new component, called "OpenStack image service". In addition to releasing the new project, the development teams also made some enhancements to the previously announced projects. For example, the object storage (swift) project introduced a means of authorizing and authenticating users, known as "swAuth". The third release, code named "cactus", announced the addition of two features to the object storage project: The option to serve static content and the ability to perform content checksum validation during get object actions. At the same time, OpenStack was performing quick enhancements on and providing additional support for virtualization technology. the fourth and, at the time of this writing, latest OpenStack release, "diablo", was announced in September 2011, at Science Publications JCS which point the OpenStack community included over 1500 people and 87 companies. At this time, the number of product deployments began to increase. Although the project teams improved scalability, availability and stability, many security concerns were still pending. OpenStack is open-source software for building private and public clouds (Wen et al., 2012;Beloglazov et al., 2012a). OpenStack consists of three main projects. The relationships between these projects are depicted in Fig. 3.
The core services are compute, storage, networking and dashboard, whereas the auxiliary services are identity and image: • Nasa developed OpenStack compute (NOVA), which provides and manages networks of virtual machines. Public cloud service providers offer Infrastructure as a Service (IaaS) Rackspace developed and contributed to OpenStack object storage (swift and cinder). OpenStack storage saves objects and blocks for servers and applications. Object storage, implemented via a distributed storage system, is designed to house static data, such as virtual machine images, backups and archives. These objects and files are saved in disk drives throughout the OpenStack cloud.

JCS
Hence, scalability and repeatability are achieved. OpenStack likewise provides constant block-level storage devices for computing tasks that require high performance storage, which is often required by databases, expandable file systems, or servers that access raw block-level storage (Baset, 2012). The features of OpenStack storage are as: • Commodity hard drives reduce the storage cost per byte • It is capable of self-healing because data are copied to different sectors of the cloud; thus, the storage system becomes highly redundant and reliable • It can store data on a very large scale; multiple petabytes of data and billions of individual objects can be stored • Amazon s3 (elastic block storage) API is supported • Utilities enable the management of account, container and storage monitoring features OpenStack image repository (glance). This component enables discovery, registration and delivery for disk and server images. Base image templates can be created for use in new instances users and administrators can also construct and store snapshots of images, which can be saved in raw, VHD (Hyper-v), VDI (VirtualBox), qcow2 (Qemu/KVM), VMDK (VMware) and OVF (VMware, others) formats (Baset, 2012).
OpenStack networking (quantum). OpenStack networking is an API-driven system for cloud networks and IP addresses. Its features include the following: • Static, DHCP and floating IP addresses are managed • It supports several networking models, such as flat networks and VLANs • It creates and manages users' • It supports SDN technology (i.e., openflow) OpenFlow (SDN). A systems architecture, SDN stands for "software-defined networking". Although SDN has become widely recognized only recently, its defining architecture has been extensively used. A conventional network device contains hardware and software. Users, however, could not independently define a network because of the lack of an Application Programming Interface (API).
Hence, OpenFlow was introduced. This technology is capable of enabling SDN. It is not a networking method that provides specific functions, such as l2 (layer 2) switching or IP routing. Instead, OpenFlow is simply an interface that can be installed on a network device. Promoting the use and standardisation of SDN, the Open Networking Foundation (ONF) defined the specifications of SDN (Mell and Grance, 2009), including the components and basic functions of switches and the OpenFlow protocol for managing OpenFlow switches from remote controllers. OpenFlow accesses and manages the API controlling the hardware, although information concerning the latter is not disclosed by the device manufacturers and enables users to independently manage networks. The network framework allows various devices to be incorporated within the cloud, including intrusion detection systems, load balancers and firewalls.
OpenStack dashboard (Horizon). OpenStack dashboard enables administrators and users to provide, manage and control cloud computation, storage and networking resources. Dashboard is used to create users and projects, assign users to projects and decrease the resources required for such projects. It also provides and controls resources allocated to projects. The OpenStack dashboard is an extensible web-based application (Crago et al., 2011).
OpenStack identity (keystone). OpenStack identity maintains a database of users and provides authentication services. A common authentication system is provided throughout the cloud and can be integrated with third-party, back-end directory services (i.e., lightweight directory access protocol or ldap). It supports multiple verification systems, such as the standard username and password, token-based systems and web services such as Amazon. OpenStack identity allows cloud administrators to establish policies across users and systems, create users and tenants and grant permission to compute, store and network resources (Beloglazov et al., 2012b). All of the core services are illustrated in Fig. 4.

Security in OpenStack
We have found several flaws in OpenStack; these threats may be addressed in the current releases of OpenStack (Slipetskyy, 2011;Cigoj and Klobucar, 2012): • Users cannot reset their passwords on horizon; regular users can only have their passwords reset by the administrator within the horizon interface. We do not currently know how this flaw will impact • The administrator of a project on horizon is automatically made the administrator of the whole Science Publications JCS system. OpenStack utilizes the concept of projects and tenants to group people into logical units for cloud computing. However, the administrator of a single project is granted managerial rights to all projects, not merely the project at hand, by the interface. The administrator's privileges, including the creation of new users and projects, have the potential to change other projects, remove items • Cleartext is used in the network API.
OpenStackapi endpoints encourage the use of cleartext and no SSL/TLS support is available right now. This allows for easy man-in-the-middle attacks and even "sniffing" passwords over the wire can be trivial • No authentication in the client-server system. It appears that any host with access to the db and to the AMQP system can act as a compute node and launch VMs • Usernames and passwords. Passwords and usernames that are used for accessing images will be stored in Cleartext in the db and in external storage. When glance stores images on swift, for example, the username and password of the swift account will be stored as Cleartext in the db together with the URL of the swift object. This could potentially allow the information of any swift user to be accessed and read from the db. This storage of information is unnecessary because the username and password are already stored in the glance configuration file The problems discussed in this section will be used as the basis for studying cloud security solutions in subsequent sections. While studying the security issues of cloud computing in the previous section, we discovered which issues are often discussed in relation to identity and access management. In this section, we discuss identity and access management.

Identity
User provisioning is the process of registering a new user with a given system and user deprovisioning is the process of removing a user from the system. OpenStack object storage "swift" offers significant automation of user data management tasks by using authentication/authorization systems referred to as "tempAuth" and "swAuth". The difference between "tempAuth" and "swAuth" lies in the backend storage of user data. TempAuth uses a configuration file in which user data are saved as plain text. on the other hand, swAuth is meant to be a "scalable authentication and authorization system that uses swift itself in a backing store" Swift/overview, 2013. A swift account is created on a swift cluster and user information is stored in "json-encoded" text files, which are also swift objects. Both swAuth and tempAuth allow on-demand user provisioning and deprovisioning, which is in accordance with industry standards. The characteristics of user management are based on OpenStack object storage "swift" (Cigoj and Klobucar, 2012). The following characteristics are present: • Users are not given administrative power over any other users • Provider Admins have admin agreements with all accounts but cannot add other provider admins • Super admins are powerful users who are able to perform all user management procedures, including adding provider admins

Authentication
TempAuth and swAuth often use a username and password for the authentication process. When authentication is successfully performed, the user receives a token that will identify him to the system for a period of time. The provided token has a configurable expiration time, the default value of which is set to 4-6 h. All cloud security documents must, allow authentication by accepting confirmations in SAML format; however, this feature is not yet available in OpenStack (Khan et al., 2011).

Strength of Password
Because all OpenStack projects use a password and username system to authenticate users, password strength requirements should receive greater scrutiny. The "Electronic Authentication Guideline" created by NIST supplies guidelines for helping users avoid choosing bad passwords, such as checking a password against a dictionary of commonly used passwords, instituting a minimum password length and requiring the use of certain types of character (such as upper-case, lower-case and non-alphabetic) (Cigoj and Klobucar, 2012;Mell and Grance, 2011). Unfortunately, none of these requirements (dictionary checks, minimum password lengths, or special character requirements) exist within OpenStack, allowing users to register with short passwords containing no special characters.

Storage of Password
Password storage poses a well-known problem to all information systems using password authentication. A common practice in information security is to require the administrator to guarantee that passwords are encrypted, rather than being stored as cleartext. It is also important to limit access to the location where passwords are stored.
As was mentioned previously, tempAuth stores usernames and passwords in a configuration file in which all passwords are recorded in plain text format. The location of super user credentials is also saved to the same file, as shown in Fig. 4. By default, each user in the system possesses reading access to this file. Such access enables system users to gain the passwords of other users and easily obtain access to their accounts. Most of the developers never considered tempAuth to be suitable for production deployment.
SwAuth uses a special configuration file where super admin passwords are saved, unlike tempAuth and swAuth possesses properly configured access permissions for files containing secure password data. The only security threat that arises in swAuth is that the passwords within these files are stored in clear-text. Therefore, an internal attacker could gain access to super user accounts within the system and thus be able to learn user passwords. OpenStack should consider hashing passwords before saving them to the password file (Jackson, 2012;Laszewski et al., 2012).
In conclusion, both tempAuth and swAuth lack appropriate password protections. Both authentication systems should implement the following recommendation, taken from NIST's "Electronic Authentication Guideline": Saved passwords and/or usernames should be salted and then hashed with an approved algorithm, so that the techniques used to conduct dictionary or weakness-based attacks on a stolen password file would not be useful for attacking a similar password file. A comparison of the two authentication systems is given in Table 2. This is interrelated to the designated deployment modal because the control of the data and applications is directly supervised by the strict control of the owner Availability

JCS
The capacity of a system to operate upon the demands of a certified entity. This notion implies that the system should be able to function even in the presence of authorities that disobey the regulations. Furthermore, the system must also maintain the capacity to operate even in the existence of a security breach Integrity Resources can only be reformed by approved individuals and through official procedures.

• Software
The diverse resources include data, software and hardware • Data (Authentication, Authorization and Access control AAA) Confidentiality Data in cloud computing are more vulnerable because of the increase in the number • Software of individuals, devices and applications that use cloud computing which will in turn • Data increase the number of access points. Consequently, authorized individuals and systems are the only entities that are allowed to access the protected data Privacy An individual's need to govern the entree to his/her personal information Recently, all components of "Essex", the latest release of OpenStack, support Identity Service (Keystone), which introduces a more secure way of storing passwords in the database. Customers must be identified by Keystone before they are allowed to use any of the cloud services, which guarantees a unique point of entry. Keystone encrypts usernames and passwords and provides each user with a unique token that enables access to the services for which they are authorized. So far, Identity Service provides the most complete security solution available to Open Source clouds.

Authentication Tokens
Authentication tokens play similar roles as identifiers for web applications. An API, such as an OpenStack service, is used to authenticate a user. Successful authentication generates a token that is used to authorize service requests. The password and username are given as input to the API interface. When authentication succeeds, the resulting feedback includes an authentication token and service catalogue. Note that tokens remain valid for 12 h. Issued tokens become invalid in two situations: • If the token is expired • If the token has been canceled It is important that the authentication be executed over a secure channel, such as Transport Layer Security (TLS); otherwise, an attacker could obtain a user token by executing a man-in-the-middle-attack and remove the user who received the token from the Science Publications JCS authentication system. However, Rostyslav Slipetskyy has subjected the algorithms that are imported for token generation to a more detailed examination. The algorithm imitates the approach used to generate Universally Unique ID (UUID) and utilizes a solid source of randomness that has no known disadvantages and thus is considered to be secure by (Slipetskyy, 2011).

Susceptibility of Authentication Data
The transfer of OpenStack authentication data from one server to another is not safe. SwAuth has security issues that allow provider admins to view the data belonging to all users who are managed by the admin account. Malicious users are also able to gain access other users' passwords (Lonea et al., 2012;Dlamini et al., 2012).

Maliciousof Data
Most cloud providers do not encrypt data before saving it to a cluster. In fact, OpenStack does not provide any data encryption at all; thus, users would need to encrypt their data before uploading it and manage their encryption keys themselves.
It may be difficult to track security issues in cloud computing environments. Therefore, the primary aim of this study is to highlight the implications of the major security issues. Table 3 provides a summary of these security issues, which are divided into five categories and listed with their implications.

CONCLUSION
Cloud computing provides an important benefit to companies looking for an advantage in today's economy. Many providers are offering cloud computing services; this competition will lead to increasingly affordable prices over time. Lower prices enable businesses to use staff for other tasks and allow them to consume resources more efficiently by paying for services only as they are needed. These features, supported by an attractive and economical pay-as-you-go approach, have led to growing support for this model. One important threat posed by cloud computing is the obscuring of boundaries between internal and external security concerns. To understand how well companies' data are kept safe, security services in the cloud must be closely studied. In second level will be the availability, as providers can be victims of attacks that stop the running of their operations.
This study discusses issues that arise with the deployment model of cloud computing; in particular, this study focuses on OpenStack security issues and threats. Certain parts of OpenStack are considered secure while others need to be improved. OpenStack does not support minimum password complexity requirements and passwords are stored in plain text format. There are no controls to regulate access to sensitive files, including those containing passwords. Information transferred within the cloud is not protected through the use of file encryption techniques.