Security in Kyma environment – What's new for SAP BTP, Kyma Runtime?

[quovadis]

SAP software is renowned for its stringent security standards. As explained in Kyma 2.0 release notes, Open Source Kyma 2.0 brings a number of security changes to SAP BTP, Kyma Runtime (SKR). In a nutshell, what has changed is the user/cluster authentication (with OIDC) and authorisations (with RBAC). As a result, DEX and a few other authentication and authorisation components were deprecated and removed.

This blog post focuses on the latter, as the removal of DEX as a static OIDC IDP (OpenID Connect Identity Provider) has a direct impact on API Rules managed and protected with the JWT strategy.

Good to know:

• These changes are summerized in Security in the Kyma Environment | SAP Help.

Putting it all together

The API rules in Kyma support a number of security strategies, for instance JWT and OAuth2.

As aforementioned, with Open Source Kyma 2.0 release, the DEX component has been deprecated and removed altogether:

Ory Oathkeeper without Dex
With Kyma 2.0, the Dex component becomes deprecated. Therefore, Ory Oathkeeper will no longer use Dex to verify JWT tokens. Existing API Rules that have a JWT access strategy defined must be enriched with an individual jwks_url parameter pointing to a custom OpenID Connect-compliant identity provider.

The API Rules with JWT handlers hardwired to DEX IDP will need to be changed to a custom OpenID Connect (OIDC) Identity Provider as follows:

DEX IDP - (Kyma 1.x built-in OIDC service)	OIDC-compliant IDP provider
DEX OIDC metadata https://dex.<cluster hostname>.<cluster domain>/.well-known/openid-configuration	custom OIDC metadata URL. Typically this will be the OIDC provider host URL with the .well-known/openid-configuration suffix.
DEX Issuer URL https://dex.<cluster hostname>.<cluster domain>	custom OIDC Issuer URL this is the OIDC provider host URL
DEX JWKS URI URL https://dex.<cluster hostname>.<cluster domain>/keys	custom OIDC JWKS URI URL JWKS URI URL is a pointer to a json array that will be used to validate the JWT digital signature by the callee.
A JWT token fetched from DEX is  a so-called user JWT token representing a OIDC user identity present in the cluster kubeconfig… Here goes an example of DEX fetched JWT token: https://github.com/kyma-project/examples/tree/main/gateway	The issuer's token endpoint will be called [by a custom OAuth2 client] to generate the JWT token. Here goes an example of a user-agnostic JWT token, the client id is used as the technical user name (sub claim — subject): https://blogs.sap.com/2021/11/22/hardening-access-to-sap-kyma-runtime-apis-with-jwt-tokens./

An example of how to configure a function API rule combining several access strategies is in the appendix.

Conclusion

The below table attempts to address the most common questions you may have in the aftermath of DEX removal:

Questions	Answers
What are the DEX replacement options ?	Pretty much any OIDC-compliant provider can do. But the choice will depend very much on the answer to the next question.
What authorisation grant type to choose from?	client credentials grant type (basic authentication, technical user) authorization code  grant type (3-legged authentication, business user) saml bearer assertion grant type (2-legged authentication, business user)
How to retrieve a (user) JWT token ?	To start with, you may refer to the following blog post that describes the BTP XSUAA as a simple, affordable OIDC Identity Provider used to implement a JWT strategy.
How to call a JWT protected API Rule endpoint?	Simply put the retrieved JWT (bearer access token) in the Authorization header and make the API call. Please consider if you are using this endpoint from javascript in a browser, the Authorization header will trigger the CORS flow.

If you have further questions around Kyma and security topics in particular, feel free to post them in the comments area of this blog or ask the broader SAP Community.

To stay up to date with everything on Kyma, you may want to visit our Kyma topic page. 

 

 

---

Appendix

An example of an API rule for a kyma function endpoints with multiple access strategies, namely jwt with several handlers and allow.



 

spec:

  gateway: kyma-gateway.kyma-system.svc.cluster.local

  rules:

    - accessStrategies:

        - config:

            jwks_urls:

              - >-

                https://auth.pingone.eu/<env>/as/jwks

              - >-

                https://dev-12345678.okta.com/oauth2/<env>/v1/keys

              - >-

                https://12345678trial.authentication.eu10.hana.ondemand.com/token_keys

            trusted_issuers:

              - https://auth.pingone.eu/<env>/as

              - https://dev-12345678.okta.com/oauth2/<env>;

              - >-

                https://12345678trial.authentication.eu10.hana.ondemand.com/oauth/token

          handler: jwt

      methods:

        - PUT

        - POST

        - PATCH

        - HEAD

        - GET

        - DELETE

      path: /getecptoken

    - accessStrategies:

        - config: {}

          handler: allow

      methods:

        - GET

      path: /.*

 

---