feat(rbac): roles and api guards

[thornsberrysara]

Description

Please include a summary of the changes and the related issue. Please also include relevant motivation and context. List any dependencies that are required for this change.

Kubero already had roles, permissions, and JWT-based checks in parts of the UI and API, but the role model was incomplete and several API routes were not consistently protected. This PR implements the RBAC model described in #545 by adding two new built-in roles and tightening API enforcement.

Summary of changes:

• New built-in roles seeded on startup: developer (manage apps/pipelines, logs/console/reboot; no accounts or settings) and viewer (read-only apps/pipelines, logs and audit; no writes, console, or reboot).
• docs/rbac.md documenting roles, permissions, teams vs. roles, and how enforcement works.
• UI: built-in roles (admin, member, developer, viewer, guest) cannot be deleted from Accounts → Roles; English locale hints for built-in roles.
• API: PermissionsGuard added or extended on controllers that were missing or inconsistently guarded:
  • deployments, repo, kubernetes
  • addons, metrics, templates
  • notifications (previously unauthenticated; now requires JWT + config:read / config:write)

Motivation: Issue #545 calls for clearer, enforceable roles beyond admin/member/guest. Without API guards on all sensitive routes, permission checks in the UI could be bypassed. The notifications API in particular was a gap.

Dependencies: None. No operator or CLI changes required.

Fixes #545

Type of change

Please delete options that are not relevant.

• Template (non-breaking change which adds a template)
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

• I've built the image and tested it on a kubernetes cluster
• Local dev testing (server + built client, SQLite, kind cluster with Kubero CRDs)

Manual test plan (reproducible locally):

1. Start server (npm run start:dev in server/), build client (npm run build in client/).
2. Log in as admin → Accounts → Roles → confirm developer and viewer exist; confirm built-in roles cannot be deleted.
3. Create users devtest (developer) and viewtest (viewer), assign admin team for pipeline visibility.
4. Viewer: Accounts/Settings hidden in nav; pipeline create disabled; app edit/reboot/console disabled; logs allowed.
5. Developer: Accounts/Settings hidden; pipeline/app write actions enabled; console/reboot/logs enabled.
6. API (Swagger or curl): as viewer/developer, GET /api/users and GET /api/notifications return 403; as admin return 200.

Test Configuration:

• Operator Version: n/a (CRDs only on local kind cluster; not required for RBAC verification)
• Kubernetes Version: v1.35.0 (kind-tools)
• Kubero CLI Version (if applicable): n/a

Checklist:

• I removed unnecessary debug logs
• My code follows the style guidelines of this project
• I have performed a self-review of my code
• I documented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings

---

Note for reviewers: Permissions are embedded in the JWT at login — users must log out and back in after a role change to pick up new permissions. Repo webhook routes remain unauthenticated by design (external Git providers).