Sidecarless Kubernetes cluster 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.

1. A Web client wants to access the Web application. The request is sent to the Ingress of the Kubernetes cluster.
2. The Ingress accepts the traffic from outside the cluster and forwards it to the Microgateway Engine Deployment via the Microgateway Service.
3. The Microgateway Engine Deployment forwards the 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.

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 Microgateway Service(s) and 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 1:1 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 led through the Microgateway Engine as configured. Airlock Microgateway uses a security-by-default strategy and will apply the built-in security measures to all routes.
4. If one of the K8s Gateway API resources has been altered, the Microgateway Operator updates the Microgateway Engine with the new configuration.
5. CRDs for custom configurations like DenyRules, Limits, etc., and the ContentSecurityPolicy are optional. The ContentSecurityPolicy is a Direct Policy Attachment to extend K8s Gateway API resources – this allows custom deny rules, limits, and other settings to be added.
6. If one of the optional Microgateway resources has been altered, the Microgateway Operator updates the Microgateway Engine with the new configuration.