Sidecarless architectures (K8s Gateway API)

The sections of this article address the sidecarless Airlock Microgateway installation and deployment forms with one or more Microgateway Engine Pods deployed using the K8s 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

  • SidecarGateway must be switched off.
    • When deploying with RedHat OLM, SidecarGateway is already disabled.
    • When deploying with the Microgateway Helm Chart, set operator.sidecarGateway.enabled: false.
  • 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 K8s Gateway API [1]
    • Presenting TLS server certificate
  3. Recording metrics (request count)
  4. Applying CORS filter via K8s 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
  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 K8s Gateway API [2]
    1. Removing request headers
    2. Adding request headers
  18. Applying URL rewrites via K8s Gateway API and redirects via K8s Gateway API [3]
    • If redirected, proceedsing to response processing
  20. Performing TLS handshake with upstream via K8s 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. Enforcing OpenAPI specification
  5. Updating session handling information
  6. Modifying headers via K8s Gateway API [4]
    1. Removing response headers
    2. Adding response headers
  8. Sending response to downstream
[1]

See also official K8s Gateway API TLS documentation.

[2]

See also official K8s Gateway API HTTP header modifiers documentation.

[3]

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

[4]

See also official K8s Gateway API HTTP header modifiers documentation.

Sidecarless without a service mesh

This article shows the architecture of a web application protected by Airlock Microgateway using the K8s Gateway API, deployed in a Kubernetes cluster. The example illustrates the setup without service mesh. It is the most simple functional sidecarless 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 K8s Gateway API resources.
  3. New Gateway resources trigger the Microgateway Operator to deploy Service(s) and Microgateway Engine deployments. The K8s 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 K8s 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 K8s 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.