Role Based Access Controls in Kubecost

[kc-creynold]

What problem are you trying to solve?
For customers that are running kubernetes as a enterprise solution, they want to offer their tenants the ability to track/view/monitor only for their namespace/project/etc only and not have the ability to see other tenants data/spend/underling assets, health, settings, etc in the UI/API. By bringing in RBAC and applying contextually aware UI elements we can offer separation tenants within a single KC cluster.

Describe the solution you'd like

Say we have 2 namespaces in KC.

• Project 1
• Project 2

We have 3 users.

• User 1 - non admin user
• User 2 - non admin user
• User 3 - admin user

User 1 is a member of only project 1, therefore they should only see the cost allocations reports that involved project 1. They should not be able to see the settings page, the assets page unless they have assets that belong to their project, Savings should only apply to their project/namespace, they probably don't need to see the health page, and reports and alerts should only apply to their namespace.

User 2 is an member of project 1 and project 3, therefore they should only see relevant data in the UI for for project 1 and 3.

User 3 is an admin user and should be able to see/change any and all within the UI

The UI would be built around the permission the user brings with them when logging in via SSO/SAML based on their groups in their identity management platform. Thus preventing users from seeing other tenants cost, workloads, infrastructure, etc.

Admins would be able to create custom roles/groups, etc that they would be able to define what a user can and can't see.

Describe alternatives you've considered
N/A - advanced reporting will help with this to a degree

How would users interact with this feature?
The admin for KC would add SAML/SSO in front of KC, then roles/access can be pulled from the identity manager platform of the customer. From there KC UI would load the elements related to that users permissions.

[AjayTripathy]

Just to check in, this has been implemented for the allocations page and api, and this request is to ensure that this implemented throughout the app?

[kc-creynold]

Correct.

Right now there are three pre-defined roles (https://guide.kubecost.com/hc/en-us/articles/4407595985047-User-Management-SSO-SAML) that allow for filtering based on filters.json

Most of the Govt customers use OU mapping to manage application RBAC via keycloak and need a higher level of granularity in turning things on/off. In addition they use SSO via a CAC (X509) card to pass to the application. So this might need to be two feature requests, x509/keycloak and additional RBAC in the app.

[AjayTripathy]

There's more than those 3 defined roles; Editor and Reader can already be scoped to namespaces, though it is in beta: https://docs.google.com/document/d/1o3jzlHg9lHhz5hNCaTERXVzVrwLe1R7YTKGTxt6RYTM/edit

@kc-creynold

[kc-creynold]

Ok cool, good to know @AjayTripathy. Could we take it a step further and have a mappings file that would map a User identity management OUs, to roles created in the SAML filters once we have full rbac? This way a users access is tracked and managed/maintained upstream in a system that meets/maintains auditing requirements/logging requirements, etc.

[dwbrown2]

@AjayTripathy is that mapping that @kc-creynold mentions not currently supported?

Also, I think there's overlap with discussion in kubecost/features-bugs#39

They should not be able to see the settings page.

@kc-creynold more thoughts on this one? What I commonly see is that they would get a limited view or read-only view of Settings as opposed to not be able to access at all.

[AjayTripathy]

https://github.com/kubecost/cost-analyzer-helm-chart/blob/develop/cost-analyzer/values.yaml#L162 @kc-creynold do you think this idea is sifficient? you can use SAML attributes to perform mappings of groups / any arbitrary thing to users.

[kc-creynold]

@dwbrown2 yes there is some overlap with that one. The request I have had from a few PubSec customers extends beyond just the assets page. Say for an application/namespace owner that wants to log into KC to view their reports, etc for just their namespace. The settings page has no bearing/use for that user.

@AjayTripathy that would work, as long as the SAML attributes can be mapped to a OU/group from the iden manager platform

[dwbrown2]

@Adam-Stack-PM proposal is to review closely as part of 1.99!

[Adam-Stack-PM]

@dwbrown2 Awesome appreciate the help getting this assigned to a release target. Labeled and added to our product pillar tracking doc.

[cr-benchmarkcorp]

Having worked with multiple Global Organizations (including currently working with one previewing KubeCost), it is desirable for the organization to control which accounts have access to view OCC Cloud Costs. It would be very beneficial to also restrict OCC costs tagged to various namespaces (etc) as part of the RBAC implementation. This would allow companies to maintain internal financial privacy where it is a business requirement to do so.

[Adam-Stack-PM]

@cr-benchmarkcorp Thanks for this insightful product feedback. Very much appreciated.

[patrickbardo]

I would also like to echo the need for this feature. As the platform team, we want to give our tenants this tool to monitor their spend, but want to limit their access to the settings page (and possibly other pages we haven't fully tested yet).

[AjayTripathy]

Proposal that we look at this for v1.99

[mmurph3]

Another customer needing this. Including RBAC with filtering for labels and annotations. tix # 2877

[AjayTripathy]

We've expanded Role Based Access filtering to support labels and annotations in v1.99. Part 2 is to enable this in assets, which we expect in v1.100.

[mmurph3]

Another use-case from a customer on how RBAC would work:

Hiding the front page “Possible Savings” and “Cloud Cost” panes from regular users. The first being inaccurate and the second being something our FinOps team might want to keep confidential from developers at the org.

[AjayTripathy]

@teevans @kwombach12 @kwombach12 ... I think this needs to be moved and broken up into some sort of epic. We support a ton of functionality and it's probably not clear from this giant ticket what we do and do not support. Can you all help me break this one up?

We need to:

1. Enable this for Assets
2. Support in Cloud costs and savings.

Once we've broken this up let's close this one.

[kwombach12]

@AjayTripathy I think we have a separate issue for enabling this in Assets: kubecost/features-bugs#39
I can create a separate issue for adding this for Cloud Costs & Savings

[kwombach12]

kubecost/features-bugs#12

[AjayTripathy]

Thank you! Closing.