You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Thomas O'Dowd <tp...@cloudian.com> on 2013/07/03 08:51:39 UTC
S3 Object Storage - secret key handling
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
Tom.
--
Cloudian KK - http://www.cloudian.com/get-started.html
Fancy 100TB of full featured S3 Storage?
Checkout the Cloudian® Community Edition!
Re: S3 object store - extract image (template/volume/iso)
Posted by John Burwell <jb...@basho.com>.
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 <Pr...@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.,
Re: S3 object store - extract image (template/volume/iso)
Posted by Prasanna Santhanam <pr...@citrix.com>.
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.,
Re: S3 object store - extract image (template/volume/iso)
Posted by Thomas O'Dowd <tp...@cloudian.com>.
Hi Prasanna,
See inline below.
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).
> 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.
Hope that helps,
Tom.
[1] http://aws.amazon.com/articles/5050/
[2] http://docs.aws.amazon.com/AmazonS3/2006-03-01/dev/RESTAuthentication.html#RESTAuthenticationQueryStringAuth
--
Cloudian KK - http://www.cloudian.com/get-started.html
Fancy 100TB of full featured S3 Storage?
Checkout the Cloudian® Community Edition!
S3 object store - extract image (template/volume/iso)
Posted by Prasanna Santhanam <pr...@citrix.com>.
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?
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?
[1] http://aws.amazon.com/articles/5050/
--
Prasanna.,
Re: S3 Object Storage - secret key handling
Posted by Tom O'Dowd <tp...@cloudian.com>.
Hi Min,
I'm not familiar with all the use cases of Cloudstack so let me just ask
anyway... If you create another user as an admin can that user see the S3
secret key? Is there is any use case where another admin should not see the
secret key then I think we should hide it. If not, then I guess its ok to
leave it.
Tom.
On Thu, Jul 4, 2013 at 10:09 AM, Min Chen <mi...@citrix.com> wrote:
> Tom, on second thought, I don't think that this is an issue at all. This
> Infrastructure page UI is only available to cloud admin, who is the person
> who set up S3 secondary storage, so he/she already knows S3 secret key.
> Hiding or not hiding it will make no difference. This UI will not be
> visible to end users, so should not expose security issue.
>
> Thanks
> -min
>
> On 7/2/13 11:51 PM, "Thomas O'Dowd" <tp...@cloudian.com> 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
> >
> >Tom.
> >--
> >Cloudian KK - http://www.cloudian.com/get-started.html
> >Fancy 100TB of full featured S3 Storage?
> >Checkout the Cloudian® Community Edition!
> >
>
>
Re: S3 Object Storage - secret key handling
Posted by Min Chen <mi...@citrix.com>.
Thanks Tom for reporting this. Jessica, can you take a look at this bug to
hide it from UI, in the similar manner as we handle password field?
-min
On 7/2/13 11:51 PM, "Thomas O'Dowd" <tp...@cloudian.com> 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
>
>Tom.
>--
>Cloudian KK - http://www.cloudian.com/get-started.html
>Fancy 100TB of full featured S3 Storage?
>Checkout the Cloudian® Community Edition!
>
Re: S3 Object Storage - secret key handling
Posted by John Burwell <jb...@basho.com>.
Min,
+1. In my opinion, masking the secret key will only make debugging and diagnostics more difficult. From a security perspective, CloudStack administrators/operators should be creating a dedicated CloudStack access key/secret key with a read/write ACL only for the bucket used by the system. This approach is a best practice recommended by Amazon for circumstances when a a credential set will be used by an automated system such as CloudStack. If the credentials are compromised, the impact of revocation is minimized and the access gained by an attacker is greatly limited.
Thanks,
-John
On Jul 3, 2013, at 9:09 PM, Min Chen <mi...@citrix.com> wrote:
> Tom, on second thought, I don't think that this is an issue at all. This
> Infrastructure page UI is only available to cloud admin, who is the person
> who set up S3 secondary storage, so he/she already knows S3 secret key.
> Hiding or not hiding it will make no difference. This UI will not be
> visible to end users, so should not expose security issue.
>
> Thanks
> -min
>
> On 7/2/13 11:51 PM, "Thomas O'Dowd" <tp...@cloudian.com> 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
>>
>> Tom.
>> --
>> Cloudian KK - http://www.cloudian.com/get-started.html
>> Fancy 100TB of full featured S3 Storage?
>> Checkout the Cloudian® Community Edition!
>>
>
Re: S3 Object Storage - secret key handling
Posted by Min Chen <mi...@citrix.com>.
Tom, on second thought, I don't think that this is an issue at all. This
Infrastructure page UI is only available to cloud admin, who is the person
who set up S3 secondary storage, so he/she already knows S3 secret key.
Hiding or not hiding it will make no difference. This UI will not be
visible to end users, so should not expose security issue.
Thanks
-min
On 7/2/13 11:51 PM, "Thomas O'Dowd" <tp...@cloudian.com> 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
>
>Tom.
>--
>Cloudian KK - http://www.cloudian.com/get-started.html
>Fancy 100TB of full featured S3 Storage?
>Checkout the Cloudian® Community Edition!
>