Exposing and Securing Workloads with API Rules and Istio in Kyma

Explanation

Once a workload is deployed into a Kyma cluster, it is not reachable from outside the cluster by default. Kyma uses Istio as its service mesh and exposes an API Rule custom resource that lets you declare, in a controlled and auditable way, which services should be reachable externally, on which hosts, and under what access strategy. This matters in real SAP integration projects because Kyma workloads frequently act as the target or source of integration flows built in Cloud Integration, or as microservices that SAP applications call directly, so exposing them correctly and securely is a core operational skill, not an optional extra. An API Rule typically references a Kubernetes Service and a host (a subdomain under the cluster's shared domain or a custom domain bound to the subaccount), and defines one or more access strategies per path. Common access strategies include no_auth for public health endpoints, jwt for validating bearer tokens issued by an identity provider such as SAP Cloud Identity Services, and oauth2_introspection style patterns where a gateway validates opaque tokens against an introspection endpoint. In SAP BTP projects, the JWT strategy is most common because SAP Cloud Identity Services integrates cleanly, and API Rules can be configured to check the issuer, audience, and required scopes on incoming tokens before Istio's sidecar proxy allows the request through to the pod. Behind the scenes, every pod in the mesh runs alongside an Istio sidecar proxy that intercepts inbound and outbound traffic. This gives you mutual TLS between services inside the mesh by default in many Kyma configurations, meaning traffic between your own microservices is encrypted and authenticated without your application code doing anything special. This is a meaningful difference from a plain Kubernetes deployment without a service mesh, where you would have to implement mTLS yourself at the application layer. For architects comparing environments, it is worth being explicit that this mesh-level security is a Kyma/Istio capability and should not be assumed present in every Kubernetes distribution. A realistic integration flow looks like this: an external SAP Cloud Integration flow needs to call a custom validation microservice running in Kyma. You deploy the microservice with a ClusterIP Service, create an API Rule exposing a specific path such as /validate on a subdomain, and configure the jwt access strategy pointing at the tenant's identity provider. The Cloud Integration flow is configured with an OAuth2 client credentials artifact that requests a token from the same identity provider, then calls the exposed Kyma host with that token in the Authorization header. Istio's sidecar validates the token signature and claims before the request ever reaches your application code, so your service can trust the caller's identity without implementing token validation itself, though many teams still validate claims in-app for defense in depth. Troubleshooting exposure issues generally starts with checking whether the API Rule was accepted and reconciled successfully, since a rule with an invalid host or a Service selector mismatch will not route traffic even though it appears created. The next check is confirming DNS resolution for the custom or default domain, then verifying the JWKS endpoint of the identity provider is reachable from the cluster, since a common failure mode is a token being rejected because the issuer or audience claim does not match what the API Rule expects. Certificate issues are also common when using custom domains, since the TLS certificate bound to the domain must be valid and correctly referenced. For production readiness, teams should avoid using no_auth on anything beyond simple health checks, should scope JWT validation to specific required scopes rather than accepting any valid token, and should treat API Rule definitions as version-controlled artifacts deployed through the same CI/CD pipeline as the workloads they expose, rather than being edited manually in a cluster.

Code example

# Example API Rule exposing a Kyma microservice with JWT-based access controlapiVersion: gateway.kyma-project.io/v1beta1kind: APIRulemetadata:  name: validation-service-rule  namespace: integration-servicesspec:  host: validation-api.mycompany-cluster.kyma.ondemand.com  service:    name: validation-service    port: 8080  gateway: kyma-system/kyma-gateway  rules:    - path: /health      methods: ["GET"]      accessStrategies:        - handler: no_auth    - path: /validate      methods: ["POST"]      accessStrategies:        - handler: jwt          config:            trusted_issuers:              - "https://mytenant.accounts.ondemand.com"            required_scope:              - "validation.write" # Verifying the rule was accepted# kubectl get apirule validation-service-rule -n integration-services -o wide# kubectl describe apirule validation-service-rule -n integration-services# Look at status.APIRuleStatus.code == OK before assuming traffic will route

Real project scenario

An integration team built a custom address-validation microservice in Kyma that SAP Cloud Integration flows call before posting customer master data into S/4HANA Cloud. Initially the service was exposed with no_auth for speed during development, but during the security review before go-live, the team had to retrofit JWT-based access strategies, coordinate with the identity team to register an OAuth2 client for the Cloud Integration side, and update the API Rule and Cloud Integration OAuth2 credential artifact together. Because the API Rule was stored in a Git repository and deployed via pipeline, the change was reviewed, tested in a non-production cluster first, and rolled out with a clear diff, avoiding a manual, undocumented change directly against the production cluster.

Common mistakes

• Exposing services with no_auth beyond simple health or readiness endpoints, leaving business logic reachable without authentication • Forgetting that an accepted API Rule does not guarantee correct routing if the underlying Service selector or port does not match the deployed workload • Assuming mesh-level mTLS between internal services removes the need for authorization checks at the application layer for sensitive operations • Hardcoding trusted issuer or audience values that differ between test and production identity provider tenants, causing failures only after promotion • Editing API Rules manually in the cluster instead of managing them as version-controlled deployment artifacts, leading to configuration drift

Best practices

• Restrict no_auth access strategies strictly to non-sensitive health or readiness endpoints • Scope JWT validation using required_scope or claim checks rather than accepting any token from a trusted issuer • Store API Rule manifests in version control and deploy them through the same pipeline as application workloads • Validate DNS and TLS certificate configuration for custom domains before relying on them in production traffic paths • Test exposure and authentication changes in a non-production cluster before promoting to production, since access strategy mistakes directly affect security posture

Interview angle

Interviewers use this topic to check whether a candidate understands that Kubernetes networking alone does not provide external exposure or security, and that Kyma adds API Rule and Istio-based constructs on top. Strong answers explain the difference between no_auth, jwt, and other access strategies, describe how mTLS is applied automatically within the mesh via sidecars, and can walk through a concrete failure scenario such as a token being rejected due to an issuer mismatch, showing they have actually operated this rather than only read about it.