Product Information
Security in Kyma environment – What’s new for SAP BTP, Kyma Runtime?
|
|
|
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:
|
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
|
custom OIDC metadata URL.
|
DEX Issuer URL
|
custom OIDC Issuer URL
|
DEX JWKS URI URL
|
custom OIDC JWKS URI URL
|
|
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: |
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): |
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? |
|
| 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: /.*
