SAP BTP Kyma runtime offers a number of optionals modules and built-in components .

One of these components is the api gateway. And one of the most commonly used api gateway resources is the api rule.

An API rule is a relatively complex Custom Resource Definition that simplies the task of exposing kubernetes services to the public internet.

Thus, it is paramount to secure access to these services. Let’s see how.

BTP subaccounts come to the rescue.

In a nutshell, a BTP subaccount is a BTP platform tenant grouping access to entitled services in a given region (data center) and a is service provider (SP) as well.

As a SP, it comes with a default SAP ID OIDC identity provider and can be additionally trusted to other OIDC and SAML SSO identity providers including custom IDP providers.

It also features built-in connectivity and destination services and can host a managed approuter to help route the traffic to business applications.

A managed approuter is typically used with the HTML5/Fiori applications (both CAP and non-CAP based) deployed to a BTP subaccount HTML5 repository.

But not only. One of its royal features is a built-in support of dynamic destinations.

SAP Workzone standard edition

You need to subscribe to managed approuter service first, for instance, via a subscription to SAP Workzone standard edition which offers a free service plan, as follows:

Good to know:

• A free application plan means a free tier subscription service:

just create it and you are good to go…

BTP Subaccount as a Service Provider and a tenant.

As aforementioned, a BTP subaccount has a built-in trust to SAP ID OIDC provider, is a service provider and a tenant.

Subsequently, custom workloads are not deployed to a subaccount. They are deployed to one of the three runtime environments, namely CF, kyma and ABAP.

Every workload can be passed a currently logged-in user context as an user-JWT token. The approuter retrieves a user-JWT and passes it along to workloads. The is commonly done using a BTP destination mechanism.

Deploy a kubernetes workload to a kyma runtime

Let’s consider deploying a kubernetes workload to a kyma cluster. We shall be using an API Rule to expose the workload’s service securely to the public internet. And in order to do so, we shall need to define a jwt access strategy.

A jwt access strategy needs to know how to decode a digitally signed user-JWT token and the issuer’s URL as well.

We can conveniently obtain this information via a .well-known/openid-configuration OIDC metadata endpoint, namely:

https://<tenant>.authentication.<region>.hana.ondemand.com/.well-known/openid-configuration

where we can get both the issuer and the jwks urls from, for instance:

• “issuer”:”https://<tenant>.authentication.<region>.hana.ondemand.com/oauth/token”
• “jwks_uri”:”https://<tenant>.authentication.<region>.hana.ondemand.com/token_keys”

Deploy httpbin to a namespace

$ kubectl -n <namespace> create -f https://raw.githubusercontent.com/istio/istio/master/samples/httpbin/httpbin.yaml --kubeconfig ~/.kube/kubeconfig--<shoot>-quovadis.yaml
serviceaccount/httpbin created
service/httpbin created
deployment.apps/httpbin created

Create a secured API Rule

apiVersion: gateway.kyma-project.io/v1beta1
kind: APIRule
metadata:
  labels:
    app.kubernetes.io/name: httpbin
  name: httpbin
  namespace: <namespace>
spec:
  gateway: <istio gateway>
  host: httpbin-anywhere.<custom domain>
  rules:
    - accessStrategies:
        - config:
            jwks_urls:
              - >-
                https://<tenant1>.authentication.<region1>.hana.ondemand.com/token_keys
              - >-
                https://<tenant2>.authentication.<region1>.hana.ondemand.com/token_keys
              - >-
                https://<tenant3>.authentication.<region3>.hana.ondemand.com/token_keys
            required_scope:
              - openid
            trusted_issuers:
              - >-
                https://<tenant1>.authentication.<region1>.hana.ondemand.com/oauth/token
              - >-
                https://<tenant2>.authentication.<region1>.hana.ondemand.com/oauth/token
              - >-
                https://<tenant3>.authentication.<region3>.hana.ondemand.com/oauth/token
          handler: jwt
      methods:
        - GET
        - POST
        - HEAD
        - PUT
        - PATCH
        - DELETE
      path: /.*
      timeout: 300
  service:
    name: httpbin
    port: 8000

Create a subaccount level destination for each of the BTP tenants (subaccounts)

The destination target is the API Rule URL itself.

Thus, even if the httpbin service exposes a number of endpoints, we only need a single URL in the destination definition as depicted below:

and then the connection test should return 401

Good to know:

• The additional destination definition properties are mandatory.

• • HTML5.DynamicDestination: true — that makes it a dynamic destination
  • HTML5.ForwardAuthToken: true — that tells the managed approuter to forward the business user JWT token to the API rule in the Authorization header as a bearer access token

• What if I wanted to use my own OIDC provider in this worklow, instead of relying on a forwarded user token? You can find the answer to this question in this other blogpost, namely: Easy routing with SAP BTP, Kyma runtime API rules

Test your secured workload access

The time has come to test the designed solution. We only need to know:

• the URL of a managed approuter and
• the name of the BTP destination.

A managed approuter URL always follows the below pattern:

• https://<tenant>.launchpad.cfapps.<region>.hana.ondemand.com

As aforementioned, the managed approuter has a built-in support of dynamic destinations with the following pattern:

• <managed approuter url>/dynamic_dest/<destination name>/<verb>

Thus, for instance, to call httpbin headers endpoint

• https://<tenant>.launchpad.cfapps.<region>.hana.ondemand.com/dynamic_dest/httpbin-anywhere/headers

or httpbin bearer endpoint

• https://<tenant>.launchpad.cfapps.<region>.hana.ondemand.com/dynamic_dest/httpbin-anywhere/bearer

In a nutshell, SAP BTP platform with the subaccounts offers a robust and efficient tenancy and service provider mechanism.

One can start with a brand new BTP subaccount in a region of their choice and have their kyma workloads secured with user-JWT with a BTP destination mechanism.

Last but not least, if you were looking for more complex destination definitions design patterns please refer to my previous blogs post on this topic, namely:

• Destinations routing easy with SAP Build Work Zone, standard edition
• Easy routing with SAP BTP, Kyma runtime API rules

where you can find more details with the API rules, the jwt access strategy and the BTP destinations.

On the other hand, if you needed to use the oauth2 introspection access strategy or have a mix of jwt based and oauth2 introspection based strategies in a single API rule, you may refer to this other excellent blogpost, namely:

• SAP BTP, Kyma runtime ORY Hydra OAuth2 Client migration

I hope you have enjoyed reading this blog post. Feel free to provide feedback in the comments section below.

SAP Kyma Community and SAP BTP, Kyma runtime Q&A Tags

Follow me in SAP Community: Piotr Tesny