Keystone Federated Security - Security Infrastructure for Hybrid Clouds and Cloud Federation for Openstack

With hybrid clouds increasingly becoming important in the field of cloud computing there is a rapid raise in the demand for a secure infrastructure that would enable sharing of computing resources between multiple hybrid cloud deployments to facilitate accommodation of situations where the demand outstrips supply, load balancing, and other such infrastructure constraints. But the current implementation of OpenStack provides no support for federation between multiple OpenStack deployments.
Thus the objective of this project is to implement a secure infrastructure to achieve federation as a natural extension of Openstack.

Design and Implementation:

The design typically addresses the issue of achieving federation between multiple hybrid cloud deployments. It is general and applicable to all types of clouds, in hybrid clouds there generally is a primary cloud owned by the enterprise, and multiple Remote Clouds owned by service providers or partners in which cases, it is preferable to extend the capabilities of the primary cloud to allow federation. We assume that, there are two clouds – a primary cloud, and a Remote Cloud, and that users of the primary cloud want to access resources in the Remote Cloud. It is assumed that there are a number of tenants in both clouds. We also assume that trust relationships have already been set up between the primary cloud and the Remote Cloud.

Our implementation relies on gateways that are typically extensions to keystone in case of Openstack that (i) relay requests from the primary cloud to the Remote Cloud and (ii) translate requests for resources to commands that are understandable by the Remote Cloud. Since a trust relationship has already been set up between the clouds, the gateways in the primary cloud and the Remote Cloud have already established a secure communication channel and are ready to receive requests from each other. It can be seen from the description below that the inter-gateway communication can consist of SAML calls. Also, the policy engine in our implementation is extended to support RBAC.

The authentication process is done at three levels namely Remote Gateway Acquisition, Remote Tenant Acquisition and Remote Resource Acquisition .To acquire resources, users in the primary cloud execute the following protocol.

1. Remote Gateway Acquisition:
It is necessary for users to get a token (referred to as a GAT or Gateway Access Token) that allows them to access the gateway in the remote cloud. Since in Openstack, the access tokens are obtained at login, the user obtains the GAT via a background call to the gateway in the primary cloud which in turn contacts the remote gateway so as to verify the user credentials from the NEWROLES table present in its database. Upon successful authentication, it returns a GAT (Gateway Acquisition Token) to the user and at the same time updates the GATS table (database maintained in the Remote cloud) so that the GAT can be validated at a later time.

2. Remote Tenant Acquisition:
 Once the user has the GAT, they need to obtain a token that specifies the list of tenants they can access in each remote cloud. This could also be accomplished via background calls at login. However, for efficiency and security, in our design, these tokens are acquired when the user wishes to access a remote tenant. At that point, the user sends the GAT to the foreign gateway. The foreign gateway validates the GAT from the GATS database, then generates a list of tenants that the user can access. Once, the user has chosen a particular tenant, the gateway returns the TAT or Tenant Acquisition Token for that particular tenant after making the background calls to Keystone of the remote cloud.

3. Remote Resource Acquisition:
the user then sends the TAT with a request for resources to the Remote Cloud. Before granting the request, as before, the appropriate Openstack process invokes Keystone to validate that the user has access. The modified Keystone recognizes that this is a remote request, and invokes the gateway to validate the request. The Gateway validates the user credentials obtained from the TAT and uses RBAC to authenticate the same for the resource requested. Upon successful validation, the gateway grants the resource access to the user. Once the access is granted, the user can access the resources directly without having to go through the authentication processes.

For more details :
1. http://www.slideshare.net/openstackindia/keystone-federation

2. http://ieeexplore.ieee.org/xpl/articleDetails.jsp?tp=&arnumber=6750285&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D6750285