The widespread adoption of cloud computing has resulted in proliferation of open source cloud computing frameworks that give more control to enterprises over their data and networks. Though, the benefits of the open source software are widely recognized, there is a growing concern over their security assurance. Often open source software is a subject of frequent updates. The updates might introduce or remove a variety of features and hence violate security properties of the previous releases. Obviously, a manual inspection of security would be prohibitively slow and inefficient. In this work, we propose an automated approach that can help developers to assure security of open source cloud framework even in the presence of frequent releases. Our methodology consists of creating a (stateful) wrapper that emulates the usage scenarios with explicit representation of security and functional requirements as contracts. We use a model-driven approach to model REST APIs of KeyStone, an identity service in OpenStack. Openstack is an open source cloud computing framework providing IaaS. Our models define structural and behavioral properties of Keystone together with its security requirements. We detail the implementation of these models in Django Web Framework and also show how to use the behavioral interfaces to implement a service monitor for the cloud services. This mechanism facilitates verification and validation of functional behavior and security requirement in an automated manner.
Keystone Open StackKeystone is the centralized identity service of OpenStack that offers authentication and authorization [25]. KeyStone authenticates a user by generating a token. A token can either be scoped or unscoped depending on the client's request and the configured policy of KeyStone. An unscoped token authenticates a user without authorising for any project. In contrast, a scoped token provides the authorization information of the user for a particular project or domain.KeyStone offers REST API in compliance with OpenStack policy [3]. REST services expose their functionality as resources and each resource has a unique URI that provides addressability. CRUD (create, retrieve, update and delete) operations can be performed on resources using standard HTTP methods. This means that only HTTP request methods (GET, PUT, POST, DELETE) can be invoked on KeyStone resources. In order to offer scalability, the statelessness feature of REST is ensured by treating every request independently without requiring any session or cookie information from user requests. Each resource, when invoked via its URI and a standard HTTP method, replies with a status code and a resource representation, which contains the data about the resource attributes and links to other resources. The HTTP response code is a numeric code that tells the clients whether the request went successfully. HTTP has a list of status codes that reveal how the request went [7], for example, 200 means the request was successful, 404 means the resource was not found and 403 implies th...