With the Kyma 2.0 release, it is possible to configure the access to the Kyma runtime via a Custom / Corporate Identity Provider. This can be done either during provisioning of a Kyma runtime or later on via an update.

Note:

• This is different from earlier way of doing it via XSUAA in the subaccount.
• Configuring the identity provider is optional and if not configured, the default accounts.sap.com will be used.

What benefits it provides?

• You already use a corporate identity provider such as Azure Active Directory / Auth0 / SAP Cloud Identity Service (IAS)

• You can use the same user base without the need to replicate your user data.

• Access to all applications can be centrally managed in your corporate identity provider.

• Role-based access control is simplified as you can configure groups for your users in the corporate identity provider. They can then be enforced via Kubernetes ClusterRoleBinding and RoleBinding in your Kyma runtime

Configuring the Identity Provider in Kyma runtime

Prerequisites

• You already have an Identity Provider configured.
• It supports OIDC
• In case, it only supports SAML, you can set up SAP Cloud Identity Service tenant and use the Identity Provider as a proxy

Either during provisioning or later on as an update, it is possible to provide the various parameters for the Kyma runtime configuration.

Among other configurations, you can configure your custom OpenID Connect IdP to authenticate users in your Kyma runtime.

{
    "administrators": [
        "{Id of the default administrators, this can be an email or login-id depending upon which assertion attribute is used}"
    ],
    "oidc": {
        "clientID": "{Client Id of the configured OIDC application in the identity provider}",
        "groupsClaim": "{assertion attribute to be used for groups}",
        "issuerURL": "{Issuer URL}",
        "signingAlgs": [
            "RS256"
        ],
        "usernameClaim": "{name of the assertion attribute to be used for user name}",
        "usernamePrefix": "-"
    }
}

Note: The users accessing the dashboard still need to have an account at accounts.sap.com. This is used for the initial access to the empty dashboard page (http://dashboard.kyma.cloud.sap). The access to the runtime itself will be based on the configured identity provider.

Role-based access control

You can configure groups or other similar permission configurations for users in the Identity provider. Then, using the groups, you can create RoleBinding and ClusterRoleBinding in the Kyma runtime. The same can also be configured for individual users instead of groups if required.

For example,

Let say in your Identity Provider you have a group called kyma-dev-ns. You intend to provide access to all users in this group to the dev namespace in my Kyma runtime.

You can create a RoleBinding for this.

Based on your requirements, you can use one of the pre-existing Roles or create one for yourself.

Similarly, you can use ClusterRoleBinding in case you need to grant access at the cluster level instead of namespace.

The configuration and management effort is considerably reduced as you create a RoleBinding once per group.

Please check out this reference sample about using Auth0 as an Identity Provider for Kyma access.

Takeaways

• Configuring Kyma access for admins and developers has considerably improved with Kyma 2.0
• You can configure Identity Provider during provisioning as well as later on via update
• The access is no longer based on XSUAA. Thus, no Roles/RoleCollections need to be defined in subaccount
• Configure RoleBinding and ClusterRoleBinding in Kyma runtime to grant access to individual users as well as groups for development and admin access.