System architectures

This article addresses the different deployment forms with one or more Microgateway Engine Pods deployed using the Kubernetes Gateway API. Each Microgateway Engine Pod can route traffic (i.e., defined in HTTPRoute resource) to multiple Services and application Pods.

 
Info

The Kubernetes Gateway API is a Kubernetes API specification defining a standard way to configure and manage application traffic routing in Kubernetes clusters. It becomes a superset of the classic Kubernetes Ingress functionality with powerful and granular control, including expanded protocol support and routing options. For more information, see the official Kubernetes Gateway API documentation.

Gateway deployment

The following table illustrates two possible models for deploying Gateways within a Kubernetes cluster:

Microgateway as Ingress (RECOMMENDED)

Microgateway as an in-cluster Gateway

Architecture

Description

A Microgateway as Ingress protects multiple upstream services from different namespaces.

An in-cluster Microgateway protects upstream services within the same namespace.

Traffic

  • North-South

  • Notice
    Route the traffic through the Microgateway Ingress.

  • East-West

  • Notice
    Route the traffic through the in‑cluster Microgateway service or the Microgateway Ingress.

  • North-South

  • Notice
    Route the traffic from an existing Ingress to the in-cluster Microgateway service.

  • East-West

  • Notice
    Route the traffic through the in‑cluster Microgateway service.

Gateway namespace

Dedicated namespace, separated from the application namespace.

Application namespace.

Number of Gateways

Low

Notice
Multiple Gateways can be deployed. Services with the same external FQDNs must use the same Gateway.

Corresponds to the number of protected application namespaces.

Operational Overhead

Low, since only one Ingress is deployed.

Medium to high, since more than one Ingress are deployed.

Complexity

Low, since only a few Gateways are deployed.

Medium to high, since much more Gateways are deployed.

Latency

Minimal

Moderate, since another hop is in place.

Security Control

Incoming traffic (north-south) passes automatically Microgateway, which is the security component.

Incoming traffic (north-south) might by-pass Microgateway and reach the upstream service unfiltered.

Isolation

(logs, metrics, tracing, upgrade, traffic handling)

Low to strong, depending on which services share the same Gateway.

Strong, since every namespace has a dedicated Gateway.

Ecosystem integration

Special attention for the integration into the existing ecosystem is required (e.g., Istio, Cilium, RedHat OpenShift, ...)

Less invasive, because there is no need to change the existing Ingress of the ecosystem (e.g., Istio, Cilium, RedHat OpenShift, ...)

Microgateway Operator deployment

The following table illustrates two possible models for deploying the Microgateway Operator:

Single Operator (RECOMMENDED)

Multiple Operators

Description

Only one Microgateway Operator is deployed within a Kubernetes cluster.

Multiple Microgateway Operators are deployed within a Kubernetes cluster. The controllerName in the GatewayClass defines the responsible Operator.

Microgateway version

One version in the Kubernetes cluster

By deploying different Operator versions, different versions could be used in the same Kubernetes cluster.
 

Custom Resource Definitions (CRDs)

One version

Shared, newest version must be deployed.

Complexity

Low

High, since the shared components could interfere other Microgateway Operators and causes outages.

Operational Overhead

Low

High, since multiple Microgateway Operators must be maintained.

Isolation

(managed Gateways)

Low, on Operator side.

High, except shared compontents:

  • Custom Resource Definitions (CRDs)
  • Kubernetes webhooks
  • Kubernetes admission policies

Remarks

  • Deploy each Operator in a different namespace.
 
Info

We strongly recommend deploying a dedicated Kubernetes cluster with a single Microgateway Operator to ensure full isolation of the Operator and avoid interference from other components.

Management roles and responsibilities

The Kubernetes Gateway API features a concept of three distinctive roles to address the differing needs of the users to balance usability, flexibility, and control.

The following primary roles have been defined:

  • The Infrastructure provider manages the GatewayClass resource.
  • The Cluster operator manages the Gateway resource and may define cluster-wide routing limitations for xRoute resources such as HTTPRoute.
  • Developers manage the routing by *Route resources such as HTTPRoute and of course, they also manage their application Services and Pods.
 
Info

Depending on the environment, a single human may take on multiple roles.

Processing sequence

Request processing

  1. Performing TLS handshake with downstream via Kubernetes Gateway API [1]
    • Presenting TLS server certificate
  3. Recording metrics (request count)
  4. Applying CORS filter via Kubernetes Gateway API
  5. Enforcing CSRF protection
  6. Establishing session handling
  7. Applying prepended Envoy HTTP filters
  8. Evaluating access control policies
    1. Executing OIDC flow
    2. Validating JWT
    3. Performing authorization checks
    4. Performing Token Exchange
  10. Enforcing policies
    1. Validating against input limits (parameters, JSON, GraphQL, etc.)
    2. Enforcing OpenAPI specifications
    3. Applying deny rules
    4. Validating GraphQL schema
    5. ICAP request filtering
  12. Modifying headers via CR HeaderRewrites
    1. Removing request headers
    2. Adding request headers
  14. Propagating identity
  15. Applying appended Envoy HTTP filters
  16. Modifying headers via Kubernetes Gateway API [2]
    1. Removing request headers
    2. Adding request headers
  18. Applying URL rewrites via Kubernetes Gateway API and redirects via Kubernetes Gateway API [3]
    • If redirected, proceedsing to response processing
  20. Performing TLS handshake with upstream via Kubernetes Gateway API
  21. Sending request to upstream

