Hi Min, Yes. generatePresignedURL() implements the QSRA that I mentioned. This should be secure if you use reasonable dates and enables you to keep the object private. The content-type of the template object that will be sent to the client when downloaded will be whatever you set in S3 when you uploaded the template initially (See issue: https://issues.apache.org/jira/browse/CLOUDSTACK-3027)
Tom. On Tue, 2013-06-18 at 04:39 +0000, Min Chen wrote: > 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: > > > URL > generatePresignedUrl(String bucketName, String key, Date expiration, > HttpMethod method) > 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. > > > Thanks > -min > > > From: John Burwell <jburw...@basho.com> > Date: Monday, June 17, 2013 7:38 PM > To: Min Chen <min.c...@citrix.com> > Cc: Thomas O'Dowd <tpod...@cloudian.com>, "dev@cloudstack.apache.org" > <dev@cloudstack.apache.org> > Subject: Re: Query String Request Authentication(QSRA) support by S3 > providers > > > > Min, > > > 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. > > > Thanks, > -John > > > On Jun 17, 2013, at 1:15 PM, Min Chen <min.c...@citrix.com> wrote: > > > > Tom filed a very good bug for ACL setting change on S3 object when > > users issue extractTemplate API > > (https://issues.apache.org/jira/browse/CLOUDSTACK-3030), 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? > > > > > > Thanks > > -min > > > > -- Cloudian KK - http://www.cloudian.com/get-started.html Fancy 100TB of full featured S3 Storage? Checkout the Cloudian® Community Edition!
