KubeCrow uses your kubeconfig’s identity and the Kubernetes API, so it can do exactly what that identity is allowed to do, and nothing more. Here is what each part uses.
Browsing
listandwatchon the resources you open. Each selected namespace gets its own watch, so namespace-scoped RBAC works: pick the namespaces you have.- Metrics in lists and the Health page come from metrics-server (
metrics.k8s.io). - The node disk column reads each node’s stats through
nodes/proxy; without it, the column says why.
Actions
| Action | Needs |
|---|---|
| Logs | get pods/log |
| Pod shell | create pods/exec |
| Node shell | create pods and create pods/exec in kube-system: it starts a short-lived privileged pod (busybox:1.36) on the node and deletes it when you close the tab |
| Edit, restart, cordon, drain, suspend, roll back | patch on the object |
| Scale | patch or update on its scale subresource |
| Delete | delete |
| Trigger a CronJob | create jobs |
| Port forward | create pods/portforward |
| Prometheus and Loki | get services/proxy in their namespace (details) |
Greyed-out actions
KubeCrow asks the cluster once per namespace what you may do (a SelfSubjectRulesReview, cached for a minute) and greys out actions you can’t perform; hovering says which permission is missing. Bulk actions count only the objects you may change and skip the rest. It never blocks on doubt: if the cluster’s authorizer can’t list everything (for example EKS access entries or a webhook) or the check fails, everything stays enabled and the API server has the final say.
A read-only setup
Kubernetes’ built-in view ClusterRole covers browsing most resources (not Secrets) and reading logs. Bound in one namespace:
kubectl create rolebinding kubecrow-view --clusterrole=view [email protected] -n team-aFor charts and log search, add get on services/proxy in the monitoring namespace. On top of RBAC, KubeCrow’ own Read-only mode (Settings → Clusters) refuses changes and shells for a cluster even when your identity could make them.
Questions
Can I use KubeCrow with read-only Kubernetes access?
Yes. With the built-in view role you can browse resources and read logs; actions you aren’t allowed to do are greyed out with the reason.
Why does a node shell need access to kube-system?
It starts a short-lived privileged pod on that node in kube-system and opens a shell in it, so it needs create on pods and pods/exec there. The pod is deleted when the tab closes.