{% hint style="info" %} Teams is a Kubecost Enterprise only feature. {% endhint %}
Teams enables Role-Based Access Control (RBAC) in Kubecost's UI, allowing you to define a granular set of permissions for your users. These permissions include enabling or disabling pages within Kubecost as well as scoping those pages down to even finer levels with filters.
Before using the Teams page, make sure you have configured SAML or OIDC with a provider of your choice. Teams cannot work independent of one of these two IAM protocols.
In order to use teams, you must have the Kubecost PersistentVolume enabled in your Helm values. This is enabled by default and no action is needed unless you have previously disabled it. PersistentVolume is enabled via:
persistentVolume:
enabled: trueIf this is your first time using Teams, consult the Getting started section below. For additional team creation, see the Adding a team section.
If you previously had teams enabled and are upgrading from a version of Kubecost prior to 2.6, see the Upgrading section below.
Using the teams feature involves two parts: enabling the feature via Helm and creating teams. While teams may be created via either Helm values or the UI, which are mutually exclusive, it must always be enabled via Helm. The two methods of creating teams are shown below.
In order to enable teams, enable RBAC for your desired IAM protocol (SAML or OIDC) but do not define any values under the respective groups[] list. If groups are defined, this will default the installation to the earlier simple RBAC and not the newer teams RBAC. An example of how to enable the new teams RBAC in Helm when using OIDC is shown below.
oidc:
enabled: true
rbac:
enabled: trueThe first person to log in will be added to a default team with admin-level access. They will then be able to configure teams through the UI on the Teams page.
{% hint style="warning" %} Configuring teams through Helm will disable configuration of teams through the UI. {% endhint %}
Kubecost allows teams to be defined in Helm values obviating the need to create them in the UI. Note that Teams must still be enabled using Helm regardless of if configuration is done in the UI or via Helm by enabling RBAC within your desired protocol config, as above.
An example values snippet is shown below for the creation of a team in Helm.
teams:
# teamsConfigMapName: teams-configmap-name
teamsConfig:
- id: ''
name: helm-team
roles:
- id: ''
name: helm-role
description: helm configured role
pages:
showOverview: true
showAllocation: true
showAsset: true
showCloudCost: true
showClusters: true
showExternalCosts: true
showNetwork: true
showCollections: true
showReports: true
showInsights: true
showActions: true
showAlerts: true
showBudgets: true
showAnomalies: true
showEfficiency: true
showSettings: true
permissions: admin
routes: []
allocationFilters:
- key: cluster
operator: ":"
value: cluster-one
assetFilters: []
cloudCostFilters: []
claims:
NameID: [email protected]Configure at least one team under teamsConfig with an associated role under the team's roles.
Alternatively, a ConfigMap can be created manually, with teamsConfigMapName set to this ConfigMap's name.
apiVersion: v1
data:
rbac-teams-configs.json: '[
{
"claims": {
"NameID": "[email protected]"
},
"id": "",
"name": "helm-team",
"roles": [
{
"allocationFilters": [
{
"key": "cluster",
"operator": ":",
"value": "cluster-one"
}
],
"assetFilters": [],
"cloudCostFilters": [],
"description": "helm configured role",
"id": "",
"name": "helm-role",
"pages": {
"showActions": true,
"showAlerts": true,
"showAllocation": true,
"showAnomalies": true,
"showAsset": true,
"showBudgets": true,
"showCloudCost": true,
"showClusters": true,
"showCollections": true,
"showEfficiency": true,
"showExternalCosts": true,
"showInsights": true,
"showNetwork": true,
"showOverview": true,
"showReports": true,
"showSettings": true
},
"permissions": "admin",
"routes": []
}
]
}
]'
kind: ConfigMap
metadata:
name: <your-configmap-name>
namespace: <your-kc-namespace>Note that setting a manually-configured ConfigMap name will override teamsConfig.
For more information about teams and roles, see the Adding a team section below.
Claims are part of the Identity Provider (IdP) response that provide information about the authenticated user. For SAML, these are relayed as part of the SAML response. For OIDC, these are returned as part of the access or ID tokens.
Kubecost Teams uses these claims to map users to teams. As long as a group or attribute defined in your IdP is returned as part of the authorization process in the SAML response/OIDC token(s), it can be used in teams.
For example, in OIDC, an ID token may contain a certain number of claims.
{
"sub": "11111111",
"name": "John Example",
"email": "[email protected]",
"iss": "https://authserver.com",
"groups": [
"kubecost_admins",
],
"iat": 1735722061,
"exp": 1735722062,
}While some of these claims (e.g. iss, iat, exp) are set automatically by the IdP and are unsuitable for matching, others (e.g. groups, name, email) can be used to map a Kubecost team to the user.
After initial configuration, more teams and roles can be added through the Teams page in the UI provided they have not been defined via Helm.
A team matches user claims from your configured IdP to a set of roles. Each role is essentially a set of permissions, including access level (admin/read-only/editor), page enablement states, filters, and so on.
Each team can have several roles, and each user may map to several teams. A team without a role has no permissions.
Therefore, to have permissions when using Teams, each prospective user must have at least one team with at least one role.
Each team requires one or more roles, which act as sets of user permissions. If you have already created a role or want to use an existing one, go on to the next step.
To add a role follow the steps below.
- Click the New Role button on the roles page.
- Add a role name. Note that this must be unique, and multiple roles cannot share the same name.
- Add a description of the role.
- Choose the role's access level. This can be Admin, Read Only, or Editor.
- Define which pages can be viewed by users with the role. If any Monitoring pages are shown, you may additionally define a filter that will apply to the contents of this page.
To add a team follow the steps below.
- Click the New Team button on the teams page.
- Add a team name. Note that this must be unique, and multiple teams cannot share the same name.
- Define user claims. For more information on what a claim is, see the Claims section above. Note that any overlap between a user's claim data from the IdP and a team's claims will assign the user to the team, even if there are other claims specified in the Team.
- Add one or more roles.
On login, the user with the associated claims will be assigned the permissions of their team(s) role(s).
Note that, depending on the claims set, a user may have multiple teams. Also note that a team can have multiple roles. For more info, see the Multiple teams section below.
If a user has multiple roles (either through having multiple teams, a team with multiple roles, or both), they will be assigned an additive union of the permissions defined by each role.
Asset, Allocation, and Cloud Cost filters are ANDed together within a role, and then ORed together within both a set of roles in a team and a set of teams for a user.
For example, if a user is assigned both roles Role 1 and Role 2 with the following Allocation filters:
Role 1:
cluster IS cluster-1, cluster-2
namespace IS kubecost
Role 2:
cluster IS cluster-3
namespace IS dev
The user will gain a combined filter of ((cluster = cluster-1 OR cluster = cluster-2) AND namespace = kubecost) OR (cluster = cluster-3 AND namespace = dev).
Permissions level will respect only the highest level out of all roles for all teams assigned to a user. The order of precedence is Admin > Editor > Read Only.
Combined page view permissions will enable any page marked as such in any one of a user's roles. Otherwise, the page is designated as disabled. Essentially, if any of the user's roles has a page enabled, that page will be enabled in the user's combined permissions set. Only if none of the user's roles have a page enabled is it disabled for them.
Prior to Kubecost 2.6, Teams existed with more limited functionality. This is referred to as legacy Teams.
Legacy teams provided a limited set of access control capabilities.
- Functionality for SAML environments
- Allocation filtering
- Ability to assign a team a permissions level (under legacy teams previously referred to as a "Role") of Admin, Read Only, or Editor
Post-2.6 Teams, in addition to all the functionality provided by legacy Teams, supports additional capabilities.
- Support for OIDC and SAML authentication
- Asset and Cloud Cost filters along with existing Allocation filters
- Individual page enable/disable functionality
- Ability to assign teams based on OIDC ID/Access token claims or claims returned in SAML response
If upgrading to 2.6+ with existing teams, no config changes are required. Kubecost will attempt to automatically migrate existing legacy Teams teams on pod startup.
For each existing legacy team, a role and associated team will be created. The Allocation filter and permissions level will be migrated into the new role, with the SAML email claim being added to the team.
Kubecost allows configuration of a simple version of RBAC in the Helm chart (for example, see the config for Entra ID). This is mutually exclusive with Teams.
If any configuration is specified under saml.rbac.groups or oidc.rbac.groups, this will enabled simple RBAC, ignoring any configured teams.
The Kubecost aggregator container handles all operations relating to Teams. Viewing the logs may allow you to troubleshoot any issues.
If a state where invalid or incorrect teams are causing access issues in Kubecost, teams config can be deleted by running the below commands.
kubectl exec $POD -- sh -c 'rm -rf /var/configs/rbac_teams.json'and
kubectl exec $POD -- sh -c 'rm -rf /var/configs/roles.json'After this, on pod restart, Teams should recreate these stores as empty stores.