ocdp-go/docs/bugs-user-c.md

QA Report: Permission Isolation & Multi-Tenancy Testing — test-user-c

Tester: test-user-c (role: user) Date: 2026-05-11 Environment: http://10.6.80.114:18080

Summary

Test-user-c is a standard user role with namespace ocdp-u-test-c, workspace 71459030-7166-4c79-b53c-81c61da4c313. Permissions follow the manage_own / view pattern — no admin-level permissions.

---

Test Results

1. Login & Basic Access ✅

Test	Result	Notes
POST /auth/login	✅ Pass	Token issued, role=user, workspace/namespace correctly assigned
GET /auth/me	✅ Pass	Returns correct user profile with permissions
GET /clusters	✅ Pass	Sees all global_shared clusters (k8s, k3s)
GET /registries	✅ Pass	Sees all global_shared registries (harbor)

2. Admin Endpoint Protection

Test	Result	Notes
GET /api/v1/users	✅ 403 Forbidden	Properly blocked — permission denied
POST /auth/register	✅ 403 Forbidden	Cannot register new users as non-admin
GET /api/v1/admin/*	✅ 404	Admin route prefix doesn't exist (not a bypass risk)

3. Frontend Access

Test	Result	Notes
GET /configuration/users	⚠️ 200 (OK)	SPA returns index.html — expected. Auth is enforced via API, not routes.
GET /configuration/clusters	⚠️ 200 (OK)	Same — SPA behavior.
GET /configuration/registries	⚠️ 200 (OK)	Same.

Risk: Low. This is standard SPA behavior. Authorization is enforced at the API level. However, if the frontend relies solely on hiding UI elements rather than checking permissions, users who manually navigate could see empty/error states.

4. Namespace Isolation Enforcement

Test	Result	Notes
Deploy with namespace: ocdp-u-test-a	⚠️ Silently overridden	Server ignored requested namespace and used ocdp-u-test-c instead. No warning or error returned.
PATCH to change namespace	✅ 404	PATCH endpoint doesn't exist — namespace cannot be changed after creation

🔴 Bug: Silent namespace override (Low severity) When a user specifies a namespace that doesn't belong to them in the instance creation request, the server silently overrides it with the user's own namespace. This is secure (prevents cross-namespace deployment) but:

• The user receives HTTP 200 with the overridden value — no indication that their request was modified
• The response does not differentiate between "user's own namespace" and "requested namespace"
• This could lead to user confusion about where their resources were actually deployed
• It's unclear whether the user's Helm values also get silently overridden (e.g., the values.namespace field)

5. Resource Isolation

Test	Result	Notes
GET instances with other workspaceId query param	✅ Isolated	Returns only own instances (workspaceId filter is server-enforced)
DELETE on own instance	⚠️ Async deletion	Returns HTTP 404 on DELETE itself, but instance transitions to pending-delete then disappears

🔴 Bug: DELETE returns 404 on success (Medium severity) When deleting an instance via DELETE /clusters/{clusterId}/instances/{instanceId}:

• The instance transitions to pending-delete status
• But the HTTP response status code is 404 rather than 200/202/204
• The first raw DELETE call returns an empty body (causing JSON parse errors)
• This is an API inconsistency — async deletions should return HTTP 202 Accepted

6. Monitoring & Other Endpoints

Test	Result	Notes
GET /monitoring/clusters/.../pods	✅ 404	Monitoring endpoints not implemented for this cluster type
POST /kubeconfig	✅ 404	Kubeconfig endpoint not implemented

These endpoints return 404 which is acceptable behavior for features not yet implemented.

---

Security Assessment

Works as Intended ✅

• Admin endpoints (/users, /auth/register) properly return 403
• User cannot access other users' instances via workspaceId manipulation
• User cannot deploy into other users' Kubernetes namespaces
• No PATCH/PUT verbs available to modify existing instance namespaces
• No admin-specific route paths leak data

Bugs Found

1. DELETE returns 404 on successful async deletion (Medium)

   • Endpoint: DELETE /clusters/{id}/instances/{id}
   • After call, instance status becomes pending-delete and eventually disappears
   • But the HTTP response is 404 with empty body
   • Expected: 202 Accepted with a status: "deleted" or similar response
   • Risk: Clients interpreting HTTP 404 as "not found" will retry or report errors incorrectly

2. Silent namespace override without user feedback (Low)

   • Endpoint: POST /clusters/{id}/instances
   • When requesting deployment into another user's namespace, the server silently uses the caller's namespace
   • No warning, no error, no indication in the response
   • Expected: Either 403 Forbidden with "cannot deploy into namespace owned by another user" or a response field indicating the override occurred
   • Risk: Low for security (the override correctly prevents cross-tenant deployment), but could cause user confusion

No Critical Vulnerabilities Found

• No privilege escalation vectors identified
• No data leakage across workspaces
• No ability to access or manipulate other users' resources