For users with read-only access (that doesn't include watch permission) an alternative refresh-on-interval method is needed to maintain a semi-realtime view of the cluster state. This decision/fallback needs to occur on a per-resource kind basis, for any case where the user is allowed to get the resource kind, but not watch it.
In addition, a fallback is also needed for cases where a user is authorized to list a resource kind, but cannot get individual instances of that resource (this might occur for Secret type resources).
On top of this, some users may not be allowed to issue watch/get/list at a global level, but will be permitted within some namespaces.
Related is the distinction for resources that a user would not be allowed to create/edit/delete ( #23 )--the user should see a "View" option as opposed to an "Edit" option for those resources, and should not be allowed to invoke the "Create" or "Delete" options at all.
Testing should be conducted against the following profiles:
(control) User with full admin permission to all resources
[x] should see edit/exec resources from all namespaces
User with admin permission to all resources within 2 namespaces (and nothing else)
[x] should only see resources from those 2 namespaces displayed
User with get/list/watch permission to all resources within 2 namespaces (no create/edit/delete)
[x] should be able to see all resources from those 2 namespaces
[x] should not see any "Delete", "Edit" or "Create" actions available
User with only list and get permission to a given resource within a given namespace
[x] should see all instances of that resource in the namespace
[x] should not see any "Delete", "Edit" or "Create" actions available
matt-deboer
commented
7 years ago
For users with read-only access (that doesn't include
watchpermission) an alternative refresh-on-interval method is needed to maintain a semi-realtime view of the cluster state. This decision/fallback needs to occur on a per-resource kind basis, for any case where the user is allowed togetthe resource kind, but notwatchit.In addition, a fallback is also needed for cases where a user is authorized to
lista resource kind, but cannotgetindividual instances of that resource (this might occur forSecrettype resources).On top of this, some users may not be allowed to issue
watch/get/listat a global level, but will be permitted within some namespaces.Related is the distinction for resources that a user would not be allowed to create/edit/delete ( #23 )--the user should see a "View" option as opposed to an "Edit" option for those resources, and should not be allowed to invoke the "Create" or "Delete" options at all.
Testing should be conducted against the following profiles:
get/list/watchpermission to all resources within 2 namespaces (no create/edit/delete)listandgetpermission to a given resource within a given namespace