Skip to main content
Back to blog

Namespaces Are the Tenancy Line. Your Cluster View Should Respect It.

Riya Mittal
Riya Mittal Engineer · Zop.Dev
3 min read
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 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 viewWhat a scoped user seesLeaks other teamsMatches RBAC
Cluster-wideEvery namespaceYes, all of themNo
Per-namespaceOnly granted namespacesNoYes

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.

Tagged
Riya Mittal

Riya Mittal

Engineer · Zop.Dev

Riya works on the autonomous remediation engine at Zop.Dev. Before that she was a security engineer at a SaaS company that learned the hard way what 14 days of exposure looks like. She writes about cloud security, automation, and the trade-off between speed and safety.

Stop watching the waste.
Start cutting it.

See. Find. Fix. Automatic.

Connect your first cloud account in under 5 minutes. See your first remediation in under 7. No credit card required.

CDCR connect detect classify remediate
full audit every action traceable
read-only default access
Multi-cloud automation· Production-ready in 30 min· SOC 2 · ISO 27001 · zero-trust· 30% average cloud cost cut· 4 platforms · 1 console· Multi-cloud automation· Production-ready in 30 min· SOC 2 · ISO 27001 · zero-trust· 30% average cloud cost cut· 4 platforms · 1 console·