Uploaded image for project: 'FlightPath'
  1. FlightPath
  2. FLPATH-2690 Use ACM and Kessel for ReBAC
  3. FLPATH-3336

Secure sources-api write endpoints with Kessel authorization (ONPREM)

XMLWordPrintable

    • Icon: Dev Sub-task Dev Sub-task
    • Resolution: Unresolved
    • Icon: Undefined Undefined
    • None
    • None
    • insights-on-prem
    • False
    • Hide

      None

      Show
      None
    • 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

              jgil@redhat.com Jordi Gil
              jgil@redhat.com Jordi Gil
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated: