Multi-tenant SaaS using GCP as back-end data store and compute engine [closed]

Question

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.

Answer 1

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.