Enable the Kyma environment with a custom identity provider (IdP).
-
Install kubectl oidc-login. This is also needed when you log in to Kyma dashboard, as the dashboard uses the kubeconfig file, and it requires the kubectl oidc-login tool to work.
-
If you choose to use SAP Cloud Identity Services as custom IdP, you have configured your tenant as OpenID Connect (OIDC) provider for your Kyma cluster. For details, see Configure OpenID Connect Application for Authorization Code Flow.
-
Configure the Kyma dashboard URL (
https://dashboard.kyma.cloud.sap
) and the localhost for kubectl authentication (http://localhost:8000
) as allowed callback URLs at your IdP provider, so that authenticated users can be redirected back to the Kyma application. See Redirect URIs, Post Logout Redirect URI Rules.
It is recommended to use SAP Cloud Identity Services tenant as a custom IdP. It allows you to use SAP Cloud Identity Services as a proxy to integrate your corporate identity provider. See Get Your Tenant. You could also configure SAP Cloud Identity Services to use a third-party IdP if you already have one.
When you create a new Kyma instance in the SAP BTP cockpit from the Service Marketplace, you can configure your custom OpenID Connect IdP to authenticate users in your Kyma runtime.
If you've already created your Kyma environment, you can also apply the custom IdP configuration and set up administrators during your Kyma instance update operation by providing the details as an array of strings in the respective fields.
-
Go to Services > Service Marketplace and Creating a Kyma Instance.
-
In the Parameters view, fill in the following information:
-
issuerURL - the URL of the OpenID issuer (use the
https
schema) -
clientID - the client ID for the OpenID client
-
usernameClaim - the name of a custom OpenID Connect claim for specifying a username
-
groupsClaim - the name of a custom OpenID Connect claim for specifying user groups
An identity provider token consists of fields (claims) that are included in it. For example:
{ sub: "[email protected]" groups: ["SAP fans", "Identity Provider", "OpenID"] }
When you configure
usernameClaim
, Kubernetes knows which field (claim) includes the user represented by a given token.Similarly, when you configure
groupsClaim
, Kubernetes knows to which groups the user is assigned. -
signingAlgs - the list of allowed cryptographic algorithms used for token signing. The allowed values are defined by RFC 7518.
-
usernamePrefix - the prefix for all usernames. If you don't provide it, username claims other than “email” are prefixed by the issuerURL to avoid clashes. To skip any prefixing, provide the value as
-
. -
administrators - the list of usernames meant to be administrators. Users identified with those usernames get the role cluster-admin during provisioning of your Kyma runtime.
You can also provide the configuration as a JSON object:
"oidc": { "issuerURL": "{issuerURL}", "clientID": "{clientID}", "usernameClaim": "sub", "groupsClaim": "groups", "signingAlgs": ["RS256"], "usernamePrefix": "-" }, "administrators": [ "[email protected]", "[email protected]" ]
If you want to revert to the default settings, use the following configuration:
"oidc": { "issuerURL": "https://kyma.accounts.ondemand.com", "clientID": "12b13a26-d993-4d0c-aa08-5f5852bbdff6", "groupsClaim": "groups", "signingAlgs": ["RS256"], "usernamePrefix": "-", "usernameClaim": "sub" }, "administrators": [ "[email protected]", "[email protected]" ]
The email addresses must be recognized by
https://kyma.accounts.ondemand.com
. -
-
Select Create.
Your Kyma environment is instantiated with a custom IdP.
Related Information