cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Min Chen <min.c...@citrix.com>
Subject Re: Query String Request Authentication(QSRA) support by S3 providers
Date Tue, 18 Jun 2013 19:55:08 GMT
John,
	In that case, how do we keep backward compatibility of extractTemplate
api, which requires a URL in the response?

	Thanks
	-min

On 6/18/13 11:53 AM, "John Burwell" <jburwell@basho.com> wrote:

>Min,
>
>Looking through the code, I think we can simplify driver operation and
>increase robustness by changing ImageStoreDriver#createEntityExtractUrl()
>: String to ImageStoreDriver#readEntity(Š) : InputStream.  My first
>concern with the current implementation is that it circumvents any
>connection pooling/resource management underlying client libraries
>provide.  I/O streams provide a higher-level abstraction that allows
>drivers to provide the orchestration components with actual resources
>rather String references.  Second, the current interface seems to appears
>to assume that an http/https URL will be returned.  With I/O streams, we
>can support any client library capable of using the standard I/O
>framework -- enabling us to support other protocols for downloading
>templates in the future (e.g. RBD, local filesystem, NBD, etc).
>
>Thanks,
>-John
>
>On Jun 18, 2013, at 1:11 PM, Min Chen <min.chen@citrix.com> wrote:
>
>> A new version of using generatePresignedUrl in S3ImageStoreDriverImpl is
>> checked into object_store.
>> 
>> THanks
>> -min
>> 
>> On 6/18/13 8:29 AM, "Min Chen" <min.chen@citrix.com> wrote:
>> 
>>> Yes, current code is in S3ImageStoreDriverImpl.createEntityExtractUrl,
>>> which has a security issue mentioned in CLOUDSTACK-3030. I am going to
>>> change it to use generatePresignedUrl api from AWS S3 api.
>>> 
>>> Thanks
>>> -min
>>> 
>>> From: John Burwell <jburwell@basho.com<mailto:jburwell@basho.com>>
>>> Date: Tuesday, June 18, 2013 8:07 AM
>>> To: Min Chen <min.chen@citrix.com<mailto:min.chen@citrix.com>>
>>> Cc: Thomas O'Dowd <tpodowd@cloudian.com<mailto:tpodowd@cloudian.com>>,
>>> "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>"
>>> <dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>>
>>> Subject: Re: Query String Request Authentication(QSRA) support by S3
>>> providers
>>> 
>>> Min,
>>> 
>>> Is the code checked into the object_store branch?  If so, which lines
>>>in
>>> S3TemplateDownloader?
>>> 
>>> Thanks,
>>> -John
>>> 
>>> On Jun 18, 2013, at 12:39 AM, Min Chen
>>> <min.chen@citrix.com<mailto:min.chen@citrix.com>> 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<http://java.sun.com/j2se/1.5.0/docs/api/java/net/URL.html?is-externa
>>>l=
>>> true>        
>>> 
>>>generatePresignedUrl<http://docs.aws.amazon.com/AWSJavaSDK/latest/javado
>>>c/
>>> 
>>>com/amazonaws/services/s3/AmazonS3Client.html#generatePresignedUrl%28jav
>>>a.
>>> 
>>>lang.String,%20java.lang.String,%20java.util.Date,%20com.amazonaws.HttpM
>>>et
>>> 
>>>hod%29>(String<http://java.sun.com/j2se/1.5.0/docs/api/java/lang/String.
>>>ht
>>> ml?is-external=true> bucketName,
>>> 
>>>String<http://java.sun.com/j2se/1.5.0/docs/api/java/lang/String.html?is-
>>>ex
>>> ternal=true> key,
>>> 
>>>Date<http://java.sun.com/j2se/1.5.0/docs/api/java/util/Date.html?is-exte
>>>rn
>>> al=true> expiration,
>>> 
>>>HttpMethod<http://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amaz
>>>on
>>> aws/HttpMethod.html> 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 <jburwell@basho.com<mailto:jburwell@basho.com>>
>>> Date: Monday, June 17, 2013 7:38 PM
>>> To: Min Chen <min.chen@citrix.com<mailto:min.chen@citrix.com>>
>>> Cc: Thomas O'Dowd <tpodowd@cloudian.com<mailto:tpodowd@cloudian.com>>,
>>> "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>"
>>> <dev@cloudstack.apache.org<mailto: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.chen@citrix.com<mailto:min.chen@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
>>> 
>>> 
>> 
>


Mime
View raw message