cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Min Chen <>
Subject Re: Query String Request Authentication(QSRA) support by S3 providers
Date Tue, 18 Jun 2013 04:39:28 GMT
Hi John,

This is regarding extractTemplate api, where for extractable template, users can click "Download
Template" button from UI to get a http url to download the template already stored at S3 without
providing S3 credentials. In 4.1, we don't have this issue, since the URL returned is the
public web server location hosted in ssvm, and in 4.2, we are returning URL pointing to s3
object. Without setting ACL to the S3 object, user cannot directly click the URL returned
 from extractTemplate api to download the template without providing credentials. By reading
the AWS SDK doc today, I ran across the following API that I may be able to use for this purpose:

bucketName, String<>
key, Date<>
expiration, HttpMethod<>
           Returns a pre-signed URL for accessing an Amazon S3 resource.

This is along the same line as QSRA mentioned by Tom, by wrapped in AmazonS3Client for easy
consumption. By using this method, I think that I don't need to change ACL of S3 object to
open a security hole.


From: John Burwell <<>>
Date: Monday, June 17, 2013 7:38 PM
To: Min Chen <<>>
Cc: Thomas O'Dowd <<>>, "<>"
Subject: Re: Query String Request Authentication(QSRA) support by S3 providers


Why are we mucking with ACLs at all?  The best security practice would be to create a bucket
for CloudStack's use and assign it a dedicated access key and secret key pair with read/write
access only to that bucket.  Requiring an administrative account to an object store opens
an unnecessarily large attack surface.  Therefore, as implemented in 4.1, we should defer
bucket creation, ACL assignment, and credential creation to the administrator/operator.


On Jun 17, 2013, at 1:15 PM, Min Chen <<>>

Tom filed a very good bug for ACL setting change on S3 object when users issue extractTemplate
API (, and his recommendation of using
Query String Request Authentication (QSRA) alternative sounds like a right approach to fix
this bug. Before implementing it, I would like to confirm if QSRA should be supported by all
S3 providers if they claim that they are AWS s3 compatible. If so, we will make this assumption
in our code. Based on Tom, Cloudian is supporting it. How about RiakCS, John?


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message