A veritable eco-system is starting to thrive around cloud infrastructure services such as AWS. Management and monitoring services (RightScale, Ylastic, CloudKick), security services (VPN Cube, Enstratus, Vordel), integration, migration, and deployment services (CloudSwitch, Makara, Elastra). Not to forget about storage solutions. In almost all cases, the services are offered in SaaS mode requiring to pass your access credentials of the cloud infrastructure provider (AWS, Rackspace, Linode) to the service provider that builds on top of it. Two major problems are inherent to service stack model.
- The first problem is a problem of trust. You share your key to access the center of your IT infrastructure, notably to your critical applications and your confidential data with several companies all around the world of which you 1) don’t know how they store and protect your credentials 2) don’t know how long they will exist and to whom they may belong one day. When we launched Cloudy_Scripts, we faced this problem and got the remark: “won’t use your site, only your code”.
- The second problem is related to the first one, but a pure technical one: credential management. You need to change your cloud infrastructure credentials? Don’t forget to log-in to replace the old credentials by the new ones for all your managing, monitoring, security, and deployment services that you use. Otherwise, they simply won’t work anymore.
These are two veritable problems. How can you deal with them? How to solve them? Some suggestions:
Solution 1: Trust Every Service Provider
Actually, that’s not really a solution, but rather ignoring the problem. Even when you fully trust all the service providers you subscribe to, changing the credentials of your cloud infrastructure provider requires you to update those credentials for each and every service.
Solution 2: Wait for Your Cloud Infrastructure Providers Role-based Credentials Support
Imagine your Cloud Infrastructure Provider (CIP) would allow you to generate credentials with limited access (limited in time, limited by location, limited by API calls) that can be given out to our Cloud Added-Service Providers (CASP). You would manage your credentials at a central place and be able to revoke them at any time you want. Even better: your CIP supports a standard protocol that allows to update the credentials for all your CASPs automatically. Dreams are today’s answers to tomorrow’s questions (E.Cayce)
Solution 3: Self-Service
This is a very pragmatic solution (and the one we took for Cloudy_Scripts). Instead of relying on a SaaS provider, run the service yourself within your infrastructure. In the case of Amazon EC2, this means: starting a preconfigured AMI yourself that manages the credentials (see Trusted Gateway pattern). Precondition: the service provider plays the game and delivers his solution as virtual appliance. Don’t know of a management console supporting this mode, but JumpBox and CohesiveFT offer lots of self-service images. Self-service, however, does not address the issue of managing credentials across different services.
Solution 4: Trusted Credentials Broker
Now this is my favorite one. The idea is the same as for solution 2, but the solution is provided by a third party. The broker service could be a proxy that exposes the same API as the CIP does. It knows your security credentials for your CIP (if you don’t want this, then you might want to run the broker yourself like solution 3) and issues security credentials that are then given to the CASPs. The broker/proxy could even do even more useful things in addition to managing credentials and perform access control, e.g. it could provided detailed audit logs and usage information for your cloud infrastructure or accelerate HTTP access and reduce load (and thus costs) on the server by using caching techniques. Link-tip: The idea has been explained and discussed in detail here.
Any other solutions? How is your company dealing with the “crux with the creds”?