Nowadays, a majority of cloud service providers offer an API that allows users to interact with their infrastructure for the creation or deletion of resources, volumes, and images, to name a few. To use these APIs, users have to first authenticate using mechanisms based on key-password pairs.
However these mechanisms are quite cumbersome as users often have to search for their credentials on cloud provider websites or in their file systems. Besides, these key-password pairs are in the format of long and difficult chains of alphanumeric characters, which make them impossible or pretty difficult to remember. Even though the use of these key pairs is justified by security reasons, it clearly affects a user’s experience when having to access these APIs. In ElasticBox, as well as in many other cloud platforms, users have to specify their credentials, in order to interact with cloud vendors such as AWS, Google Compute Engine (GCE), Microsoft Azure, VMware, Openstack or Cloudstack among others.
Our philosophy at ElasticBox is to alleviate and minimize all tedious management operations which affect a user’s experience, as long as they don’t present security issues. In the following, we will focus on Google Compute Engine’s API which supports two authentication mechanisms to interact with resources.
Users now create Google Compute Engine providers by setting a project ID, service account email and uploading a private key file. Most of the time, users have to access their Google Developer Consoles to obtain all these credentials. This might not sound too hard, until you get to the organization level, where having to manage several GCE projects, service accounts, emails and private keys can be a real nightmare. Fortunately, there’s no need to reinvent the wheel, a better solution was already there! As most of you already know, Google supports a single sign-on authentication (our most popular authentication service) which allows users to access to any Google service when they are a logged in. To take advantage, we decided to change our GCE access management mechanism to benefit from the Google single sign-on (SSO) platform. Using Google SSO, ElasticBox users are now able to link their ElasticBox account to a Google account when creating a GCE provider. This linking operation only takes place when configuring a provider for the first time. By doing so, users simply need to specify a project ID (a customized name users chose when they create a project) to easily create providers, and thereby start managing GCE resources.
- Users don’t have to enter new credentials every day or after a while, which isn’t practical.
- Users don’t need to handle complex chains of alphanumeric characters or download/upload private key files.
How does it benefit ElasticBox users? This authentication model helps our ElasticBox users from two different viewpoints:
- From a DevOps perspective, this model exempts DevOps from having to search for their credentials every time a GCE provider needs to be created.
- From an Admin perspective, this model facilitates the access management and control of infrastructural expenses for each project member. Administrators can now share projects and assign permissions to existing Google accounts instead of sharing different key-password pairs with the project members. Moreover financial expenses of the project members can easily be identified based on their Google accounts.
With this new feature, we believe users will easily configure GCE providers, as well as organizations will be able to manage the permissions and expenses of their members. To learn more about how to create GCE providers, please visit our documentation. For a free consultation about how this authentication mechanism can benefit your particular use-case, please email us at email@example.com