|
Discussion Forums
|
Thread: Best Practice for securing Access Key ID/Secret Key
 |
This question is not answered.
Helpful answers available: 2.
Correct answers available: 1.
|
|
|
|
Replies:
14
-
Pages:
1
-
Last Post:
Apr 22, 2008 8:02 AM
by: stuart_jenkins
|
|
|
Posts:
77
Registered:
5/5/06
|
|
|
|
Best Practice for securing Access Key ID/Secret Key
Posted:
Apr 20, 2008 2:32 PM PDT
|
|
|
Hi
The concept that the secret key is kept, well secret; is fine. However if you are working - lets say in a company where you are creating (internal) applications that use EC2/S3/SQS etc etc then multiple people need to know/have access to the secret key for support purposes.
I just wondered how other people are "managing" access to their key/dealing with the inherent issues of mis-use/people leaving the company etc etc.
Thanks in advance.
Stuart
|
|
Posts:
2,715
Registered:
5/25/06
|
|
|
|
Re: Best Practice for securing Access Key ID/Secret Key
Posted:
Apr 20, 2008 4:24 PM PDT
in response to: stuart_jenkins
|
|
|
You're developers really need access, so you can't really get around that.
- keep an eye on your usage reports, billing statements
- if people leave, or you suspect mis-use, generate a new secret key, which replaces the old one
- don't put your access id or secret key on your AMIs, just pass that as instance data.
David
|
|
Posts:
5,320
Registered:
3/19/07
|
|
|
|
Re: Best Practice for securing Access Key ID/Secret Key
Posted:
Apr 20, 2008 5:27 PM PDT
in response to: D. Kavanagh
|
|
|
It would be possible to implement an in-house web service that essentially signed and proxied requests for validated users.
|
|
Posts:
77
Registered:
5/5/06
|
|
|
|
Re: Best Practice for securing Access Key ID/Secret Key
Posted:
Apr 21, 2008 5:29 AM PDT
in response to: D. Kavanagh
|
|
|
Hi David
With regard to:
- don't put your access id or secret key on your AMIs, just pass that as instance data.
are you talking about Parameterised Launches?
Cheers
|
|
Posts:
278
Registered:
4/10/06
|
|
|
|
Re: Best Practice for securing Access Key ID/Secret Key
Posted:
Apr 21, 2008 9:48 AM PDT
in response to: D. Kavanagh
|
|
|
> You're [sic] developers really need access, so you
> can't really get around that.
Why do developers need access to a production account? I have 3 different AWS accounts -- two for development purposes, one for production use -- even though I'm the only person who uses any of them, since this allows me to use development keys for development purposes while only bringing out (and decrypting) the production keys when I'm actually going to need them.
|
|
Posts:
77
Registered:
5/5/06
|
|
|
|
Re: Best Practice for securing Access Key ID/Secret Key
Posted:
Apr 21, 2008 9:53 AM PDT
in response to: Colin Percival
|
|
|
while only bringing out (and decrypting) the production keys when I'm actually going to need them
Q. How are you storing/using the production keys at runtime?
Could you elaborate?
Thanks
|
|
Posts:
2,715
Registered:
5/25/06
|
|
|
|
Re: Best Practice for securing Access Key ID/Secret Key
Posted:
Apr 21, 2008 7:33 PM PDT
in response to: stuart_jenkins
|
|
|
Yes, I am talking about parameterized launches. That was one of the best features they put in early on.
WRT Colin's comment, yes, separate accounts is a good idea. Works even better once you parameterize your AMI's! :-)
David
|
|
Posts:
77
Registered:
5/5/06
|
|
|
|
Re: Best Practice for securing Access Key ID/Secret Key
Posted:
Apr 22, 2008 4:20 AM PDT
in response to: D. Kavanagh
|
|
|
So your scripts etc query the web server inherently on 169.254.169.254 and get the "key" for example - and utilise it at run time - but never actually exist in the script....
Performance hit?
|
|
Posts:
2,027
Registered:
3/15/06
|
|
|
|
Re: Best Practice for securing Access Key ID/Secret Key
Posted:
Apr 22, 2008 4:30 AM PDT
in response to: stuart_jenkins
|
|
|
The parameterization of launches is an incredibly handy feature and has been very useful in allow for more flexibility in our AMI's. However, I think it's wrong to think of it as being "more secure" in any way. The main threat you are trying to protect yourself from is a hacker gaining access to your running instance and, in doing so, gaining access to your AWS credentials and passing the credentials at launch doesn't help protect you in any way from that threat.
The only threat it does protect you against is someone gaining access to the stored AMI image and finding the credentials within that image but given that the images stored in S3 are already encrypted and protected by ACL's, that seems pretty remote.
Mitch
|
|
Posts:
77
Registered:
5/5/06
|
|
|
|
Re: Best Practice for securing Access Key ID/Secret Key
Posted:
Apr 22, 2008 4:47 AM PDT
in response to: M. Garnaat
|
|
|
Thanks Mitch
So how are you dealling with key management on your running AMIs? i.e. when they need to get info from S3
Stuart
|
|
Posts:
2,027
Registered:
3/15/06
|
|
|
|
Re: Best Practice for securing Access Key ID/Secret Key
Posted:
Apr 22, 2008 7:11 AM PDT
in response to: stuart_jenkins
|
|
|
So how are you dealling with key management on your running AMIs? i.e. when they need to get info from S3
I'm afraid I haven't figured out any foolproof scheme yet. We have AWS credentials for each developer on our team and a separate set of "production" credentials. I agree that's a good idea and well worth doing.
The difficulty arises when you have code running on production boxes that wants to use other Amazon services. For example, let's say you have a cron job running on your production boxes that copies information from the instance to a bucket in S3. So, you need to have some set of credentials on that instance with sufficient rights (WRITE at least) to the bucket to store the information. The problem is that now you have credentials sitting on that box that would also allow a hacker to delete every object in the bucket. Gack! Granted (no pun intended) you could disallow READ on the bucket so they couldn't list the contents but they could still do irretrievable damage.
The situation is actually worse when using SQS or SDB because there are no grants at all so whatever credentials you put on the instance will have complete access to everything associated with that account. Double Gack!
One workaround would be to not have any AWS credentials on the box but have each instance talk to a web service you create that would produce signed requests that could be used for access to other services. The two main problems with that are 1) you have to try to make that service as reliable as AWS which would be very hard indeed and 2) it won't really work for other services because they don't fully support the signed query string authentication scheme that S3 supports.
Maybe I'm missing something but I've been pondering this for a long time and have yet to think of a really good solution. It's my single biggest gripe with AWS.
Mitch
|
|
Posts:
77
Registered:
5/5/06
|
|
|
|
Re: Best Practice for securing Access Key ID/Secret Key
Posted:
Apr 22, 2008 7:25 AM PDT
in response to: M. Garnaat
|
|
|
Thanks for a informative post Mitch
It sounds like a feature request to Amazon then.....
Please let us create "sub-accounts" with their own access key/secret key with defined rights (perhaps by service and Read/ Write ability?) ....
Thoughts any one?
|
|
Posts:
633
Registered:
3/24/06
|
|
|
|
Re: Best Practice for securing Access Key ID/Secret Key
Posted:
Apr 22, 2008 7:46 AM PDT
in response to: stuart_jenkins
|
|
|
Providing EC2 "sub-accounts" was actually the original motivation for creating the RightScale dashboard for EC2. I was teaching a graduate course in the fall of '06 and had one account for 30 students. You can sign-up for a free developer account and enter the credentials. After that, you can invite others to your account and they can't access the credentials unless you give them admin privileges.
Thorsten - www.rightscale.com
|
|
Posts:
2,027
Registered:
3/15/06
|
|
|
|
Re: Best Practice for securing Access Key ID/Secret Key
Posted:
Apr 22, 2008 7:49 AM PDT
in response to: stuart_jenkins
|
|
|
I think at least some of my problems could be addressed by restricting the ability to delete or overwrite content in AWS. This could be done either by setting some bit on the container object (I've written about WriteOnce buckets before) or it could be done via a new permission that could be granted.
If all of my servers were running in a conventional data center, someone hacking into one of my servers would be bad but could be contained. In AWS, if you have credentials available on running instances, hacking the server can be like gaining physical access to my data center and the potential risk is much higher. I think we need better tools to mitigate those risks.
Mitch
|
|
Posts:
77
Registered:
5/5/06
|
|
|
|
Re: Best Practice for securing Access Key ID/Secret Key
Posted:
Apr 22, 2008 8:02 AM PDT
in response to: Thorsten von Ei...
|
|
|
Hi Thorsten
But under RightScale customers have to "give" you their keys.
Forgive me but thats the issue I am trying to control - I'm going to look at what you offer in more detail as I am sure the work you have already done will help shortcut development/management processes - but I would still be
worried
that I have given my keys away.
As Mitch says - they're the crown jewels - the key to the data center.
Stuart
|
|
|
|
Sign in to the AWS Management Console
Create an AWS Account
