Tell us what you think

We want to create the best possible experience for our learners. Your feedback helps us to improve the experience for everyone.

Using the API Gateway module to Expose Services

Objectives

After completing this lesson, you will be able to:

Describe the components of the API Gateway module
Use the API Gateway components to expose services

Components of the API Gateway

Project "Kyma" extends the Kubernetes platform with a set of modules that allow you to expose your Services and Functions outside the cluster. The API Gateway module can be used on top of your Kubernetes Services to make the Services accessible outside the Kyma cluster.

Istio and API Gateway are default Kyma modules, which means that they are added to your Kyma runtime once you provision it. If you want to create Functions and expose them using API Gateway, you must also add the Serverless module. To trigger exposed Services with events, add the Eventing module. To monitor exposed workloads, add the Telemetry module and use the observability features it provides.

API Gateway Components

The API Gateway is based on the open-source project Istio, which is also installed as part of the Istio module. 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.

Using the API Gateway Module

To expose a service using the API Gateway module, you must create a Kubernetes Custom Resource (CR) called APIRule (apirules.gateway.kyma-project.io). By creating an APIRule for a service, the API Gateway Controller creates an Istio VirtualService for you behind the kyma-gateway. So with APIRule CR, you have a higher-level abstraction that allows you to provision services quickly and securely.

APIRule CR

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

YAML

123456789101112131415
apiVersion: gateway.kyma-project.io/v2alpha1
kind: APIRule
metadata:
  name: my-api-rule
spec:
  hosts:
    - my-api-rule.xxxxx.kyma.ondemand.com
  service:
    name: hello-kyma-svc
    port: 80
  gateway: kyma-system/kyma-gateway
  rules:
    - path: /*
      methods: ["GET"]
      noAuth: true

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

gateway: The Istio Ingress Gateway to expose the Service. For development purposes, you can use a Kyma domain and the default Kyma Gateway kyma-system/kyma-gateway . In the production environment, use your custom domain to set up a TLS Gateway. To learn, how to do this, see the tutorial.
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 access rules. The path specifies the request's path that should be matched. The methods array specifies the HTTP methods that should be matched. APIRule allows you to define the security configuration of an exposed endpoint using the concept of access strategies. The supported access strategies are noAuth, jwt, and extAuth. Setting noAuth to true disables authorization. The jwt field specifies the Istio JWT access strategy and the extAuth field specifies the Istio External Authorization access strategy.

For more information, see APIRule Custom Resource.

Using Kyma Dashboard

Kyma dashboard provides a simple way to create APIRules to expose your workload. The creation of APIRules is integrated into the view of functions and services. However, you can also go to the APIRules view and create a new APIRule.

You can specify the APIRule via YAML or use the form-based view on the dashboard. In the form-based view, you can select and specify all attributes for the APIRule. Also, Rules can be created in the form-based view.

Summary

With APIRule, 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.