User Management - SSO/OIDC

Note: OIDC capabilities are only included with a Kubecost Enterprise Subscription.
Helm configuration
The OIDC integration in Kubecost is fulfilled via the .Values.oidc configuration parameters in the Helm chart.
oidc:
   enabled: true
   clientID: "" # application/client client_id parameter obtained from provider, used to make requests to server
   clientSecret: "" # application/client client_secret parameter obtained from provider, used to make requests to server
   secretName: "kubecost-oidc-secret" # k8s secret where clientSecret will be stored
   authURL: "https://my.auth.server/authorize" # endpoint for login to auth server
   loginRedirectURL: "http://my.kubecost.url/model/oidc/authorize" # Kubecost url configured in provider for redirect after authentication
   discoveryURL: "https://my.auth.server/.well-known/openid-configuration" # url for OIDC endpoint discovery
#  hostedDomain: "example.com" # optional, blocks access to the auth domain specified in the hd claim of the provider ID token
Note: 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.
Supported identity providers
Please refer to the following references to find out more about how to configure the Helm parameters to suit each OIDC identiy provider integration.
​Auth0 docs​
​Azure docs​
​Gluu docs​
​Keycloak (see below)​
​Google OAuth 2.0 docs​
​Okta docs​
Note: 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.
Keycloak setup
1.Create a new Keycloak Realm.
2.Navigate to "Realm Settings" -> "General" -> "Endpoints" -> "OpenID Endpoint Configuration" -> "Clients".
3.Click "Create" to add Kubecost to the list of clients. Define a clientID. Ensure the "Client Protocol" is set to openid-connect.
4.Click on your newly created client, then go to "Settings".
1.Set "Access Type" to confidential.
2.Set "Valid Redirect URIs" to http://YOUR_KUBECOST_ADDRESS/model/oidc/authorize.
3.Set "Base URL" to http://YOUR_KUBECOST_ADDRESS.
The .Values.oidc for Keycloak should be as follows:
oidc:
  enabled: true
  # This should be the same as the `clientID` set in step 3 above
  clientID: "YOUR_CLIENT_ID"
  # Find this in Keycloak UI by going to your Kubecost client, then clicking on "Credentials".
  clientSecret: "YOUR_CLIENT_SECRET"
  # The k8s secret where clientSecret will be stored
  secretName: "kubecost-oidc-secret"
  # The login endpoint for the auth server
  authURL: "http://YOUR_KEYCLOAK_ADDRES/realms/YOUR_REALM_ID/protocol/openid-connect/auth?client_id=YOUR_CLIENT_ID&response_type=code"
  # Redirect after authentication
  loginRedirectURL: "http://YOUR_KUBECOST_ADDRESS/model/oidc/authorize"
  # Navigate to "Realm Settings" -> "General" -> "Endpoints" -> "OpenID Endpoint Configuration". Set to the discovery URL shown on this page.
  discoveryURL: "YOUR_DISCOVERY_URL"
Token validation
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, or
as part of the Authorization header Bearer token
The token is then validated remotely in one of two ways:
1.POST request to Introspect URL configured by identity provider
2.If no Introspect URL configured, GET request to /userinfo configured by identity provider
Hosted domain
Note: 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, or
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.
User Management - SSO/SAML/RBAC
Tuning Resource Consumption
Last modified 1mo ago