-2

I am developing a SaaS product for multiple tenants. Each will be able to upload their data to BigQuery via Google Cloud Storage. However, for the users it would only be an "Upload" button on a front end and all the wonders of GCP will be abstracted away from them. Once they have uploaded their huge datasets (5GB for each file) they will be able to view the visualise it using my web-app built in React on that and subsequent logins. For each tenant (separate clients of mine) I would need to create viewer roles to be able to view datasets and creator roles to be able to create datasets for both viewers and creators to see.

Is at all possible? I do not believe service accounts are appropriate here as they would result in everyone having the same authorization (i.e. that of the service account). At the same time I do not want to force customers to have a Google account or as their preference is to use their enterprise domain email and their own passwords. I do not need access to any of their data either, and just want to simply authenticate them and assign a role.

Currently I have a mock-up that uses servcie accounts that works fine. But everyone would ahve the same role once they have logged into my app because the Flask backend just uses a service account with minimal priviledges.

I was thinking of a way to perhaps map a service account to the user type for respective organisations and then that environment variable is set in the Flask app that calls the GCP API's.

This will be on Kubernetes and multi-tenancy will be achieved through completely separate namespaces.

Two examples of a customer journey to illustrate: 1) A customer from client A logins in to my app by typing clientA.webappurl.com - > they have access to create datasets so they upload their vehicle dynamics datasets -> the file is read into a GCS bucket -> file is then uploaded to BigQuery using a schema that has been determined by a Flask backend application I ahve written -> client can then navigate data on a React dashboard employing aggregations to ensure data is within the size of the client browser limits.

2) A customer from client B login in to my app by typing clientB.webappurl.com -> they only have access as a viewer so they can view datasets that have been loaded previously by their dataset creator colleague -> they observe the data, save some png's to a slide pack and then logout of my web app.

Does anyone have any tips of documentation that could help or some use-cases? I am considering dropping GCP altogether because of it, despite it being very impressive.

closed as too broad by Robert Harvey Aug 14 at 14:27

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • I'm not sure I understand what your main problem is. You don't know how to handle authentication/authorization for your users? Based on your description it sounds like the obvious way would be to handle it yourself (as you don't want/need Google accounts or the like to be involved). – Kayaman Aug 14 at 6:56
  • Apologies, I should take a step back. GCP advocates using service accounts between server applications. These are not linked to an actual person as a user, but as the name suggests a service. So when a user logs in to my application and goes through the authentication to my application (which is simple enough), how would I then link that person to IAM policies in GCP as from then on service accounts would be used between my app and GCP. This makes it very difficult to separate users of my app based on privilege level. – TeeJ Aug 14 at 10:07
  • You would use a single service account (with the least amount of privileges that are used by all users) and write access control into your program to prevent users from performing tasks they're not allowed to. Just like when you connect to a database, you have the single database user which is distinct from your (multiple) app users. IAM is not applicable here, since you have "unmanaged" users (and now it's up to you to manage them). – Kayaman Aug 14 at 10:16
  • Perfect, that makes sense. Apologies this is my first GCP project and the whole service accounts concept threw me off. So if this turned into a large application I could then have a number of services each with it's own service account and then simply control who can access the respective services through my app rather than GCP? If that is the case I was definitely over thinking this one. If you write this as an answer I will happily accept. – TeeJ Aug 14 at 10:56
0

User credentials can exist on many different layers of a system, and it can be confusing to know what the relation is between the end user and credentials in other layers (database, queues, other 3rd party integrations).

It's incredibly rare that an end user would have a 1-1 association with users on other layers. Imagine adding a user to your application, the database, and all the other places. Not very handy and not even very useful (for one it would destroy database connection pooling).

The other layers use application specific users which restrict access in some way, but it's still up to application code to provide tight-grained authorization. You might think that it's insecure to have a normal user and a superuser use the same credentials for something, but it's a trade-off between (over)tight security and ease of configuration and use. If your application code has security issues, they need to be fixed there anyway.

For high security projects things are different, since you usually need stricter access control as well as audit data. As this requires extra work, you don't tend to do it "for fun" when it's not needed. The "right amount of security" depends on whether your perceived enemy is a random hacker or let's say a foreign state's intelligence service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.