SAP BTP Kyma API Rules with destinations and a managed approuter.
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:
where we can get both the issuer and the jwks urls from, for instance:
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:
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
or httpbin bearer endpoint
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.
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:
- 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:
I hope you have enjoyed reading this blog post. Feel free to provide feedback in the comments section below.
Follow me in SAP Community: Piotr Tesny