Posting this to get early feedback on an authentication and authorization direction for OpenCost before writing a formal design doc or LFX proposal.
This is an idea for discussion, not a finalized design.
As discussed with @ameijer during a previous community meeting, authentication/authorization was identified as a potential LFX Mentorship project. After looking into the existing work and related issues, I wanted to write down the direction I had in mind and get feedback from the maintainers and community before investing time into a formal design document and LFX proposal.
Everything below is open to discussion and I'm happy to adapt the approach based on maintainer feedback.
Background
One thing I noticed while exploring OpenCost is that there is currently no concept of who is accessing cost data, which means there is no built-in way to control what different users are allowed to see.
For smaller deployments this is completely reasonable, but for organizations running a shared OpenCost instance across multiple teams, every user who can access OpenCost can currently view cost data across all namespaces, clusters and labels. Even if UI-level restrictions were added, the backend APIs could still be queried directly unless authorization is enforced server-side.
During a previous community discussion with @ameijer, this was mentioned as an area worth exploring for LFX. I was also pointed toward:
- #3797 - Scoped View CRUD APIs
- opencost-ui#256 by @maxvishy
as existing work and a good starting reference.
Existing Work
Vishy's PR (opencost-ui#256) already laid a strong foundation by introducing:
- Clerk authentication
- Scoped Views
- User management
PolicyAuthBridgePolicyProvider / usePolicy hooks- Initial UI for managing users and scoped views
From my understanding, it demonstrates the overall direction very well.
However, it also highlights a few challenges that would likely need to be addressed before something similar could become a long-term upstream solution:
- Authentication is currently coupled to Clerk
- Authorization is primarily frontend-driven
- The work remained incomplete after the mentorship term ended
Proposed Direction
The overall idea would be to separate authentication from authorization.
Instead of OpenCost becoming an authentication system itself, it would simply integrate with an organization's existing identity solution and focus on authorization of OpenCost resources.
In other words:
- Authentication - Who is the user? (delegated to the organization's existing IdP)
- Authorization - What is this user allowed to see inside OpenCost? (owned by OpenCost)
Authentication (delegated)
Rather than integrating with a single provider, OpenCost could support standard enterprise authentication approaches.
Option 1 - Trusted Reverse Proxy (preferred direction)
Use an OIDC-aware reverse proxy such as oauth2-proxy, Pomerium, or an ingress controller with OIDC support. The proxy validates authentication and forwards trusted identity headers (e.g. X-Forwarded-User, X-Forwarded-Groups) to OpenCost.
This keeps authentication outside of OpenCost while allowing organizations to continue using their existing identity provider: Keycloak, Authentik, Okta, Azure AD, Google Workspace, GitHub Enterprise, etc.
Option 2 - Direct OIDC Validation
For simpler deployments, OpenCost could optionally validate JWT tokens directly against a configured OIDC issuer. Whether this belongs in the initial scope or as a follow-up is something I'd like maintainer feedback on.
Option 3 - Disabled (current behavior)
If authentication is not configured, OpenCost continues behaving exactly as it does today, ensuring full backwards compatibility.
Authorization (owned by OpenCost)
Once identity has been established, OpenCost becomes responsible for authorization.
Building on the ideas in #3797, authorization metadata could be persisted locally (for example using SQLite as proposed there) and expose backend CRUD APIs for:
- Scoped Views
- User mappings
- Group mappings
- Role mappings
Rather than relying on the UI to hide information, authorization would be enforced server-side.
A middleware layer would resolve the authenticated user, determine the assigned Scoped View, and transparently apply namespace, cluster and label filters before the request reaches the cost handlers. This ensures that authorization applies equally to UI requests, direct API requests, and any future API consumers.
Admin Experience
The UI work from Vishy's PR provides a great starting point. The direction I had in mind would be a lightweight administration page allowing administrators to manage:
- Scoped Views
- User ↔ Group assignments
- Group ↔ Scoped View mappings
OpenCost would not manage passwords or user provisioning. It would simply map identities provided by the organization's IdP to authorization rules inside OpenCost.
Why This Direction?
Many CNCF projects separate authentication from authorization rather than implementing their own identity management. Projects such as Loki, Cortex/Mimir, and kube-rbac-proxy delegate authentication to existing infrastructure while focusing on authorization or tenant isolation inside the application itself.
A similar approach could allow OpenCost to remain provider-agnostic and support enterprise deployments without introducing another identity system into the stack.
Possible LFX Scope (subject to maintainer feedback)
If this overall direction makes sense, one possible breakdown for a 12-week mentorship could look something like:
| Weeks |
Work |
| 1–2 |
Codebase deep dive, validate architecture with mentors, finalize design |
| 3–4 |
Identity resolution (proxy-header mode), middleware and unit tests |
| 5–6 |
Scoped View CRUD APIs and SQLite persistence (building on #3797) |
| 7–8 |
Authorization middleware for Allocation / Assets / CloudCost endpoints |
| 9–10 |
UI for Scoped View management and identity mapping |
| 11 |
Documentation, deployment examples, Helm values, reference configurations |
| 12 |
Testing, polish, bug fixes and final documentation |
This is only a tentative plan and would naturally evolve based on maintainer feedback.
Open Questions
Some questions I'd especially appreciate input on:
- Should trusted proxy headers be the primary integration point, or would direct OIDC validation be preferred?
- Should Scoped Views apply only to Allocation APIs, or should they also cover CloudCost, Assets and CustomCost?
- If a user belongs to multiple groups, should Scoped Views be merged, prioritized, or handled differently?
- Is direct OIDC validation reasonable within a single mentorship term, or would proxy-header support be a better first step?
- Would maintainers prefer SQLite for authorization metadata, or a different persistence mechanism?
Related Work
In this repo:
- #3797 - Scoped View CRUD APIs
- opencost-ui#256 - Clerk authentication, Scoped Views and initial authorization work
Related CNCF projects:
- Loki - multi-tenancy via
X-Scope-OrgID header, no auth inside the store
- Cortex / Grafana Mimir - same header-based multi-tenant pattern
- kube-rbac-proxy - validates OIDC tokens as a sidecar before proxying to the app
My goal with this discussion is simply to validate whether this direction aligns with where maintainers see OpenCost evolving.
If the overall direction looks reasonable, I'd be happy to convert this into a detailed design proposal and formal LFX Mentorship proposal after incorporating feedback.
Looking forward to hearing everyone's thoughts.
cc @ameijer @mbolt35 @nikovacevic @maxvishy
Posting this to get early feedback on an authentication and authorization direction for OpenCost before writing a formal design doc or LFX proposal.
Background
One thing I noticed while exploring OpenCost is that there is currently no concept of who is accessing cost data, which means there is no built-in way to control what different users are allowed to see.
For smaller deployments this is completely reasonable, but for organizations running a shared OpenCost instance across multiple teams, every user who can access OpenCost can currently view cost data across all namespaces, clusters and labels. Even if UI-level restrictions were added, the backend APIs could still be queried directly unless authorization is enforced server-side.
During a previous community discussion with @ameijer, this was mentioned as an area worth exploring for LFX. I was also pointed toward:
as existing work and a good starting reference.
Existing Work
Vishy's PR (opencost-ui#256) already laid a strong foundation by introducing:
PolicyAuthBridgePolicyProvider/usePolicyhooksFrom my understanding, it demonstrates the overall direction very well.
However, it also highlights a few challenges that would likely need to be addressed before something similar could become a long-term upstream solution:
Proposed Direction
The overall idea would be to separate authentication from authorization.
Instead of OpenCost becoming an authentication system itself, it would simply integrate with an organization's existing identity solution and focus on authorization of OpenCost resources.
In other words:
Authentication (delegated)
Rather than integrating with a single provider, OpenCost could support standard enterprise authentication approaches.
Option 1 - Trusted Reverse Proxy (preferred direction)
Use an OIDC-aware reverse proxy such as
oauth2-proxy, Pomerium, or an ingress controller with OIDC support. The proxy validates authentication and forwards trusted identity headers (e.g.X-Forwarded-User,X-Forwarded-Groups) to OpenCost.This keeps authentication outside of OpenCost while allowing organizations to continue using their existing identity provider: Keycloak, Authentik, Okta, Azure AD, Google Workspace, GitHub Enterprise, etc.
Option 2 - Direct OIDC Validation
For simpler deployments, OpenCost could optionally validate JWT tokens directly against a configured OIDC issuer. Whether this belongs in the initial scope or as a follow-up is something I'd like maintainer feedback on.
Option 3 - Disabled (current behavior)
If authentication is not configured, OpenCost continues behaving exactly as it does today, ensuring full backwards compatibility.
Authorization (owned by OpenCost)
Once identity has been established, OpenCost becomes responsible for authorization.
Building on the ideas in #3797, authorization metadata could be persisted locally (for example using SQLite as proposed there) and expose backend CRUD APIs for:
Rather than relying on the UI to hide information, authorization would be enforced server-side.
A middleware layer would resolve the authenticated user, determine the assigned Scoped View, and transparently apply namespace, cluster and label filters before the request reaches the cost handlers. This ensures that authorization applies equally to UI requests, direct API requests, and any future API consumers.
Admin Experience
The UI work from Vishy's PR provides a great starting point. The direction I had in mind would be a lightweight administration page allowing administrators to manage:
OpenCost would not manage passwords or user provisioning. It would simply map identities provided by the organization's IdP to authorization rules inside OpenCost.
Why This Direction?
Many CNCF projects separate authentication from authorization rather than implementing their own identity management. Projects such as Loki, Cortex/Mimir, and kube-rbac-proxy delegate authentication to existing infrastructure while focusing on authorization or tenant isolation inside the application itself.
A similar approach could allow OpenCost to remain provider-agnostic and support enterprise deployments without introducing another identity system into the stack.
Possible LFX Scope (subject to maintainer feedback)
If this overall direction makes sense, one possible breakdown for a 12-week mentorship could look something like:
This is only a tentative plan and would naturally evolve based on maintainer feedback.
Open Questions
Some questions I'd especially appreciate input on:
Related Work
In this repo:
Related CNCF projects:
X-Scope-OrgIDheader, no auth inside the storeMy goal with this discussion is simply to validate whether this direction aligns with where maintainers see OpenCost evolving.
If the overall direction looks reasonable, I'd be happy to convert this into a detailed design proposal and formal LFX Mentorship proposal after incorporating feedback.
Looking forward to hearing everyone's thoughts.
cc @ameijer @mbolt35 @nikovacevic @maxvishy