Improve UI handling of custom RBAC config #2287
Labels
kind/feature
Categorizes issue or PR as related to a new feature.
lifecycle/frozen
Indicates that an issue or PR should not be auto-closed due to staleness.
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:
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.
The text was updated successfully, but these errors were encountered: