Using the API Gateway to Expose Services

The API Gateway is based on the open-source project Istio, which is also installed as part of the Kyma installation. You will find out more about Istio in the next unit.

Technically, the API Gateway is a custom-configured Istio Ingress Gateway that is installed in the kyma-system namespace called kyma-gateway. The kyma-gateway is the central point of contact for all external traffic that enters the Kyma cluster. The kyma-gateway (Istio Ingress Gateway) uses the Envoy Proxy as an application-based service proxy to handle the traffic and to forward it to the correct Service.

For authorizing incoming HTTP requests, the open-source project Ory Oathkeeper is plugged into the Envoy Proxy of the API Gateway. Oathkeeper is a lightweight identity, and access proxy used to secure your services and functions. Oathkeeper decides whether a request is allowed to access a service by applying Access Rules.

To define an API Rule, you must create a CR of the kind apirules.gateway.kyma-project.io. A simple API Rule manifest looks like this:

apiVersion: gateway.kyma-project.io/v1beta1
kind: APIRule
metadata:
  name: my-api-rule
spec:
  gateway: kyma-system/kyma-gateway
  host: my-api-rule.xxxxx.kyma.ondemand.com
  service:
    name: hello-kyma-svc
    port: 80
  rules:
    - path: /.*
      methods: ["GET"]
      mutators: []
      accessStrategies:
        - handler: allow
          config: {}

Let's have a closer look at the spec section of the API Rule CR:

• gateway: The Istio Ingress Gateway to expose the Service. The kyma-system/kyma-gateway should be used to expose it.
• host: Specifies the host or subdomain of the host where the Service should be exposed. You can expose multiple services behind the same host through Istio VirtualServices.
• service: Specifies the Kubernetes service to be exposed. The name is the name of the Kubernetes Service that you want to expose. The port is the port of the Kubernetes Service that you want to expose.
• rules: Specifies the array of Oathkeeper access rules. The path specifies the request's path that should be matched. The methods array specifies the HTTP methods that should be matched. The mutators array specifies the array of Oathkeeper mutators that should be applied to the request. The accessStrategies array specifies the array of Oathkeeper access strategies that should be applied to the request.

Read more about the API Rule here.

With API Rule, you get a higher-level object to expose services quickly and securely. The API Gateway Controller will create the corresponding Istio VirtualServices and Oathkeeper Access Rules for you.