How do we want to do RBAC for Dev portal users in console plugin?

[R-Lawton]

The purpose of this discussion is to decide on how we want to go about the permissions for the users/personas of the new dev portal in OCP. The main question we need to answer is whether we predefine the users' RBAC for them and they can map to existing roles, or do we give examples/recommendations of what each persona is from our opinion, with the exception of what RBAC has to be there for the views to work as intended.

To kick off the discussion, I would be in favour of the latter. I don't think we should predefine the roles and try to map them. It keeps in line with the console plugin already, and it saves us the headache of trying to think of all the scenarios potential users may have and also avoids certain users not being able to use it because it doesn't fit their system. What are yer thoughts?

Im also thinking we ustilse the perspectives that you can do with OCP so currently we have core platform and dev platform but you can create custom ones.

[eguzki]

Regarding the pre-defined roles topic, I don't have a strong opinion. In either case, we need to provide a way to assign users to roles, specifically developer portal roles, not OpenShift RBAC role resources. This assignment mechanism is what we need to build on top of the existing RBAC system. Ultimately, we need developer portal roles with specific permissions. We can either assign these permissions in a pre-defined way (by creating default api-admin, api-owner, and api-consumer roles), or we can allow users to define their own custom roles and assign existing permissions to them.

But I wanted to highlight that developer portal roles and OpenShift RBAC roles are not the same. The fundamental difference: Boundary vs. Ownership

• OpenShift RBAC (Infrastructure-Centric): This is fundamentally boundary-based. In Kubernetes and OpenShift, namespaces are the primary administrative boundary. An RBAC RoleBinding grants permissions to a user or group for specific resource kinds within that specific namespace, regardless of who actually "owns" the resource. It cares about "where" the resource lives.

• Developer Portal/Backstage (Catalog-Centric): This is fundamentally ownership-based. The Backstage software catalog models the organizational reality of your engineering teams. Permissions are evaluated based on relations (like the spec.owner field in a catalog-info.yaml). A developer portal role cares about "who" is responsible for the resource, even if a single team's owned components are scattered across multiple OpenShift namespaces or even entirely different clusters.

Thus, developer portal roles allow you to define roles with permissions on owned resources or all resources of a kind.

# api-owner can update only api products they own                                                                                                                                                                                                       
p, role:default/api-owner, kuadrant.apiproduct.update.own, update, allow                                                                                                                                                                              
# api-admin can update any api product
p, role:default/api-admin, kuadrant.apiproduct.update.all, update, allow

Furthermore, the developer portal roles allow you to define roles with permissions like "create API keys only if they belong to a named API product." For example:

 # example: restrict specific apis to specific roles                                                                                                                                                                                                                                                                                                                                                                                                                                                   
 p, role:default/partner, kuadrant.apikey.create, create, allow, apiproduct:toystore/toystore-api                                                                                                                                                      

So, another question we need to answer is if we want to maintain the developer portal role system as we know or needs to be revisited.

[didierofrivia]

I concur with the difference between the _ Infrastructure-Centric_ and _ Catalog-Centric_ differences and how they are/should be applied. Since we are facing a Catalog-Centric situation, we might need to consider other solutions, closer to RBAC we can go for ABAC (or a mix of both), that is a bit more flexible and natively supported by K8S... I can foresee that some business models will require a stronger system of permission granting, and some organisations that are using IDPs for this such as Keycloak that already defined everything there... Regardless of how we approach this, we might want to have a template or Kuadrant predefined way + documentation on how to expand it. I'd love to know what @guicassolato thoughts are about this.