[miravmehta]

Sure, here are the corrected sentences:

1. RBAC Policy When there are multiple types of roles in a parent-tenant (pt) and child-tenant (ct), there could be cases where some resources can be shared between pt and ct, while others cannot. Hence, conditions to access these data are not limited to RBAC, but also depend on the type of data and metadata. Checks are applied on metadata.

2. Architecting Multi-Tenant A significant challenge would be in schema design, especially the isolation of pt and ct. There are open-source solutions available that provide pre-cooked solutions, yet they may not be as effective as writing your own.

3. RBAC can go beyond ABAC and REBAC This is an advanced problem. Customers in the cloud-native space have demanded this before as it provides granularity. This is heavily backed by your RBAC architecture. If that's implemented incorrectly, then your ABAC and REBAC will also be affected.

[barnabas-szoke]

Thanks for your answer.

1. I am not familiar with the parent-child tenant relationship in auth. Could you elaborate on that? Is it like some sort of logical relationship between a holding company and subsidiaries or maybe different cost centers in an organization?

2. I agree. Managing the schema changes in a siloed multi-tenant platform can be a nightmare. I would be keen the have a look at those open-source pre-cooked solutions.

Based on your response it sounds like you wanted to design/build a custom auth solution. May I ask what was the main motivation? Did you have any other pain points with the current offerings?

[miravmehta]

[1] MSP is the term for this. Managed Service Provider Lets say my company has a SaaS product. AT&T is the customer to my company and i onboard them to my SaaS platform, now AT&T has a customer called "Dell" and AT&T wants to onboard Dell to this platform ; Essentially white-labelling

Parent- AT&T Child - AT&T

[2] We have SaaS platform build like Backstage, Vmware Tanzu. We didn't wanted to build custom auth solution, this was a demand from customers who wanted granularity not just based on CRUD operations but based on environments, access to type of metadata, projects, other app-services

We had something called soft-multi-tenancy, where user "abc" can access namespace in k8s in cluster B, but not cluster A; because B (child) is inherited cluster from A (parent)

Examples of RBAC granularity

1. Write access to Namespace (can change, Namespace, pods, deployment and more .. based on k8s first class object) 2. Read access to Namespace 3. Write access to Pods 4. Read access to Pods

Just like this we had close to 20 RBAC granularity

I recommend you reading about RBAC, ABAC, RE-BAC, Soft Multi-tenancy ; companies who are building this loft.sh, rancher. Our solution was not focused RBAC at all, when we bough multi-tenancy it enforced us think through RBAC