Re: [gs-discussion] Some security questions

[Navneet (Google)]

Hi Boyan,

Sorry for the delay in responding. 

1) Getting a write-only token for a service account

Unfortunately, we don't have write-only ACLs.

2) Getting a token for a service account which is NOT able to list all buckets in the project (what I tried was create a couple of buckets with a "private" ACL and requested a read only token by a service account which was not a project owner - all of the buckets were visible)

This should be doable. Create two projects - one (A) which owns the buckets, and the other (B) is the accessor. Create a service account under B (ServiceAcctB). Now, have an Owner in A add ServiceAcctB to ACLs of the buckets in B with either WRITE or FULL_CONTROL permission (depending on what permissions the service account needs).

ServiceAcctB will be able to list the contents of every bucket, but will not be able to list all the buckets (only owners of A can list the buckets).

3) Being able to use a custom user store and get OAuth tokens for GCS for those users

Not sure what you mean here, so my answer may not be what you're looking for. Your users will have to have Google Accounts. If you have a Google Apps account, you could create email addresses for them and mint tokens for each user using a service account (see the Signed JWT documentation). However, you'd be paying a fee for every user you add under Apps.

Finally, while Signed URLs are experimental, they've been pretty stable and we do intend to continue to support them. We don't have any current plans to make backwards-incompatible changes to them either, and if we do need to, we generally give a heads-up via gs-announce in advance.

Regards,

Navneet

 

On Wed, Sep 26, 2012 at 4:54 AM, Boyan <boyan...@gmail.com> wrote:

Hello,

I am currently evaluating using GCS for a project, and I have some questions regarding some security scenarios.
The general requirements of the project are that a part of the application deployed at the customer site would regularly upload some files to the cloud storage. It is necessary that the data uploaded by one customer is NOT visible or accessible by another customer. Now, I came up with following possibilites:
1) Each customer is identified by their google id, and uploads to a bucket only he has permissions for. The downside of this is that not every customer might have a google account, and, according to my understanding, the customer would have to authorize the application doing the upload manually at least once.
2) A service account is used to do the upload on behalf of the customer. Unfortunately, it isn't possible that every customer use a separate service account (as they are limited to 7), so let's say there will be at least 2 customers using the same service account. As the application needs only to upload, a write only token would ensure that the service account cannot list data uploaded by another customer, but it seems that it's impossible to request a write only token. (If we grant it a read-write token, it would be able to list all buckets, and if another customer is uploading at the same time, list and delete the other customer's data).
3) Use signed URLs to grant temporary access to upload in a bucket (if that's possible, haven't tried it); This seems attractive, but it says that the signed URLs feature is currently experimental, which means some possible breakages if some backward-incompatible changes are made.

Basically what would be secure enough is:
1) Getting a write-only token for a service account
2) Getting a token for a service account which is NOT able to list all buckets in the project (what I tried was create a couple of buckets with a "private" ACL and requested a read only token by a service account which was not a project owner - all of the buckets were visible)
3) Being able to use a custom user store and get OAuth tokens for GCS for those users

Is any of these possible?

Thanks

--
 
 

[Boyan]

Alright, thanks a lot! I'll give the things you pointed out a try. I realize that the signed URLs feature is probably quite stable, but I was looking for a fail-safer(-ish) option.

Regards