Using the API Gateway to Expose Services

Objectives
After completing this lesson, you will be able to:

After completing this lesson, you will be able to:

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

Components of the API Gateway

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

API Gateway Components

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.

Using the API Gateway

To expose a service through the API Gateway, you must create a Kubernetes Custom Resource (CR) called API Rule (apirules.gateway.kyma-project.io). By creating an API Rule for a service, the API Gateway Controller creates an Istio VirtualService for you behind the kyma-gateway. When specifying rules for the API Rule, the API Gateway Controller will also create the corresponding Oathkeeper Access Rules. So with API Rule CR, you have a higher-level abstraction of Istio VirtualServices and Oathkeeper Access Rules that allows you to provision services quickly and securely.

API Rule CR

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:

Code snippet
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: {}
Copy code

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.

Using the Kyma Dashboard

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

You can specify the API Rule 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 API Rule. Also, Rules can be created in the form-based view.

Summary

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.

Further Reading

Log in to track your progress & complete quizzes