Security Aspect for Edge Cloud

Introduction

The users are authenticated using keystone with the help of LDAP and AD in the backend. This architecture should also support an External Identity Provider authentication. Keystone should recognize the token received from the IDP and then issue a token to the user to use the services of openstack.

The users will be assigned roles to implement RBAC for the various services available in Openstack.

But, this architecture has a threat of single point of failure, so we plan to implement a distributed control plane and federate the large/medium edge sites. Independent control plane is placed within each edge site. In the event of any problem or failure in the central data center, the edge site can authenticate the users. Due to the use of IDP, with the help of federation, user can authenticate in any edge site he may visit.

Keystone to Keystone federation is also another planned activity to enable federation between edge clouds using openstack.

We will investigate if there is any change in performance of keystone authentication and communication between Identity Provider and Keystone when different OS is installed in Edge clouds, for E.g. Ubuntu, Redhat Linux, Fedora etc and if different OS is installed in each cloud.

Keystone will work as a CA and sign the images before storing in the database, so trust is acheived when an edge site tries to access the image placed at the central database.

1st Architecture: Centralized Control Plane Scenario

1

The control plane is in the main datacenter. This gives a simplified management of compute resources across the edge sites.

2nd Architecture: Distributed Control plane Scenario

To implement robust security for edge cloud infrastructure, we should incorporate a Distributed Control plane scenario.

Independent control plane is placed within each edge site. In the event of any problem or failure in the central data center, the edge site can authenticate the users.

Large cost but can avoid single point of failure.

Install keystone at all the edge sites, which might be using different versions of linux.

1

We will test for each architecture:

Case1:

Here, keystone will use an external identity provider as a primary authentication system.

Case2:

Horizon can show a list of trusted Identity Providers and the user can choose an Identity Provider, he has an account with and can get authenticated there and use that token to get authenticated at keystone. The keystone after verifying the signature of the service provider, will issue a token to use with the openstack services. The Identity provider node at an edge site will be useful in case of any failure in the centralized datacenter and in case of users present local to that edge site, they can use the services of IDP locally instead of contacting the central data center.

Case3:

Keystone can also be used as an Identity Provider and federation between keystone to keystone can be achieved.

This can be used if we have many clouds using Openstack.

Keystone for Authentication:

Using keystone with the help of its local storage
Integrate identity with
- LDAP
- Active Directory
- Compare if any advantages.

Authentication using a Service Provider and SAML:

Web browser will be a middle layer.

When a user requests a service and if the user is not authenticated, he will be redirected to the Identity Provider, using a SAML request.

2

SAML response is communicated to the service provider and also the resource the user requested.

WebSSO with keystone and Horizon:

User will request authentication using a federated identity through a dropdown menu. Horizon will generate a keystone URL based on the IDP and redirects to keystone. Apache will identity that the user is not authenticated and redirects to the IDP with SAML request, and the request will follow the same steps as in the above case of SAML WEBSSO. Apache module will validate the response and redirects to the location of Horizon from where the request has originated.

2