Google Cloud Storage: How can I grant an installed application access to only one bucket?

1
votes

I'm developing an application that manipulates data in Google Cloud Storage buckets owned by the user. I would like to set it up so the user can arrange to grant the application access to only one of his or her buckets, for the sake of compartmentalization of damage if the app somehow runs amok (or it is impersonated by a bad actor or whatever).

But I'm more than a bit confused by the documentation around GCS authorization. The docs on OAuth 2.0 authentication show that there are only three choices for scopes: read-only, read-write, and full-control. Does this mean that what I want is impossible, and if I grant access to read/write one bucket I'm granting access to read/write all of my buckets?

What is extra confusing to me is that I don't understand how this all plays in with GCS's notion of projects. It seems like I have to create a project to get a client ID for my app, and the N users also have to create N projects for their buckets. But then it doesn't seem to matter -- the client ID from project A can access the buckets from project B. What are project IDs actually for?

So my questions, in summary:

  1. Can I have my installed app request an access token that is good for only a single bucket?

  2. If not, are there any other ways that developers and/or careful users typically limit access?

  3. If I can't do this, it means the access token has serious security implications. But I don't want to have to ask the user to go generate a new one every time they run the app. What is the typical story for caching the token?

  4. What exactly are project IDs for? Are they relevant to authorization in any way?

I apologize for the scatter-brained question; it reflects what appears to be scatter-brained documentation to me. (Or at least documentation that isn't geared toward the installed application use case.)

4
authorizationgoogle-cloud-storagegoogle-cloud-platform
When you say 'buckets owned by the user', will your application be creating them on users' behalf, or do they already exist (and are owned by the user)? – Travis Hobrla
Also, if you haven't read it already, I recommend reading through cloud.google.com/storage/docs/access-control – Travis Hobrla
They will already exist. But is that relevant? Anyway I've seen the ACL docs, but I don't see how to apply an ACL that includes/excludes particular applications. As far as I can tell, when you give an app an authorization token, it essentially makes the app equivalent to being you for the purpose of ACLs. – jacobsa

4 Answers

3
votes

I had the same problem as you.

Go to : https://console.developers.google.com

  • Go to Credentials and create new Client ID
  • You have to delete the email* in "permissions" of your projet.
  • And add it manually in the ACL of your bucket.

*= the email of the Service Account. [email protected]

0
votes

if you are building an app. It's Server to server OAuth. https://developers.google.com/accounts/docs/OAuth2ServiceAccount

"Can you be clearer about which project I create the client ID on (the developer's project that owns the installed application, or the user's project that own's the bucket)?"

the user's project that own's the bucket It's the user taht own the bucket who grant access.

0
votes

It turns out I'm using the wrong OAuth flow if I want to do this. Thanks to Euca for the inspiration to figure this out.

At the time I asked the question, I was assuming there were multiple projects involved in the Google Developers Console:

  1. One project for me, the developer, that contained generated credentials for an "installed application", with the client ID and (supposed) secret baked into my source code.

  2. One project for each of my users, owning and being billed for a bucket that they were using the application to access.

Instead of using "installed application" credentials, what I did was switch to "service account" credentials, generated by the user in the project that owns their bucket. That allows them to create and download a JSON key file that they can feed to my application, which then uses the JSON Web Tokens flow of OAuth 2.0 (aka "two-legged OAuth") to obtain authorization. The benefits of this are:

  • There is no longer a need for me to have my own project, which was a weird wart in the process.

  • By default, the service account credentials allow my application to access only the buckets owned by the project for which they were generated. If the user has other projects with other buckets, the app cannot access them.

  • But, the service account has an "email address" just like any other user, and can be added to the ACLs for any bucket regardless of project, granting access to that bucket.

0
votes

About your answer.

Glad you solved your problem.

You can also reduce the access to only ONE bucket of the projet. For example, if you have several buckets and the application does not need access to all. By default, the service account has FULL access Read, write and ACL of all buckets. I usually limited to the needed bucket.