vmware-archive/octant

Disable cluster scope viewing on a namespace overview page

mhoshi-vm opened this issue · 2 comments

mhoshi-vm commented

Describe the problem/challenge you have
Related to #141 .
Although the above issue has introduce to disable cluster overview page(disable-cluster-overview flag), the namespace overview request cluster scope access to several resources, not allowing to open correctly when using a strict kubeconfig file.

Namely we see that it tries to access secrets, roles, rolebindings from cluster scope. Especially we never would want to allow secrets cluster scope.

2021-07-27T06:59:20.554Z	WARN	objectstore/dynamic_cache.go:446	unable to start watcher %!(EXTRA string=failed to list *unstructured.Unstructured: secrets is forbidden: User "system:serviceaccount:octant:octant-sa" cannot list resource "secrets" in API group "" at the cluster scope)

2021-07-27T06:59:20.847Z	WARN	objectstore/dynamic_cache.go:446	unable to start watcher %!(EXTRA string=failed to list *unstructured.Unstructured: roles.rbac.authorization.k8s.io is forbidden: User "system:serviceaccount:octant:octant-sa" cannot list resource "roles" in API group "rbac.authorization.k8s.io" at the cluster scope)

2021-07-27T06:59:20.847Z	WARN	objectstore/dynamic_cache.go:446	unable to start watcher %!(EXTRA string=failed to list *unstructured.Unstructured: rolebindings.rbac.authorization.k8s.io is forbidden: User "system:serviceaccount:octant:octant-sa" cannot list resource "rolebindings" in API group "rbac.authorization.k8s.io" at the cluster scope)

Describe the solution you'd like
If disable-cluster-overview is enabled should never access cluster scope resources

Environment:

  • Octant version (use octant version): 0.21.0
  • Kubernetes version (use kubectl version): v1.20.7
  • OS (macOS 10.15, Windows 10, Ubuntu 19.10 etc): 18.04.5 LTS (Bionic Beaver)
wwitzel3 commented

Thank you for opening this issue, this has been one of those long standing whack-a-mole things we've worked on and we haven't got quite right yet.

Right now, Octant cannot infer the access level. It would have to perform SelfSubjectAccessReview checks before making requests. So we opt for making the request and letting if fail with a warning.

That said, the fact that the overview is not loading properly for you is a bug. Even if Octant fails to watch resources due to RBAC restrictions this should not prevent loading the reasons the service account does have access to.

chelnak commented

I'm seeing this one too. Similar setup to the one described by OP.

I had a poke around the back end code to see if i could pin point where the issue was coming from (I couldn't). Then started to wonder if the WARNs about watchers were actually unrelated.

I noticed that from the front end we get the following from parseWebsocketMessage and thought it could be worth investigating:

{error: "action path \"action.octant.dev/setNamespace\" not found", requestType: "action.octant.dev/setNamespace"}

Does this seem legit or am I crossing wires?

  • 👀1