Cloud CDN signed url V.S. Cloud Storage signed url?

2
votes

Cloud Storage signed url doc: https://cloud.google.com/storage/docs/access-control/signed-urls

Cloud CDN signed url doc: https://cloud.google.com/cdn/docs/using-signed-urls

What's the difference between them? I am confused which one should I use.

Here is my case:

I want to make my bucket and objects from the public to not public which means I will remove allUsers member from the permissions.

I am looking for a way that the users of my application can access the objects (images, media) with some authentication. Otherwise, all users on the internet will access my bucket and objects. The users don't need to have Google accounts, so I think IAM and ACL are not the correct ways.

I am not sure cloud storage signed url is the correct way. And there is another issue is I already stored many URLs in my database with cloud storage object public url like this:

https://storage.googleapis.com/ez2on/1536250853638-NN.jpg

When a client(Front-End) try to access this data, how should I do to generate signed url for these old data in my backend?

Thanks for your advice.

1
google-cloud-platformgoogle-cloud-storage

1 Answers

4
votes

About signed URLs, internally they work approximately the same, and generate the URL more or less in the same way. Cloud Storage has a built-in CDN, so using Cloud Storage signed URL is enough.

With signed URL you don't need to whitelist users, you only send them the URL and they have access to it for a limited time.

For your use case signed URLs might not be the best option as they have a limited lifetime, so what I suggest is to make your users log in to your app with the app's own logic, not IAM, or just access the app without login (if it is not essential to log in), and then make the app handle the users' requests to Cloud Storage objects through a service account (IAM):

  1. user (non-Google/Google) logs in to the app (app login, not IAM)

  2. user requests an object presented by the app without internal data (bucket's path, etc.)

  3. app uses its own service account (IAM) to request the object to Cloud Storage

  4. Cloud Storage passes the object to app, app to user

Using this service account workaround you can still use the URLs saved in your database. If you would like to use the signed URL you should modify the database constantly, which is not the optimum.

You can use this to authenticate from your app to Cloud Storage, limiting the access to only your app's service account. You can set the service account implicitly or explicitly.