# Namespaces Are the Tenancy Line. Your Cluster View Should Respect It. > In Kubernetes, the namespace is where multi-tenancy actually lives. Resource quotas stop there. Network policy stops there. RBAC stops there. Then someone opens a live cluster view and sees every… Source: https://zop.dev/resources/blogs/kubernetes-live-view-namespace-rbac Published: 2026-07-14 · Author: riya-mittal · Tags: cloudops, kubernetes, rbac, multi-tenancy, security --- In Kubernetes, the namespace is where multi-tenancy actually lives. Resource quotas stop there. Network policy stops there. RBAC stops there. Then someone opens a live cluster view and sees every namespace at once, including the ones they were never granted. The boundary that governs everything else quietly stops at the dashboard. That is not a cosmetic gap. A platform engineer scoped to one team's namespace should not be reading another team's pod names, image tags, environment variables, and crash loops. Those details leak architecture, release cadence, and live incidents to people who were never given access to them. ZopNight's Kubernetes live view now respects per-namespace access. You see only the namespaces you have been granted, exactly the way access is granted to every other resource. ## A read-only view is still access It is easy to treat a live view as harmless because it changes nothing. But visibility is access. Seeing a namespace's workloads tells you what a team runs, how often they ship, which services are failing right now, and which secrets are wired into which pods by name. In a shared cluster with a dozen teams, an all-namespaces view hands every one of them a window into the other eleven. The fix is not a new permission model. It is the one you already have. Kubernetes RBAC already knows which namespaces a user can touch. The live view now reads from the same grants, so what you can see matches what you can do. Architecture diagram ## One access model, not two The alternative teams usually live with is two disconnected models: RBAC for what you can change, and a wide-open dashboard for what you can see. Two models drift. The dashboard shows a namespace RBAC would deny, and now the audit story has a hole. "Who could see production?" gets a different answer from "who could touch production?" Collapsing the two removes the hole. Access granted once, in RBAC, governs both action and visibility. | Live view | What a scoped user sees | Leaks other teams | Matches RBAC | |---|---|---|---| | Cluster-wide | Every namespace | Yes, all of them | No | | Per-namespace | Only granted namespaces | No | Yes | ## When it fits, and when it does not This fits any cluster that already uses namespaces as the tenancy boundary, which is most of them. If your teams are separated by namespace, per-namespace visibility simply makes the view honest. It does less for a cluster that leans on cluster-wide roles, where everyone is effectively an admin. There the view will faithfully show everything, because that is what the grants say. The fix in that case is upstream: scope the RBAC first, and the view follows. A live view is a lens on the cluster. Point it only where the viewer already holds the keys, and it stops being a quiet side channel around your access model.