As a user \
I want to replace the current permission checking system with one better suited for UI
So that I get a slightly faster UI
Context
Currently, the frontend checks permissions using SelfSubjectAccessReview API in Kubernetes. This API gives returns true/false indicating whether the user is allowed to interact with the resource in question. However, each permission needs its own request for each verb, e.g. "list", "update" and "create" sum already to 3 individual request for a single resource like Organization.
Navigating all features (teams, organizations, billing, etc) with 4 organizations already sums up to 27 requests at least.
However, there is an API that is more suited for UI permission checks: SelfSubjectRulesReview (or kubectl auth can-i --list -n <namespace> equivalent). This returns a single response with list of all the resources that can the user can access in a single namespace. With 4 organizations we can reduce the number of requests to 5 (1 is for checking the cluster-scoped resources first, using the default namespace).
This issue is intended for a refactoring, functionally or visually it shouldn't change anything for the user. But it may improve responsiveness. However, there is a downside to this: While the number of request goes down, the JSON payload size increases, especially for OpenShift. The payload would possibly contain loads of other unrelated permissions.
In that sense, switching could be considered "premature optimization", so we might only address this when it's actually a problem with lots of small SelfSubjectAccessReview requests. We currently don't know whether it's better to have many small requests on demand or few larger requests relatively early.
Out of Scope
There is another issue to discuss which permissions to check. This issue here discusses how those permissions are checked.
The Rules review API requires a namespace even for cluster-scoped resources. Upon startup we can issue 1 request in the default namespace, as that lists the cluster-scoped resources as well.
Once loaded the Rules into frontend/store, we should implement helper functions that filter the desired permissions for each module/feature.
Summary
As a user \ I want to replace the current permission checking system with one better suited for UI So that I get a slightly faster UI
Context
Currently, the frontend checks permissions using
SelfSubjectAccessReviewAPI in Kubernetes. This API gives returns true/false indicating whether the user is allowed to interact with the resource in question. However, each permission needs its own request for each verb, e.g. "list", "update" and "create" sum already to 3 individual request for a single resource like Organization.Navigating all features (teams, organizations, billing, etc) with 4 organizations already sums up to 27 requests at least.
However, there is an API that is more suited for UI permission checks:
SelfSubjectRulesReview(orkubectl auth can-i --list -n <namespace>equivalent). This returns a single response with list of all the resources that can the user can access in a single namespace. With 4 organizations we can reduce the number of requests to 5 (1 is for checking the cluster-scoped resources first, using thedefaultnamespace).This issue is intended for a refactoring, functionally or visually it shouldn't change anything for the user. But it may improve responsiveness. However, there is a downside to this: While the number of request goes down, the JSON payload size increases, especially for OpenShift. The payload would possibly contain loads of other unrelated permissions.
In that sense, switching could be considered "premature optimization", so we might only address this when it's actually a problem with lots of small SelfSubjectAccessReview requests. We currently don't know whether it's better to have many small requests on demand or few larger requests relatively early.
Out of Scope
There is another issue to discuss which permissions to check. This issue here discusses how those permissions are checked.
Further links
Acceptance Criteria
No response
Implementation Ideas
The Rules review API requires a namespace even for cluster-scoped resources. Upon startup we can issue 1 request in the
defaultnamespace, as that lists the cluster-scoped resources as well. Once loaded the Rules into frontend/store, we should implement helper functions that filter the desired permissions for each module/feature.