Context

Koku is being integrated with Kessel/SpiceDB for Relationship-Based Access Control (ReBAC) in on-prem deployments (FLPATH-3294). The ros-ocp-backend (Go/Echo) needs parallel integration to support Kessel authorization on its own API endpoints alongside the existing RBAC flow.

ros-ocp-backend currently uses RBAC_ENABLE (bool) to toggle a Go Echo middleware (internal/api/middleware/rbac.go) that calls the SaaS RBAC API at /api/rbac/v1/access/?application=cost-management. In on-prem, this RBAC service does not exist – Kessel provides the same authorization capability via gRPC.

Scope of Work

1. Add COST_APPLICATION_TYPE_ID env var support to housekeeper

The housekeeper (internal/services/housekeeper/sourcesCleaner.go) calls sources.GetCostApplicationID() (internal/utils/sources/sources_api.go) at startup via http.Get to /application_types?filter[name][eq]=/insights/platform/cost-management with no auth headers. If this call fails, the housekeeper exits with os.Exit(1).

In on-prem, the cost-management application type ID is always "0" (hardcoded in Koku source_type_mapping.py).

Change: Add a COST_APPLICATION_TYPE_ID config field in internal/config/config.go. When set, GetCostApplicationID() returns the value directly without making an HTTP call. When unset, fall back to the existing API lookup (SaaS compatibility).

The helm chart already provisions COST_APPLICATION_TYPE_ID=0 in the housekeeper deployment. This eliminates the unauthenticated /application_types HTTP call entirely in on-prem.

2. Enable ReBAC via configuration alongside existing RBAC

The current RBAC middleware in internal/api/middleware/rbac.go calls the SaaS RBAC service to check permissions for openshift.cluster, openshift.node, and openshift.project resource types. When RBAC_ENABLE=true, unauthenticated users get HTTP 403.

The authorization backend should be selectable at runtime via configuration. RBAC remains the default.

Change: Add an AUTHORIZATION_BACKEND config field in internal/config/config.go (default: rbac). The middleware layer supports both backends:

• When AUTHORIZATION_BACKEND=rbac (default): Existing RBAC middleware is used unchanged – calls the RBAC HTTP API as today
• When AUTHORIZATION_BACKEND=rebac: A new Kessel middleware queries SpiceDB via gRPC LookupResources to resolve permissions
• Both backends map the same permission types: openshift.cluster, openshift.node, openshift.project
• The X-Rh-Identity header flow is preserved in both paths (already handled by internal/api/middleware/identity.go)
• Org-admin bypass during bootstrap (ENHANCED_ORG_ADMIN equivalent) should work in both modes

Reference: Koku implements this dual-backend pattern via koku_rebac/access_provider.py (Kessel) and api/common/permissions/ (RBAC), with AUTHORIZATION_BACKEND setting to switch between them.

Technical Details

Dependencies

• FLPATH-3294: Kessel ReBAC integration (Koku side) – provides the ZED schema, role definitions, and Python reference implementation
• FLPATH-3336: Secure sources-api write endpoints – the Koku endpoints ros-ocp-backend interacts with will require Kessel authorization
• Helm chart: COST_APPLICATION_TYPE_ID env var already set in housekeeper deployment (ros-helm-chart)

Acceptance Criteria

• Housekeeper honours COST_APPLICATION_TYPE_ID env var; when set, skips HTTP lookup to /application_types and uses the value directly
• ros-ocp-backend API endpoints (/recommendations/openshift) enforce Kessel authorization when AUTHORIZATION_BACKEND=rebac
• RBAC is the default authorization backend; existing RBAC flow is unchanged
• Both RBAC and Kessel authorization backends are supported and selectable via AUTHORIZATION_BACKEND configuration
• Unit and integration tests cover both authorization paths
• Housekeeper no longer crashes (os.Exit(1)) when sources API is unreachable in on-prem with COST_APPLICATION_TYPE_ID set