Prasanna, To take things a step further, we should be advising admins to create unprivileged S3 accounts. CloudStack does not need to be manipulating ACLs or other administrative features. Therefore, we should add documentation to advise users that to limit the impact of a credential exposure, they should create a dedicated credential set with access to only the CloudStack associated bucket.
Thanks, -John On Jul 3, 2013, at 5:45 AM, Prasanna Santhanam <prasanna.santha...@citrix.com> wrote: > On Wed, Jul 03, 2013 at 04:38:35PM +0900, Thomas O'Dowd wrote: >> Hi Prasanna, >> >> On Wed, 2013-07-03 at 12:35 +0530, Prasanna Santhanam wrote: >>> On Wed, Jul 03, 2013 at 03:51:39PM +0900, Thomas O'Dowd wrote: >>>> Hi guys, >>>> >>>> I created a bug regarding the handling of the S3 secret key information. >>>> My opinion is that it should be treated more carefully like a password >>>> and not displayed in the UI at least. >>>> >>>> https://issues.apache.org/jira/browse/CLOUDSTACK-3342 >>>> >>> >>> Had a related question filed in CLOUDSTACK-3323 by Sanjeev >>> - >>> >>> The bucket permissions when a store is added by the admin to >>> cloudstack needs to be set to something specific? Or will all objects >>> put into the store have public read access? Is this something to be >>> documented prior to setting up objectstore? >> >> Cloudstack as far as I can see does not change the bucket permissions in >> any way. The owner of the bucket can leave it as the default permission >> which is usually private to that owner. To put/upload objects in that >> bucket cloudstack needs an access key (AK) and secret key (SK) pair for >> the S3 user and bucket owner.The cloudstack admin must know the AK&SK >> pair when the S3 Object store is first added as secondary storage. >> >> When Cloudstack uploads objects to the object store, they are all left >> private by default. No public access. I think this is correct. >> Cloudstack has full access because it has the AK&SK pair (assuming the >> AK&SK pair belong to the bucket owner). > > Great! This is what I was looking for. Thanks for explaining. >> >>> AWS supports rich ACLs on its object store. So do other object store >>> solutions [1] >>> >>> In relation to this - I want to understand the HTTP download link >>> exposed when I click on download image (volume/template/iso). The link >>> has the access key in its url path. Is this okay in terms of security? >> >> Yes its ok security wise. This link uses query string authentication [2] >> The AK is needed to identify the S3 user to the Object Store (AWS, >> Cloudian, Riak, etc). The request is made up of the method 'GET', the >> URI and a timestamp when the request expires. All of this is then signed >> using the SK and the result is the signature query parameter. The >> specific URL allows any user with that URL access to GET that particular >> object as that user for a limited period of time. In the current case, >> the URL is valid for 1 hour. There is no server-side cost to these URLs. >> > > Understood. This makes it clear. I guess the bucket permissions are > not of much use to cloudstack in that case for the standard image > store use. > > Thanks, > > -- > Prasanna.,
