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.
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.
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:
just create it and you are good to go…
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.
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:
$ 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
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
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 time has come to test the designed solution. We only need to know:
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.
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.
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:
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