does anyone have any references to GCP-recommended best-practices for SaaS services that set up multi-tenant authentication where they have a GSA that is being granted permissions directly or via a role assumption in to the customer GCP account? e.g., I’m specifically looking for information where the advice to isolate the SA on the SaaS-side might be a recommendation if you were say using it for something highly permissive, e.g., if you were a SaaS that had permissions to create and deleted VMs in my GCP account.
I think a custom role is the way to go here. Just create a role in the destination project with the permissions you want and assign it to the service account from the SaaS project.
I’m more specifically talkinga bout the GSAs than the roles – I’m not disputing that they will have X permissions in my account. I’m asking if GCP has a recommendation for SaaS providers on how they should be provisioning and isolating tenants in terms of their GSAs that they use for this purpose.
actually more or less this, but in less blog form I was hoping maybe and more of a solid GCP actual recommendation?.. https://www.googlecloudcommunity.com/gc/Community-Blogs/A-compartmentalized-multi-tenant-architecture-for-SaaS/ba-p/811386 …but maybe this is it. it came from google.
These 3 bullet points essentially summarize what I’m trying to have a recommendation of:
Dedicated Access Control (Gray box in the middle) - we would recommend to use dedicated service account(s) for each customer and manage it centrally to ensure consistency in IAM operations.
Runtime Environment Separation for Applications (boxes on the left) - One of the key objectives is to build a separation mechanism to isolate application workload for different customers. Depending on the choice of services for application runtime, there are different ways to implement application separation.```and more specifically this line ‘Service account accessing across customer tenants must be strictly prohibited.’ – I’d really like to be able to tell a GCP partner that manages GCP resources in customer tenants’ that they’ve violated that most basic principle – they’re asking all tenant customers to allow the same shared GSA in their account admin level access to compute engine and multiple services, for example. It seems like a gross violation. They may be enforcing one customer from using another customer’s project i.d. in their code or service somewhere, but not at the cloud resource level
Sorry I took GSA to mean “google service account” but can you clarify what the acronym stands for?
not only do the permissions apply from the same GSA across customer tenants, the actual customer tenants in this case isn’t even the tenant in the sense of a project in their account, it’s my gcp organization and it’s all other GCP organizations that are customers that have the same shared permission
GSA did mean google service account. that is what I meant
in the above diagram, imagine if there was no “SA(s) for customer 1” or “SA(s) for customer 2” but the same SA is shared and has access to all customer gcp organizations
if this were AWS it would be solved in most cases by using a shared user or role, but then in the actual IAM policy, an sts:externalId that is itself just a a randomly generated guid (generated always by the saas, never changeable by customer) and that’s how you get the security of a shared account, but GCP has no such thing
You can apply a role or permission to a principal, regardless of where it is. For instance if you want one service account across all the GCP projects that has access to do stuff, create it, then in the destination projects, create roles and apply it to the service account principal email address?
When the principal (in this case a service account) goes to do something in a project it’s action is validated against IAM, and if there’s a role/permission which matches what it’s trying to do, it will allow it.
I’m not sure I’m understanding your problem correctly though.
That wasn’t my concern
I’m asking from the perspective of isolating tenants and the security of isolating the permissions per tenant to their own principal
Yeah, I would completely agree that using a single service account is a bad idea.
When you say:
if you were a SaaS that had permissions to create and deleted VMs in my GCP account.
Do you mean GCP project?
I’ve seen it a few times where a SaaS provider needs to access things in a customer project (or projects), for example logs. The process I’ve seen is that the SaaS provider will generate a service account for that task, and then the onus is on the customer (owner of the project where logs are generated) to create a role with the required permissions and assign a binding to the principal (generated service account) so that it can read logs.
It is up to the customer to manage the access that the service account has from the SaaS provider though.
I’m not sure if there’s any Google-provided recommendations on this though, if that’s what you need. 
Yes – it is at the project-level, not org-level, but essentially they get granted computeAdmin and a few other admin roles in each project-- as a SaaS, they use the same service account for not only all projects, but all dispirate customers. like it’s documented in their online documents to give xyz@foogooglewhateverproject.googlewhatever computeAdmin etc./not dynamically created in any wy per customer or project. We have no control over how they set up that SA.
