Configure API Gateway

This page outlines the configuration values for the API Gateway deployed via Axual Governance Helm chart.

About API Gateway

API Gateway is a reverse proxy component built with Spring Cloud Gateway. It routes requests to different backend microservices based on the request path.

API Gateway Configuration

API Gateway requires the three mandatory sections defined in the Application Configuration

For a complete list of configurations, please refer to API Gateway Configuration.

API Gateway Repository Configuration

Initially, you can override the registry, tag, and pullPolicy for the API Gateway pod.

By default, these values come from the Axual Governance charts.

You can also override the imagePullSecrets; if not specify the API Gateway pod will use the global.imagePullSecrets

values.yaml

api-gateway:

  image:
    registry: "docker.axual.io"
    pullPolicy: "Always"
    tag: "0.4.1"

  imagePullSecrets:
    - name: axualdockercred

Server Security Configuration

If needed, you can specify existing kubernetes secrets containing the PEM certificates to secure incoming connections with SSL.

Here is an example of how you can configure it.

values.yaml

api-gateway:

  env:
    - name: SPRING_SSL_BUNDLE_PEM_API-GATEWAY_KEYSTORE_CERTIFICATE
      valueFrom:
        secretKeyRef:
          # key identifying the server-certificate within the k8s-secret
          key: <server-certificate-name>
          name: <k8s-secret-name>
    - name: SPRING_SSL_BUNDLE_PEM_API-GATEWAY_KEYSTORE_PRIVATE_KEY
      valueFrom:
        secretKeyRef:
          # key identifying the server-key within the k8s-secret
          key: <server-key-name>
          name: <k8s-secret-name>

  config:
    server:
      ssl:
        enabled: true
        # name referring to the bundle-pem
        bundle: "api-gateway"

Application Configuration

API Gateway is a Spring application. Spring application can be configured with application.yml files. What is present under config in the yml file, gets injected in a ConfigMap and mounted as an application.yml file.

The application configuration consists of three mandatory sections.

Gateway Endpoints

These configurations are mandatory to be provided, and they represent where the backend microservices are reachable.

Based on your installation, you might disable optional backend microservices.

Use the service name of the components based on your installation.

values.yaml

api-gateway:

  config:
    gateway:
      endpoints:
        # Mandatory Backend service
        platformManager:
          enabled: true
          url: "http://[platform-manager-service-name]"
        # Optional Backend service
        organizationManager:
          enabled: true
          url: "http://[organization-manager-service-name]"
        # Optional Backend service
        topicBrowse:
          enabled: true
          url: "http://[topic-browse-service-name]"
        # Optional Backend service
        metricsExposer:
          enabled: false
          url: "http://[metrics-exposer-service-name]"
        # Optional Backend service
        metricsExposerApiDocs:
          enabled: false
          url: "http://[metrics-exposer-service-name]"
        # Mandatory Frontend service
        platformUi:
          enabled: true
          url: "http://[platform-ui-service-name]"
        # Mandatory Backend service
        keycloak:
          enabled: true
          url: "http://[keycloak-http-service-name]"

Local and SSO Authentication Configurations

These configurations are mandatory to be provided, and they represent the two types of security restrictions that are applied depending on the endpoints.

Local Authentication — These are users signed up to the application with their email address and attempting to authenticate and access the Platform Manager endpoints.
SSO Authentication — These are users authenticating with their Organization SSO (Active Directory, LDAP, etc) identities.

values.yaml

api-gateway:

  config:
    # This defines the Local Realm for user registration
    local:
      auth:
        # Endpoint of the Local Authentication Server Issuer URI (e.g. https://idp.example.com ).
        # This endpoint is never called. It is used to compare the iss claim of the JWT token.
        issuerUrlForValidation: https://platform.local/auth/realms/local
        # Endpoint of the Local Authentication Server JWK Set URI (e.g. https://idp.example.com/.well-known/jwks.json ).
        # Used for signing up new tenants.
        jwkSetUri: http://keycloak-http/auth/realms/local/protocol/openid-connect/certs

    # Keycloak Authentication Server
    sso:
      keycloak:
        # URL of Keycloak to be accessed outside the cluster
        advertisedBaseUrl: https://platform.local
        # URL of Keycloak to be accessed within the cluster
        internalBaseUrl: http://keycloak-http
        # Allow accessing Keycloak without TLS chain validation
        useInsecureTrustManager: false

