SAP BTP Kyma runtime offers a number of optional 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 simplifies the task of exposing kubernetes services to the public internet.

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

Putting this all together

BTP subaccounts come to the rescue.

In a nutshell, a BTP subaccount is a BTP platform tenant grouping access to the entitled services in a given region (data center) and is a 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 (launchpad)

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 is a service provider with a built-in trust to SAP ID OIDC 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 workload to a namespace in a kyma cluster

$ 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

Good to know:

a single API rule can be called from multiple destinations with any combination of BTP tenants (subaccounts) and their regions
with the BTP multi-tenancy model one could achieve a full automation of on-boarding/off-boarding consumer tenants accessing application workloads deployed to kyma clusters
if you wanted to consider and apply a BTP tenancy model towards workloads deployed to kyma clusters, please refer to my other blog post on this very topic, namely: Developing multi-tenant SaaS applications easy with SAP BTP, Kyma runtime.

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

Indeed, calling a kyma-hosted micro-service from the comfort of a managed launchpad service with the integrated SAP BTP security has never been easier.

All that with little to no code.

Conclusion

In a nutshell, SAP BTP platform with the subaccounts offers a robust and efficient tenancy and service provider with integrated security and destination mechanisms.

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.

The BTP destinations are key to the API rule protection design pattern.

Most of the SAP products and engineering frameworks do support BTP destinations natively.

Think about CAP and BAS or SAP Build Apps. Think about SAP Digital Workplace, SAP Analytics Cloud or Microsoft Teams integrations

From the moment, the access to kyma workloads can be secured with BTP destinations, these workloads blend easily not only into the entire SAP BTP ecosystem but also become an integral part of the Intelligent Enterprise delivery.

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:

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