The API exposure in Kyma is based on the API Gateway component that aims to provide a set of functionalities that allow developers to expose, secure, and manage their APIs in an easy way. The main element of the API Gateway is the API Gateway Controller, which exposes services in Kyma.

API Gateway

To make your service accessible outside the Kyma cluster, expose it using Kyma API Gateway Controller, which listens for the custom resource (CR) objects that follow the apirules.gateway.kyma-project.io CustomResourceDefinition (CRD). Creating a valid CR triggers API Gateway Controller to create an Istio VirtualService. Optionally, you can specify the rules attribute of the CR to secure the exposed service with Oathkeeper Access Rules.

API Gateway Controller allows you to secure the exposed services using JWT tokens issued by an OpenID Connect-compliant identity provider, or OAuth2 tokens issued by the Kyma OAuth2 server. You can secure the entire service, or secure the selected endpoints. Alternatively, you can leave the service unsecured.

CAUTION: Since Kyma 2.2, Ory stack has been deprecated. For more information, read the blog posts explaining the new architecture and Ory Hydra migration. See the deprecation note.

NOTE: To learn more, read about the Kyma OAuth2 server.

API Gateway limitations

Controller limitations

The APIRule controller is not a critical component of the Kyma networking infrastructure since it relies on Istio and Ory Custom Resources to provide routing capabilities. In terms of persistence, the controller depends on APIRules stored in the Kubernetes cluster. No other persistence solution is present.

In terms of the resource configuration, the following requirements are set on the API Gateway controller:

Limitations in terms of the number of created APIRules

The number of created APIRules is not limited.

Dependencies

API Gateway depends on Istio and Ory to provide its routing capabilities. In the case of the allow access strategy, only a Virtual Service Custom Resource is created. With any other access strategy, both Virtual Service and Oathkeeper Rule Custom Resource are created.

Useful links

If you're interested in learning more about API Exposure in Kyma, follow these links to:

• Perform some simple and more advanced tasks:

  • Create a workload
  • Set up a custom domain for a workload
  • Expose a workload
  • Expose multiple workloads on the same host
  • Expose and secure a workload with OAuth2
  • Get a JWT
  • Expose and secure a workload with Istio
  • Expose and secure a workload with JWT
  • Activate access logs

• Troubleshoot API Exposure-related issues when:

  • You cannot connect to a service exposed by an APIRule
  • You get the 401 Unauthorized or 403 Forbidden status code when you try to connect to a service exposed by an APIRule
  • You get the 404 Not Found status code when you try to connect to a service exposed by an APIRule
  • You get the 500 Internal Server Error status code when you try to connect to a service exposed by an APIRule
  • Connection refused errors occur when you want to use your custom domain
  • You receive the could not resolve host error when you want to use your custom domain
  • A resource is ignored by the controller
  • The Issuer Custom Resource fails to be created
  • The Kyma Gateway is not reachable
  • The Pods are stuck in Pending/Failed/Unknown state after an upgrade
  • There are Issues when creating an APIRule - Various reasons

• Learn something more about:

  • Authorization configuration
  • Allowed domains in API Gateway Controller
  • Blocked services in API Gateway Controller

• Analyze configuration details for:

  • The ORY chart