Improve UI handling of custom RBAC config

[AlanGreene]

Is your feature request related to a problem ?

Follow up to #1420

The Dashboard API (provided by the Kubernetes API server) respects the configured RBAC, whether using the Dashboard ServiceAccount (default) or via user impersonation. This means that a user accessing the Dashboard can only access and act on the resources to which they (or the Dashboard ServiceAccount) are granted the relevant permissions. In case of forbidden access the Dashboard will display corresponding errors to the user.

The Dashboard also provides a 'read-only' mode with restricted RBAC. This mode is reflected in the UI by hiding any navigation items or other controls that require write access, e.g. Import resources, Create PipelineRun, delete, rerun, etc.

However, if a user/admin customises the RBAC, or enables user impersonation, the UI does not reflect this. All navigation items / controls are available in the UI and the user is presented with corresponding errors for any actions they not have permission to perform. It would be a much better user experience to only show the navigation items and controls the user has permission to use, thus avoiding these errors.

Describe the solution you'd like

The Kubernetes API server provides a number of mechanisms for checking API access

The most appropriate of these seems to be:

• SelfSubjectRulesReview - A review which returns the set of actions a user can perform within a namespace. Useful for users to quickly summarize their own access, or for UIs to hide/show actions.

The Dashboard client should use this to determine which elements to make available in the UI.

Describe alternatives you've considered

SelfSubjectAccessReview allows a user to query whether or not they have permission to perform a given action, e.g. create a deployment in the dev namespace.

This may be useful in specific targeted cases but is unlikely to work well as a more general solution as it would require many requests on page load / navigation.

Additional context

Note: SelfSubjectRulesReview is scoped to a single namespace so additional work is required to handle the 'All namespaces' option in the global namespaces filter.

Consideration should also be given to caching responses for some period to avoid the need to query access on every navigation. This would be purely a client optimisation to avoid unnecessary network traffic, the actual RBAC configured on the cluster would still apply to the API calls.

How would we handle cases where a user doesn't have permission to list namespaces? One option is to prompt them to enter a namespace and then we could persist that in browser storage and use it to populate the namespaces dropdown / selected global namespace filter. For these users we should probably remove/disable the 'All namespaces' option.

[tekton-robot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale with a justification.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle stale

Send feedback to tektoncd/plumbing.

[AlanGreene]

This is still something we want to do .
/lifecycle frozen

[DrissiReda]

@AlanGreene is it a priority? If not, when do you think it’s going to be handled.

[AlanGreene]

Apologies for not replying sooner, I must have missed the notification. It's not currently a high priority but is something we would like to get to eventually. The highest priority items at the moment are currency (supporting latest Pipeline features) and consistency (common actions / presentation of resources, ensuring all *Run resources have similar support for creation etc.).

This issue will become more important to provide clean support for #1388 and also opens up some other interesting possibilities in future so it is still something we'd love to add.