Skip to content

feat(rbac): surface denied core cluster-scoped kinds instead of '0 / No X found'#974

Closed
nadaverell wants to merge 1 commit into
mainfrom
feat/surface-denied-cluster-scoped-kinds
Closed

feat(rbac): surface denied core cluster-scoped kinds instead of '0 / No X found'#974
nadaverell wants to merge 1 commit into
mainfrom
feat/surface-denied-cluster-scoped-kinds

Conversation

@nadaverell

@nadaverell nadaverell commented Jun 23, 2026

Copy link
Copy Markdown
Contributor

What

When a user's RBAC denies listing a core cluster-scoped kind (Node, PV, StorageClass, Namespace…), handleResourceCounts silently continued — omitting the kind from both counts and forbidden. Core kinds are static in the sidebar, so they rendered as 0 / "No Node found" — indistinguishable from an empty cluster (the exact symptom a Hub owner hit on a cluster where their tier lacks cluster-scoped read).

Change

internal/server/resource_counts.go: on canRead denial for a core cluster-scoped kind, add it to the existing forbidden set instead of dropping it. The frontend already renders an "Access Restricted" state + sidebar shield from forbidden (ResourcesView.tsx), so this lights up with no frontend change. CRDs keep the silent-omit behavior (a denied CRD is ambiguous with not-installed).

Test

TestResourceCountsSurfacesDeniedCoreClusterScopedKindAsForbidden — denies list nodes, asserts Node is in forbidden and absent from counts. Existing TestResourceCountsOmitsClusterScopedCRDWhenCanReadDenies (CRD path unchanged) still passes.

Part of the cluster-scoped RBAC visibility work; no RBAC-posture change — read-authorization behavior is unchanged, only how a denial is reported.


Note

Low Risk
Reporting-only change for denied core cluster-scoped counts; authorization checks are unchanged and CRD behavior is untouched.

Overview
When RBAC denies list on a core cluster-scoped kind (Node, PV, etc.), handleResourceCounts now adds that kind to forbidden instead of omitting it from the response. That stops the sidebar from showing 0 / “No X found”, which looked like an empty cluster rather than an access denial; the UI already treats forbidden as “Access Restricted.”

Cluster-scoped CRDs still skip silently on denial (unchanged), since a denied CRD is ambiguous with not installed. A new test denies list nodes and asserts Node is in forbidden and absent from counts.

Reviewed by Cursor Bugbot for commit 6d19a5f. Bugbot is set up for automated code reviews on this repo. Configure here.

When a user's RBAC denies listing a core cluster-scoped kind (Node, PV,
StorageClass, Namespace, ...), resource-counts silently omitted it, so the UI
rendered '0 / No Node found' — indistinguishable from an empty cluster. Surface
these in the existing forbidden set so the frontend's existing 'Access Restricted'
state renders instead. CRDs stay omitted (could be not-installed vs denied).
@nadaverell

Copy link
Copy Markdown
Contributor Author

Consolidated into #988 (cluster-scoped RBAC visibility). Same commits, one PR.

@nadaverell nadaverell closed this Jun 23, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant