-
Dev Sub-task
-
Resolution: Unresolved
-
Undefined
-
None
-
None
-
False
-
-
False
-
-
Context
PR #5895 adds sources CRUD endpoints to Koku for on-prem, replacing sources-api-go. Write endpoints use AllowAny permission class, meaning any authenticated user can create, modify, or delete sources within their org with no authorization check. In the SaaS, sources-api-go enforces sources:: via RBAC on write operations.
Authorization gap
| Endpoint | sources-api-go (SaaS) | Koku PR #5895 (on-prem) |
|---|---|---|
| GET /source_types | No auth (catalog, read-only) | No auth (catalog, read-only) |
| GET /application_types | No auth (catalog, read-only) | No auth (catalog, read-only) |
| POST /sources | Tenancy + RBAC sources:: | AllowAny – no authz |
| PATCH /sources/:id | Tenancy + RBAC sources:: | AllowAny – no authz |
| DELETE /sources/:id | Tenancy + RBAC sources:: | AllowAny – no authz |
| POST /applications | Tenancy + RBAC sources:: | AllowAny – no authz |
Cross-org isolation is already enforced by the gateway (JWT validation) and middleware (org_id scoping), same as in the SaaS. The gap is intra-org: any authenticated user in the org can mutate sources regardless of their role.
Changes required
1. Add permission class to sources write endpoints
koku: Add a DRF permission class to sources write operations (POST, PATCH, DELETE on /sources/ and POST on /applications) that checks for a Kessel write permission (e.g. settings.write) when ONPREM=True. This restricts source mutation to users with the appropriate role binding (e.g. cost-administrator). Read-only catalog endpoints (/source_types, /application_types) remain AllowAny.
2. Bootstrap CMMO identity with Kessel binding
CMMO authenticates through the gateway (Keycloak JWT -> Envoy Lua -> X-Rh-Identity). The CMMO user identity (username from the JWT) needs a cost-administrator role binding in Kessel to perform source writes (POST /sources, POST /applications). This binding should be created as part of the provisioning/bootstrap process (e.g. deploy-kessel.sh or the migration job).
3. Eliminate housekeeper unauthenticated endpoint dependency
The ROS housekeeper calls GET /application_types once at startup (pod-to-pod, no auth) to resolve the cost-management application type ID. In on-prem, this ID is hardcoded to "0" (COST_MGMT_APP_TYPE_ID in source_type_mapping.py).
Quick fix:
- ros-ocp-backend: Add COST_APPLICATION_TYPE_ID config field. When set, skip the HTTP lookup and use the value directly; otherwise fall back to the API call (SaaS compatibility).
- ros-helm-chart: Set in housekeeper deployment:
- name: COST_APPLICATION_TYPE_ID value: "0"
Acceptance criteria
- Sources write endpoints (POST, PATCH, DELETE) require Kessel write permission when ONPREM=True
- Users without the appropriate role binding get 403 on source mutation
- CMMO identity has a cost-administrator Kessel binding and can register sources through the gateway
- ROS housekeeper uses COST_APPLICATION_TYPE_ID env var, eliminating the unauthenticated API call
- Catalog endpoints remain AllowAny (read-only static metadata, protected by NetworkPolicy)
- No impact on SaaS behavior
- depends on
-
FLPATH-3294 Kessel ReBAC integration - Detailed Design and Implementation
-
- In Progress
-
- is depended on by
-
FLPATH-3338 Integrate ros-ocp-backend with Kessel ReBAC authorization (ONPREM)
-
- In Progress
-