Permission and Topic Browse Config APIs

These configurations are mandatory to be provided, and they represent where the permission api is reachable and where the browse-config resource is reachable.

Only adjust the service name of the Platform Manager based on your installation.

values.yaml

api-gateway:

  config:
    # Service Name of Platform Manager
    # the path `/api/auth` is fixed
    permissions-api:
      url: "http://[platform-manager-service-name]/api/auth"
    # Service Name of Platform Manager
    # the path `/api/stream_configs/{id}/browse-config` is fixed
    topic-browse-config-api:
      url: "http://[platform-manager-service-name]/api/stream_configs/{id}/browse-config"

Metrics Exposer Configuration

If Metrics Exposer backend is enabled in API Gateway, then following configurations are mandatory.

Only adjust the service name of the Platform Manager based on your installation.

values.yaml

api-gateway:
  config:
    # Service Name of Platform Manager
    # the path `/api/monitoring_information` is fixed
    metrics-exposer-config-api:
      url: "http://[platform-manager-service-name]/api/monitoring_information"

The API Gateway intercepts all requests to Metrics Exposer (/api/metrics/**) and calls the Metrics Exposer Config API (Platform Manager) to enrich the request before forwarding it to Metrics Exposer backend.

Ingress Configuration

API Gateway helm-charts allow configuring an Ingress to make it accessible outside the kubernetes cluster.

By default, the API Gateway needs to be exposed outside the kubernetes cluster to have the Self-Service working for users.

To enable API Gateway’s ingress, you can configure it as follows

values.yaml

api-gateway:

  ingress:
    # -- Enable creation of the Ingress resource to expose this service.
    enabled: true
    # -- The name of the IngressClass cluster resource.
    # The associated IngressClass defines which controller will implement the resource.
    className: ""
    # -- Annotations to add to the Ingress resource.
    annotations: {}
    hosts:
      - # -- The fully qualified domain name of a network host.
        host: "chart-example.local"
        paths:
          - # -- Matched against the path of an incoming request.
            path: "/"
            # -- Determines the interpretation of the Path matching.
            # Can be one of the following values: `Exact`, `Prefix`, `ImplementationSpecific`.
            pathType: "ImplementationSpecific"
    # -- TLS configuration for this Ingress.
    tls: []
    #  - secretName: chart-example-tls
    #    hosts:
    #      - chart-example.local

Route Configuration

API Gateway helm-charts allow configuring an OpenShift Route to make it accessible outside the kubernetes cluster.

By default, the API Gateway needs to be exposed outside the kubernetes cluster to have the Self-Service working for users.

To enable API Gateway’s route, you can configure it as follows

values.yaml

api-gateway:

  route:
    # -- Enable creation of an OpenShift Route resource to expose this service.
    enabled: true
    # -- Annotations to add to the Route.
    annotations: {}
    # -- Labels to add to the route.
    labels: {}
    # -- An alias/DNS that points to the service. Optional. If not specified a route name will typically be automatically chosen.
    host: ""
    # -- subdomain is a DNS subdomain that is requested within the ingress controller’s domain (as a subdomain). If host is set this field is ignored.
    subdomain: ""
    # -- Path that the router watches for, to route traffic for to the service.
    path: "/"
    tls:
      # -- The Certificate Authority certificate contents.
      caCertificate: ""
      # -- Certificate contents. This should be a single serving certificate, not a certificate chain. Do not include a CA certificate.
      certificate: ""
      # -- Key file contents.
      key: ""
      # -- Indicates termination type. One of: `edge`, `passthrough`, or `reencrypt`.
      termination: "passthrough"
      # --The CA certificate of the final destination. When using reencrypt termination this file should be provided
      # in order to have routers use it for health checks on the secure connection.
      destinationCACertificate: ""