Response processing

  1. Receiving response from upstream
  2. Modifying headers via CR HeaderRewrites
    1. Removing response headers
    2. Adding response headers
  4. Custom responses
  5. Enforcing OpenAPI specification
  6. Updating session handling information
  7. Modifying headers via Kubernetes Gateway API [4]
    1. Removing response headers
    2. Adding response headers
  9. Sending response to downstream
[1]

See also official Kubernetes Gateway API TLS documentation.

[2]

See also official Kubernetes Gateway API HTTP header modifiers documentation.

[3]

See also official Kubernetes Gateway API HTTP path redirects and rewrites documentation.

[4]

See also official Kubernetes Gateway API HTTP header modifiers documentation.

Deployment without a service mesh

This section shows the architecture of a web application protected by Airlock Microgateway using the Kubernetes Gateway API, deployed in a Kubernetes cluster. The example illustrates the setup without service mesh. It is the most simple functional setup – with a single Microgateway Engine Pod securing Web application containers. The setup shows two namespaces, one for the Microgateway Operator Pod and a second one with the Microgateway Engine and Web application Pods.

Traffic handling

  1. A Web client wants to access the Web application. The Service of type LoadBalancer works as a single outward-facing endpoint and exposes the Microgateway Engine to ingress traffic.
  2. The Microgateway Engine accepts the traffic from outside and inside the cluster, processes and forwards or blocks traffic according to the configuration set in the CR ContentSecurityPolicy and CR AccessControlPolicy.
  3. The Microgateway Engine forwards traffic to the Web application Service as configured by the Gateway and HTTPRoute CRs.
  4. The Microgateway Engine deployment writes logs to /dev/stdout. A logging service can collect and visualize these logs in a graphical reporting solution.
  5. The Prometheus deployment scrapes metrics from the Microgateway Engine containers that can be visualized, e.g., using Grafana.

Configuration handling

  1. The Microgateway Operator read its configuration from the Microgateway Operator Configuration during startup.
  2. The Microgateway Operator watches for new or changed GatewayClass, Gateway, HTTPRoute, and other Kubernetes Gateway API resources.
  3. New Gateway resources trigger the Microgateway Operator to deploy Service(s) and Microgateway Engine deployments. The Kubernetes Gateway API configuration is generated based on different resources:
    • The GatewayClass resource represents the class of gateway (here: Airlock Microgateway) that can be instantiated.
    • The Gateway resource represents precisely the deployment of a Microgateway. It specifies the target namespace, the hostnames, ports, protocol, downstream TLS settings, and which routes can be attached to a listener.
    • The HTTPRoute (or other future supported Route CRs) resources contain routing configurations between the Airlock Microgateway and the web application service so that traffic is routed through the Microgateway Engine as configured. Airlock Microgateway uses a security-by-default strategy and applies built-in security measures to all routes.
  5. If one of the Kubernetes Gateway API resources has been altered, the Microgateway Operator updates the Microgateway Engine with the new configuration.
  6. CRDs for custom configurations like DenyRules, Limits, etc., and the ContentSecurityPolicy are optional.
    • The ContentSecurityPolicy and AccessControlPolicy are Direct Attached Policies extending the Kubernetes Gateway API resources – this allows custom deny rules, limits, authorization/access control and other settings to be added.
    • The GatewayParameters defines the configuration settings for deploying a Gateway in a Kubernetes cluster, including options for logging, service type, deployment strategy, and resource management. It can be referenced by either a GatewayClass or a Gateway.
  8. If one of the optional Microgateway resources has been altered, the Microgateway Operator updates the Microgateway Engine with the new configuration.

TLS certificate generation and renewal

Any communication between Airlock Microgateway containers, i.e. between Microgateway Operator and Microgateway Engine containers, is secured using mTLS.

When the Microgateway Operator starts, it generates a self-signed CA certificate and stores it as a Kubernetes Secret named airlock-microgateway-ca-cert in the airlock-microgateway-system namespace. This CA certificate is used to issue the self-signed TLS certificates required for internal communication.

Each time an Airlock Microgateway Engine is deployed, an airlock-microgateway-bootstrap-secret is generated and saved to the Namespace of the Engine Deployment. This secret holds the required certificates and keys for mTLS-based communication between the Microgateway Engine and the Operator. The TLS certificates of the bootstrap secret are renewed automatically every 48h.