🚀: Implement permission-based access control for protected routes

[prakharsingh-74]

Fixes #2079

Description

Problem
Users without proper permissions could access and view all resources, system pages, and admin features regardless of their permission settings. This is a critical security vulnerability that allows unauthorized access to:

• Admin panel (/admin/users)
• Workload management pages
• Binding policies
• System resources
• Grafana dashboards
• Plugin management

Steps to Reproduce:

• Go to /admin/users and create a user with no permissions
• Login as that user
• Navigate to any protected page (e.g., /workloads/manage, /resources)
• Expected: User should be blocked
• Actual: User can access everything

Solution
Implemented a comprehensive permission-based access control system with three layers of protection:

1. Authentication Check - User must be logged in
2. Admin Check - Admin-only routes require is_admin: true
3. Component Permission Check - Each route checks for specific read/write permissions

Changes Made

1. frontend/src/utils/permissionUtils.ts - Permission checking utilities

hasPermission(userPermissions, 'workloads', 'read') 
hasAllPermissions(userPermissions, requirements)
hasAnyPermission(userPermissions, requirements)

2. frontend/src/hooks/useUserPermissions.ts - Hook to fetch user permissions

const { data: user, isLoading } = useUserPermissions();

3. frontend/src/components/ProtectedRoute.tsx - Enhanced with permission checks

• Added requireAdmin prop for admin-only routes.
• Added requiredPermission prop for component-level permissions.
• Added error handling for 401 responses (expired sessions).

4. frontend/src/routes/routes-config.tsx - Added permission requirements to all protected routes

Route Protection Mapping

Testing Instructions

Setup Test Users

• Login as admin
• Navigate to /admin/users
• Create these test users:

User 1: No Permissions

• Username: testuser1
• Permissions: All set to null

User 2: Read Only

• Username: testuser2
• Permissions: workloads: read, clusters: read

User 3: Admin

• Username: testadmin
• Is Admin: Yes

Test Cases

Test 1: Unauthorized Access

1. Login as testuser1 (no permissions)
2. Try to access /workloads/manage
3. Expected: ✅ Redirected to / with error toast: "Access denied. You don't have read permission for workloads."

Test 2: Read-Only Access

1. Login as testuser2
2. Navigate to /workloads/manage
3. Expected: ✅ Page loads successfully
4. Try to access /resources
5. Expected: ✅ Redirected to / (no resources permission)

Test 3: Admin Access

1. Login as testadmin
   2 .Navigate to /admin/users
2. Expected: ✅ Page loads successfully

Test 4: Session Expiry

1. Clear localStorage in browser DevTools
2. Reload the page
3. Expected: ✅ Redirected to login page (no blank screen)

Checklist

Please ensure the following before submitting your PR:

• I have reviewed the project's contribution guidelines.
• I have tested the changes locally and ensured they work as expected.
• My code follows the project's coding standards.

[github-actions]

Welcome to KubeStellar! 🚀 Thank you for submitting this Pull Request.

Before your PR can be merged, please ensure:

✅ DCO Sign-off - All commits must be signed off with git commit -s to certify the Developer Certificate of Origin

✅ PR Title - Must start with an emoji: ✨ (feature), 🐛 (bug fix), 📖 (docs), 🌱 (infra/tests), ⚠️ (breaking change)

Getting Started with KubeStellar:

• 📦 Quick Start
• 📖 Documentation
• 🎬 YouTube - Getting Started & Contributing

Contributor Resources:

• 📚 Contributor Handbook
• 🪜 Contributor Ladder
• 🎓 Mentorship Programs (LFX, GSoC)
• 💬 Slack - #kubestellar-dev

---

🌟 Help KubeStellar Grow - We Need Adopters!

Our roadmap is driven entirely by adopter feedback. Whether you're using KubeStellar yourself or know someone who could benefit from multi-cluster Kubernetes:

📋 Take our Multi-Cluster Survey - Share your use cases and help shape our direction!

---

A maintainer will review your PR soon. Feel free to ask questions in the comments or on Slack!

[kubestellar-prow]

Hi @prakharsingh-74. Thanks for your PR.

I'm waiting for a kubestellar member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[oksaumya]

/ok-to-test

[Copilot]

Pull request overview

Implements frontend permission-based route guarding so authenticated users can only access protected pages when they have the required admin flag and/or component-level permissions (addressing issue #2079).

Changes:

• Added permission utility helpers (hasPermission, hasAllPermissions, hasAnyPermission).
• Added a useUserPermissions() hook to fetch /api/me (user + permissions).
• Enhanced ProtectedRoute and updated route config to enforce per-route permission requirements and admin-only access.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 6 comments.

File	Description
frontend/src/utils/permissionUtils.ts	Introduces reusable permission-checking helpers.
frontend/src/hooks/useUserPermissions.ts	Adds react-query hook for fetching current user permissions from /api/me.
frontend/src/components/ProtectedRoute.tsx	Adds permission + admin checks and session-expiry redirect behavior.
frontend/src/routes/routes-config.tsx	Attaches permission requirements to multiple protected routes.

Comments suppressed due to low confidence (2)

frontend/src/routes/routes-config.tsx:85

• The requiredPermission.component values used here (e.g., clusters, workloads, binding-policies, plugins) don’t match the permission component IDs currently managed/returned elsewhere (dashboard, resources, system, users via /api/me mock and User Management UI). As-is, users (including admins in mocks/e2e) will likely be denied access to these routes because the keys won’t exist in user.permissions. Align the route guard component IDs with the backend/admin UI permission taxonomy, or update the permission model (UI + mocks + API contract) in the same PR so these routes can be granted correctly.

            path: 'its',
            element: (
              <ProtectedRoute requiredPermission={{ component: 'clusters', level: 'read' }}>
                <Suspense fallback={<LoadingFallback message="Loading ITS..." size="small" />}>
                  <ITSLazy />
                </Suspense>
              </ProtectedRoute>

frontend/src/routes/routes-config.tsx:145

• Only the explicit plugin manager/marketplace routes are permission-gated here. Dynamically injected pluginRoutes are created in PluginLoader wrapped with <ProtectedRoute> but without any requiredPermission, so plugin pages can still be accessed by any authenticated user. Consider enforcing a permission requirement for pluginRoutes as well (either by passing a requiredPermission when generating plugin routes, or wrapping/mapping pluginRoutes here).

              <ProtectedRoute requiredPermission={{ component: 'plugins', level: 'read' }}>
                <Suspense
                  fallback={<LoadingFallback message="Loading Plugin Manager..." size="medium" />}
                >
                  <PluginManagerLazy />
                </Suspense>
              </ProtectedRoute>

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[prakharsingh-74]

@oksaumya and @MAVRICK-1 can you please review this PR?

[naman9271]

/lgtm

[kubestellar-prow]

LGTM label has been added.

Details

Git tree hash: 0671e45225201d8e70e23685e9decfb7c6b2b5a2

[naman9271]

/approve

[kubestellar-prow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: naman9271
Once this PR has been reviewed and has the lgtm label, please assign onkar717 for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment