Deploying and Exposing a Service Securely in Kyma Runtime

Explanation

Once a Kyma environment is provisioned, the practical work of an intermediate consultant centers on three activities: getting a workload running, exposing it securely to callers, and wiring it to other BTP services it needs to consume, such as Destination service, Connectivity service, or an event broker. This lesson focuses on that end-to-end flow because it is the most common day-to-day task in real BTP integration projects. Deployment typically starts with a container image built from source and pushed to a registry accessible to the cluster, often a private registry secured with pull secrets stored as Kubernetes Secrets in the target namespace. The Deployment resource then references that image, and a Service resource provides a stable internal DNS name and load-balanced access across pod replicas. This is standard Kubernetes behavior; Kyma does not change it, but it layers additional resources on top for SAP-specific needs. Exposing a service outside the cluster is where Kyma diverges most visibly from raw Kubernetes. Kyma includes an Istio-based API Gateway component, and instead of hand-writing Istio VirtualServices and AuthorizationPolicies directly, most teams use the Kyma APIRule custom resource, which is a simplified abstraction that generates the underlying Istio configuration. An APIRule specifies the host, the target Service, the port, and access strategies such as requiring a valid OAuth2 token (validated against XSUAA or another identity provider), JWT validation, or, for lower-security internal test endpoints, allowing unauthenticated access (which should be avoided for anything beyond throwaway testing). Getting the access strategy wrong is one of the most common production security gaps: teams sometimes expose an APIRule with no authentication during development and forget to lock it down before go-live. For outbound calls from a Kyma workload to on-premise SAP systems, the pattern typically involves the Destination service and Connectivity service, the same BTP services used by Cloud Foundry applications and Integration Suite. A Kyma workload authenticates to these services using a Service Binding, which is created by binding a Service Instance (representing an instance of the Destination or Connectivity service) to the workload's namespace. The binding produces a Kubernetes Secret containing credentials (client ID, client secret, service URLs) that the application reads at runtime, typically via environment variables or mounted volume, to call the Destination service API and retrieve connection details, then route through Cloud Connector if the target is on-premise. Observability in Kyma comes from a combination of Kubernetes-native tooling (kubectl logs, kubectl describe, kubectl get events) and any monitoring/tracing stack configured for the cluster, which may include SAP-provided or customer-integrated observability tools. Troubleshooting a failed deployment usually starts with checking pod status (Pending, CrashLoopBackOff, ImagePullBackOff) and reading events and logs before assuming a code-level bug; many early failures are actually image pull authentication issues, missing resource quota, or misconfigured readiness/liveness probes causing Kubernetes to kill healthy-but-slow-starting pods. Regarding differences from other SAP deployment models: in S/4HANA on-premise, custom extension logic often lives in ABAP within the same system, with authorization and connectivity handled by the ABAP stack's own mechanisms. In S/4HANA Cloud (public cloud), custom logic is pushed out to side-by-side extensions on BTP, and Kyma is one of the valid runtimes for that, alongside Cloud Foundry. The specific choice between exposing via APIRule with XSUAA versus another identity provider, or which event backend to bind to, can vary by BTP subaccount configuration and available service plans, so specifics should always be confirmed against the actual subaccount rather than assumed uniform across all landscapes.

Code example

# APIRule exposing a service with OAuth2 (XSUAA-issued token) validationapiVersion: gateway.kyma-project.io/v1beta1kind: APIRulemetadata:  name: hello-integration-service  namespace: dev-team-aspec:  host: hello-integration-service.mycluster.kyma.ondemand.com  service:    name: hello-integration-service    port: 80  gateway: kyma-gateway.kyma-system.svc.cluster.local  rules:    - path: /.*      methods: ["GET", "POST"]      accessStrategies:        - handler: oauth2_introspection          config:            required_scope: ["integration.read"]---# Example: reading Destination service binding credentials in app code (Node.js)# const destCreds = JSON.parse(process.env.DESTINATION_SERVICE_CREDENTIALS);# fetch(`${destCreds.uri}/destination-configuration/v1/destinations/MY_DEST`, {#   headers: { Authorization: `Bearer ${accessToken}` }# });

Real project scenario

During a project connecting a Kyma-hosted microservice to an on-premise SAP ECC system through Cloud Connector, the initial deployment exposed the service with no access strategy for quick internal testing. Before promoting to the test subaccount, the integration architect required the team to rebuild the APIRule with OAuth2 token validation tied to a dedicated XSUAA scope, and to bind a Destination service instance so the microservice could resolve the on-premise destination configuration dynamically instead of hardcoding the Cloud Connector location ID, which made the same container image portable across dev, test, and production namespaces.

Common mistakes

• Leaving an APIRule without an access strategy (effectively public) beyond initial development testing. • Hardcoding destination URLs or Cloud Connector location IDs in application code instead of resolving them via Destination service at runtime. • Forgetting to create the image pull secret in the target namespace, causing ImagePullBackOff errors that look like unrelated deployment failures. • Not setting readiness and liveness probes, causing Kubernetes to route traffic to pods that are not actually ready or to kill slow-starting pods prematurely. • Binding a Service Instance in the wrong namespace, so the resulting Secret is not visible to the workload that needs it.

Best practices

• Always define an explicit access strategy on APIRule; treat unauthenticated exposure as a temporary dev-only state, never a production default. • Resolve destination details dynamically via Destination service instead of hardcoding endpoints or credentials in the container image. • Set readiness and liveness probes on every Deployment to ensure accurate traffic routing and pod lifecycle management. • Store registry credentials as namespace-scoped Secrets and rotate them according to organizational policy. • Validate Service Instance and Service Binding namespace alignment before debugging application-level connectivity errors.

Interview angle

Candidates are frequently asked how they would securely expose a microservice on Kyma to external callers. A strong answer names the APIRule resource explicitly, explains that it generates Istio configuration under the hood, and describes choosing an access strategy such as OAuth2 token validation tied to XSUAA scopes rather than leaving the endpoint open, plus how outbound on-premise calls are routed through Destination service and Cloud Connector.