OIDC is only officially supported on Kubecost Enterprise plans.
This guide will take you through configuring OIDC for Kubecost using a Microsoft Entra ID (formerly Azure AD) integration for SSO and RBAC.
Before following this guide, ensure that:
Kubecost is already installed
Kubecost is accessible via a TLS-enabled ingress
You are established as a Cloud Application Administrator in Microsoft. This may otherwise prevent you from accessing certain features required in this tutorial.
In the Microsoft Entra admin center, select Microsoft Entra ID (Azure AD).
In the left navigation, select Applications > App registrations. Then, on the App registrations page, select New registration.
Select an appropriate name, and provide supported account types for your app.
To configure Redirect URI, select Web from the dropdown, then provide the URI as https://{your-kubecost-address}/model/oidc/authorize.
Select Register at the bottom of the page to finalize your changes.
After creating your application, you should be taken directly to the app's Overview page. If not, return to the App registrations page, then select the application you just created.
On the Overview page for your application, obtain the Application (client) ID and the Directory (tenant) ID. These will be needed in a later step.
Next to 'Client credentials', select Add a certificate or secret. The 'Certificates & secrets' page opens.
Select New client secret. Provide a description and expiration time, then select Add.
Obtain the value created with your secret.
Add the three saved values, as well as any other values required relating to your Kubecost/Microsoft account details, into the following values.yaml template:
If you are using one Entra ID app to authenticate multiple Kubecost endpoints, you must to pass an additional redirect_uri parameter in your authURL, which will include the URI you configured in Step 1.4. Otherwise, Entra ID may redirect to an incorrect endpoint. You can read more about this in Microsoft Entra ID's troubleshooting docs. View the example below to see how you should format your URI:
First, you need to configure an admin role for your app. For more information on this step, see Microsoft's documentation.
Return to the Overview page for the application you created in Step 1.
Select App roles > Create app role. Provide the following values:
Display name: admin
Allowed member types: Users/Groups
Value: admin
Description: Admins have read/write permissions via the Kubecost frontend (or provide a custom description as needed)
Do you want to enable this app role?: Select the checkbox
Select Apply.
Then, you need to attach the role you just created to users and groups.
In the Azure AD left navigation, select Applications > Enterprise applications. Select the application you created in Step 1.
Select Users & groups.
Select Add user/group. Select the desired group. Select the admin role you created, or another relevant role. Then, select Assign to finalize changes.
Update your existing values.yaml with this template:
Use your browser's devtools to observe network requests made between you, your Identity Provider, and Kubecost. Pay close attention to cookies and headers.
Run the following command:
Search for oidc in your logs to follow events. Pay attention to any WRN related to OIDC. Search for Token Response, and try decoding both the access_token and id_token to ensure they are well formed. Learn more about JSON web tokens.
You can find more details on these flags in Kubecost's cost-analyzer-helm-chart repo README.
Gluu is an open-source Identity and Access Management (IAM) platform that can be used to authenticate and authorize users for applications and services. It can be configured to use the OpenID Connect (OIDC) protocol, which is an authentication layer built on top of OAuth 2.0 that allows applications to verify the identity of users and obtain basic profile information about them.
To configure a Gluu server with OIDC, you will need to install and set up the Gluu server software on a suitable host machine. This will typically involve performing the following steps:
Install the necessary dependencies and packages.
Download and extract the Gluu server software package.
Run the installation script to set up the Gluu server.
Configure the Gluu server by modifying the /etc/gluu/conf/gluu.properties file and setting the values for various properties, such as the hostname, LDAP bind password, and OAuth keys.
Start the Gluu server by running the /etc/init.d/gluu-serverd start command.
You can read for more detailed help with these steps.
Note: Later versions of Gluu Server also support deployment to Kubernetes environments. You can read more about their Kubernetes support .
Once the Gluu server is up and running, you can connect it to a Kubecost cluster by performing the following steps:
Obtain the OIDC client ID and client secret for the Gluu server. These can be found in the /etc/gluu/conf/gluu.properties file under the oxAuthClientId and oxAuthClientPassword properties, respectively.
In the Kubecost cluster, create a new OIDC identity provider by running kubectl apply -f oidc-provider.yaml command, where oidc-provider.yaml is a configuration file that specifies the OIDC client ID and client secret, as well as the issuer URL and authorization and token endpoints for the Gluu server.
In this file, you will need to replace the following placeholders with the appropriate values:
<OIDC_CLIENT_ID>: The OIDC client ID for the Gluu server. This can be found in the /etc/gluu/conf/gluu.properties file under the oxAuthClientId property.
<OIDC_CLIENT_SECRET>: The OIDC client secret for the Gluu server. This can be found in the /etc/gluu/conf/gluu.properties file under the oxAuthClientPassword property.
<GLUU_SERVER_HOSTNAME>: The hostname of the Gluu server.
<BASE64_ENCODED_OIDC_CLIENT_ID>: The OIDC client ID, encoded in base64.
<BASE64_ENCODED_OIDC_CLIENT_SECRET>: The OIDC client secret, encoded in base64.
Set up a Kubernetes service account and bind it to the OIDC identity provider. This can be done by running the kubectl apply -f service-account.yaml command, where service-account.yaml is a configuration file that specifies the name of the service account and the OIDC identity provider.
In this file, you will need to replace the following placeholders with the appropriate values:
<SERVICE_ACCOUNT_NAME>: The name of the service account. This can be any name that you choose.
<GLUU_SERVER_HOSTNAME>: The hostname of the Gluu server.
<OIDC_CLIENT_ID>: The OIDC client ID for the Gluu server. This can be found in the /etc/gluu/conf/gluu.properties file under the oxAuthClientId property.
Note: You should also ensure that the
kubernetes.io/oidc-issuer-url,kubernetes.io/oidc-client-id,kubernetes.io/oidc-username-claim, andkubernetes.io/oidc-groups-claimannotations are set to the correct values for your Gluu server and configuration. These annotations specify the issuer URL and client ID for the OIDC identity provider, as well as the claims to use for the username and group membership of authenticated users.
Once these steps are completed, the Gluu server should be configured to use OIDC and connected to the Kubecost cluster, allowing users to authenticate and authorize themselves using their Gluu credentials.
OIDC and RBAC are only officially supported on Kubecost Enterprise plans.
The OIDC integration in Kubecost is fulfilled via the .Values.oidc configuration parameters in the Helm chart.
authURL may require additional request parameters depending on the provider. Some commonly required parameters are client_id=*** and response_type=code. Please check the provider documentation for more information.
Please refer to the following references to find out more about how to configure the Helm parameters to suit each OIDC identity provider integration.
Auth0 does not support Introspection; therefore we can only validate the access token by calling /userinfo within our current remote token validation flow. This will cause the Kubecost UI to not function under an Auth0 integration, as it makes a large number of continuous calls to load the various components on the page and the Auth0 /userinfo endpoint is rate limited. Independent calls against Kubecost endpoints (eg. via cURL or Postman) should still be supported.
Once the Kubecost application has been successfully integrated with OIDC, we will expect requests to Kubecost endpoints to contain the JWT access token, either:
As a cookie named token,
As a cookie named id_token (Set .Values.oidc.useIDToken = true),
Or as part of the Authorization header Bearer token
The token is then validated remotely in one of two ways:
POST request to Introspect URL configured by identity provider
If no Introspect URL configured, GET request to /userinfo configured by identity provider
If skipOnlineTokenValidation is set to true, Kubecost will skip accessing the OIDC introspection endpoint for online token validation and will instead attempt to locally validate the JWT claims.
Setting skipOnlineTokenValidation to true will prevent tokens from being manually revoked.
This parameter is only supported if using the Google OAuth 2.0 identity provider
If the hostedDomain parameter is configured in the Helm chart, the application will deny access to users for which the identified domain is not equal to the specified domain. The domain is read from the hd claim in the ID token commonly returned alongside the access token.
If the domain is configured alongside the access token, then requests should contain the JWT ID token, either:
As a cookie named id_token
As part of an Identification header
The JWT ID token must contain a field (claim) named hd with the desired domain value. We verify that the token has been properly signed (using provider certificates) and has not expired before processing the claim.
To remove a previously set Helm value, you will need to set the value to an empty string: .Values.oidc.hostedDomain = "". To validate that the config has been removed, you can check the /var/configs/oidc/oidc.json inside the cost-model container.
Kubecost's OIDC supports read-only mode. This leverages OIDC for authentication, then assigns all authenticated users as read-only users.
Use your browser's devtools to observe network requests made between you, your Identity Provider, and your Kubecost. Pay close attention to cookies, and headers.
Search for oidc in your logs to follow events
Pay attention to any WRN related to OIDC
Search for Token Response, and try decoding both the access_token and id_token to ensure they are well formed (https://jwt.io/)
Code reference for the below example can be found here.
For further assistance, reach out to support@kubecost.com and provide both logs and a HAR file.
Create a new .
Navigate to Realm Settings > General > Endpoints > OpenID Endpoint Configuration > Clients.
Select Create to add Kubecost to the list of clients. Define a clientID. Ensure the Client Protocol is set to openid-connect.
Select your newly created client, then go to Settings.
Set Access Type to confidential.
Set Valid Redirect URIs to http://YOUR_KUBECOST_ADDRESS/model/oidc/authorize.
Set Base URL to http://YOUR_KUBECOST_ADDRESS.
The for Keycloak should be as follows:
