State of the art
Overview
As can be observed from both the scenarios and requirements sections, the topic at hand is highly technical, involving many actors spread across both space (over the network interactions) and time (asynchronous interactions), and relates to the authentication and authorization of actions, specifically |API| calls initiated by software components, whose target are cloud resources, hosted by |CSP|'s and owned by |EU|, on behalf of which the software components may act, requiring thus privilege delegation from the |EU| towards these software components.
Important
We can not stress enough the fact that in the context of the credential service, the clients we speak about are not "humans" but instead software components or agents which interact with various external services on behalf of the |EU|. These clients are part of the deployed |SPECS| applications, acting on behalf of real persons which are |EU| in the |SPECS| terminology; meanwhile at the opposite end of the spectrum, the target services are other software components or agents part of either the same deployed |SPECS| applications, or most likely services offered as |SaaS| by external |CSP|'s.
Unfortunately, to our knowledge, this topic has not yet been explicitly touched by any of the cloud related scientific literature, perhaps only hinted to in some works covering cloud security. However this topic is actively discussed in the non-academic world, especially in blog posts by various engineers, like for example |yeda|, although due to practical reasons they stop at the level of securely distributing credentials by leveraging |CSP| provided services.
On the other hand the |Grid| community has already tackled and solved quite elegantly this topic by using |X.509| proxy certificates, as described in |rfc3820|, but unfortunately it is not applicable in the current cloud ecosystem for the simple reason that |CSP|'s have chosen proprietary, non-interoperable, and sometimes weak, authentication schemes that in almost all cases do not rely on public key infrastructure but instead on shared secrets. (The only notable exception is the |X.509| authentication for a handful of |AWS| services, and only when accessed through |SOAP| calls.)
Therefore the only solutions, remotely resembling our requirements for the credential service, are |STS| (Security Token Service) (not related with |SPECS|'s service with the same name), the |SASL| and |GSS-API| mechanisms, and |Plan9| factotum and secstore services.
Amazon Security Token Service
As previously noted in the scenarios section, |Amazon| has perhaps the most powerful and flexible security related features for their cloud management |API|, something yet unmatched by any of the existing cloud providers. As a further example of their focus towards security, they offer free of charge a dedicated service, namely |STS| (Security Token Service) |yagi| (unrelated to |SPECS|'s service with the same name), which allows the credential holder (either human or a software component) to create a set of new temporary credentials, restricted to a sub-set of the permissions allowed for the initial credentials.
There are two major ways in which one can put this |STS| service to good use, the first being through the usage of |IAM| roles via |EC2| |VM| profiles, meanwhile the second involving the usage of |STS| by a delegation service creating and conveying the resulting temporary credentials to the service needing them. In what follows we shall briefly discuss each of these two variants, highlighting their limitations and the main differences between these approaches and our proposed credential service.
STS via IAM roles assigned to EC2 VM profiles
The simplest, and most secure, method of leveraging |STS| is through the usage of |IAM| roles for |EC2| |VM|'s. Technically this involves defining an |IAM| role, then assigning it a set of permissions through |IAM| policies, followed by creating an |EC2| |VM| profile bound to this |IAM| role, and finally by choosing the this profile when launching a |VM|. Once the |VM| has started, through a series of |STS| |API| calls, the applications running on the |VM| can use the resulting temporary credentials, achieving thus access delegation.
It must be noted right from the start that if one strictly (and fully) follows the cloud deployment best practices, namely having one and only one service per |VM|, and furthermore that each service has always the same security access requirements, then by the usage of |IAM| roles and |STS|, one can obtain a (practically) sufficiently secure solution.
There are however certain limitations to this solution, especially in the case when on the same |VM| one needs to run multiple services, like in the case of shared |PaaS| (one of the |SPECS|'s main interaction models), where each service with its own security clearances. And because any process running on the given |VM| can use any of the privileges that have been granted to that |VM|, it implies that one can not delegate different privileges to different services.
Furthermore this solution works best when the resources, that are the target of |API| calls, belong to the same |AWS| account, therefore cross-account delegation, although not impossible, is pretty difficult to set-up. (Moreover for some services cross-account delegation is not possible.)
STS via delegation service
Despite the limitations of the previous technique, one of the big advantages is the out-of-the-box functionality, in that everything can be achieved only by using native |AWS| services and |API|'s without requiring extra work from the |EU|.
However in order to solve the flexibility limitations, one could leverage |STS| in a software component, which when asked would create a temporary set of credentials and delegate them to the requesting service, which in turn would use them to control the targeted resources. This would allow for example to have a cluster of services that are delegated access to a large number of credentials, not necessarily part of the same |AWS| account.
The way such a solution would work is very similar to our proposed credential service, and therefore does not need to be discussed further.
Discussion
Although |STS| is a very powerful tool when it comes to cloud access delegation, it does have deeper disadvantages that the limitations pretested previously. In what follows we shall highlight some of these disadvantages, which are in play regardless of the variant in which |STS| is used, either via |IAM| roles or via a delegation service.
It must be noted however that in itself, and disregarding the issues presented hereafter, |STS| is practically sufficient, offering much better security than any other existing solution.
However perhaps the greatest disadvantage of |STS| is its lack of interoperability, in that it is useful only when dealing with |Amazon| services. Even though |Amazon|'s |API|, especially the one for |EC2| and |S3|, has been copied by other software vendors, like |Eucalyptus| or |OpenStack|, the |STS| service is unique to |Amazon| and is not available in any other compatible solution.
Putting aside the interoperability issues, and focusing solely on security aspects, there are further limitations which could negatively impact its usefulness. The first issues is related to the time frame in which temporary credentials (potentially leaked by a compromised service) can be used to inflict damage, mainly due to the fact that there is no way to revoke these temporary credentials once issued. Therefore a compromise has to be made between availability and security, because in order to increase the security one needs to decrease the time frame in which these temporary credentials are active, therefore their expiration interval, which in turn requires more frequent temporary credential creation, that in the case the delegation service is down would imply reduced availability.
The second issue is related to how specific the privileges can be for the temporary credentials (or any |AWS| credential for that matter). Although one can assign standard |AWS| policies to further restrict the access of the temporary credentials, they can go only so far as specifying actions to be taken and in some cases coarse rules to match the affected targets. It is however difficult to pin-point access to say only terminate a certain |VM|, or give access only to certain |S3| paths that match a given regular expression.
Nonetheless, even disregarding all of these interoperability and security issues, there still remains the fact that a piece of software has access to credentials, even though temporary and tightly restricted, which can be easily leaked due to a software bug.
GSS-API and SASL
Both |GSS-API| (Generic Security Service |API|) |rfc2743| and |SASL| (Simple Authentication and Security Layer) |rfc4422| are two similar and widely deployed solutions for securing client-server protocols, alleviating the issues of authentication from both protocol designers and implementors. |GSS-API| goes even further by providing message integrity and confidentiality, or even delegation through specific |API|'s; meanwhile |SASL| is used mainly for authentication (sometimes in conjunction with |GSS-API| as an authentication mechanism), although it to provides support for delegation.
All this is achieved by providing a well defined |API| in terms of inputs, outputs and state transitions, that only requires from the protocol the ability to convey certain data back and forth between the two parties, the result being usually authentication of the client party, or possibly mutual authentication of both the client and the server.
Although these two technologies are not used in today's cloud ecosystem, they are good candidates for standard cloud service authentication mechanisms, and their purpose is similar to our proposed credential service, in that both solutions hide the credential management from the application, usually behind a dynamically linked library, but possibly even behind an |RPC|.
Plan9 factotum and secstore services
Perhaps the closest existing solution to our proposed credential service are |Plan9| factotum and secstore services |zoti|, both of which being the main inspiration source for our solution.
In essence the secstore service is tasked only with securely storing secret data, and guarding access permitting only authorized clients, in most likely instances of factotum. The actual storage is achieved by employing cryptographic techniques, namely symmetric key encryption algorithms, which based on a password provided by the human operator at service start-up, allows the secure storage of the secret data over an insecure file-system, either local or remote.
On the other side, factotum implements a series of security protocols that involve the credential data safely managed by secstore, and exposes these protocols to interested clients without exposing the actual credential data, furthermore confining operations to authorized clients only. In functional terms factotum is an equivalent of either |GSS-API| or |SASL|, except that it provides almost infinite extensibility in terms of supported security protocols and operational flexibility in being a service rather than a library.
The main highlight of these two services, something which sets them well apart from either |GSS-API| and |SASL| or any other solution from that matter, is that their interfaces are exposed as |Plan9| file-systems mounted at certain points in the overall file-system hierarchy, therefore all the interaction, including authentication and authorization, being mediated by |Plan9|'s standard file-system access controls. Moreover, based on |Plan9|'s capabilities, namely the |9P| file-system protocol, these interfaces can easily be exported to remote hosts, therefore achieving a fully capable client-server solution.
It must be noted that although technically it would be possible to implement our proposed credential service as an extension to the factotum service, due to the peculiarities of the |Plan9| ecosystem, especially the |9P| file-system protocol, and the nature of cloud services revolving mainly around |HTTP|-based |API|'s, such an undertaking would be far more complex than just building upon these ideas and providing a completely new solution, thus more compatible with the cloud philosophy.
Conclusion
Although we can not assert with 100% certainty that the subject of credential management and delegation to, and by, software agents in a cloud environment has not been addressed by the current scientific literature, we are certain our endeavor is unique, at least in the cloud environment.
We did identify a few solutions, one specifically targeting the topic at hand, namely |STS|, however they are only starting points which offer unique ideas, not solutions we are able to build upon or extend to other cloud services.