As I mentioned in earlier post, I’m experimenting with AWS DevPay. In this post I’m going to share about a small trick I employed to ensure safety of end user’s API( secret) keys.
AWS uses a public-key/secret-key shared secret mechanism to authenticate each API call to AWS. Since most calls to AWS are metered and billed to the key owner, the keys are same as money. Hence it is a good idea to address the key protection issue at design time.
In the Sim-OnDemand application, a few AWS api calls are to be made to initialize and attach/gracefully detach the Elastic Block Store volume. My initial design was to pass on the keys as User Data to LaunchInstances API call, and use the keys to make AWS calls to heart’s content. There is one problem though, the keys will be available for anyone that has access to the running instance. The availability of keys as plain text will be enough incentive for attackers to break into the system. There is also the risk of the next packager or the AMI not taking enough safety measures and thereby inadvertently increasing the key safety risk.
The present implementation of Sim-OnDemand‘s new-improved design is to eliminate the key passing to the instance all-together. A launcher application to compliment the AMI is developed and it does the API calls on behalf of the EC2 instance. The launcher application runs locally on the AMI user’s computer, thus keys are not exposed to the big bad world.
When the instance needs to make an API call, a pre-signed REST call url is computed by the launcher application and passed on to the instance rather than passing the keys.
If you are keen to look at the code it is opensourced and available at google code.
This approach is not too generic. What is needed is an API, protocol to pass such information/control instructions to the instance. Looks like an interesting challenge to pursue.