Architectures of sidecar-based mode deployments

This article shows the architecture of a web application deployed in a Kubernetes cluster and protected by Airlock Microgateway. This example illustrates the setup if no service mesh is used. This is the most simple functional setup – with Airlock Microgateway injected which secures a single Web application container. The setup shows two namespaces, one for the Microgateway Operator Pod and a second one with the Web application Pod.

The ​Microgateway Operator​ container injects the ​Microgateway Engine​ Container into web application Pods labeled with sidecar.microgateway.airlock.com/inject: "true".

• The Operator configures the Engine based on Custom Resources that contain the Engine configuration.
• The Microgateway CNI plugin of the Node configures the network routing between Engine and Web application container.

1. A Web client wants to access the Web application. The request is sent to the Ingress controller of the Kubernetes cluster.
2. The Ingress controller accepts the traffic from outside the cluster and forwards it to the Web application Service.
3. The Web application Service forwards the traffic to the Web application Pod.
   In this Pod, all traffic is routed through the Microgateway Engine container and subsequently to the Web application container as configured by the Microgateway CNI plugin.
4. The Microgateway Engine container writes logs to /dev/stdout. A logging service can collect and visualize these logs in a graphical reporting solution.
5. The Prometheus Pod scrapes metrics from the Microgateway Engine containers that can be visualized, e.g., using Grafana.

1. The Microgateway Operator reads its configuration from the Microgateway Operator Configuration at startup and watches for events such as Pod create, update or delete.
2. When a Web application Pod is created with a sidecar.microgateway.airlock.com/inject label, two things happen:
• The Microgateway Operator injects the Microgateway Engine and Session Agent container.
• The Microgateway CNI plugin configures the routing within the Web application Pod so that all traffic is led through the Microgateway Engine.
• The Microgateway Network Validator performs a quick sanity check of the network routing configured by the Microgateway CNI plugin.
3. The CustomResource SidecarGateway includes a podSelector that selects the group of Pods to which the configuration applies.
4. The CustomResource SidecarGateway refers to other resources that should be applied.
5. The Microgateway Operator reads the involved configuration and sends it to the Microgateway Engine.
6. The Microgateway Operator watches the Microgateway Engine configuration resources. If these resources have been altered, the Microgateway Operator updates the Microgateway Engine with the new configuration.

This article shows the architecture of a small Istio service mesh with only one Airlock Microgateway-protected web application deployed in a Kubernetes cluster. Istiod converts the high-level routing rules into Envoy-specific configurations of the Envoy proxies that are deployed as sidecars. These Envoy sidecars are injected into each Pod forming the Istio data plane.
However, in Airlock Microgateway, the Microgateway Operator Pod is not a typical manageable web application but a technical component that manages the Microgateway functionality. Hence, the Microgateway Operator does not need to be maintained by the Istio control plane.

The simple example shows a setup with a service mesh of a single web application, the Microgateway Operator and the Istiod Container in a single Node. In the Web application Pod the Microgateway Engine and the Istio-proxy/Istio-init are injected as sidecars.

• Namespaces in our example:
• istio-system working as the Istio control plane.
• airlock-microgateway-system with the Microgateway Operator Pod, which is not part of the service mesh (no Istio proxy sidecar).
• application with a web application secured by Airlock Microgateway and part of the service mesh (with Istio proxy sidecar).
• kube-system used for system processes, i.e., to install a Microgateway CNI plugin in Airlock Microgateway Nodes. This Namespace is not part of the Istio service mesh.

Within the Kubernetes cluster, the Microgateway Operator Container is responsible for injecting and configuring the Airlock Microgateway Containers, i.e., the Microgateway Engine in the Web application Pods. For operating Airlock Microgateway in an Istio setup, the sidecar injection is triggered by a sidecar.microgateway.airlock.com/serviceMesh: "istio" annotation, which must be added to the Pod definition.

1. A Web client wants to access the Web application. The request is sent to the Istio Ingress controller of the Kubernetes cluster.
2. The Istio Ingress controller accepts the traffic from outside the cluster and forwards it to the Web application Service.
3. The Web application Service forwards the traffic to the Web application Pod.
   The traffic routing configuration inside the Web Application Pod is as follows:
• Istiod injects the istio-init Container, which reconfigures the Pod's network to route all traffic to the Istio proxy.
  (Istio can also be operated with a CNI plugin instead of the istio-init container.)
• The Microgateway CNI plugin reconfigures the Pod's network behind the istio proxy to route the traffic from the istio proxy to the Microgateway Engine container and finally to the web application.
4. The Microgateway Engine Container writes logs to /dev/stdout. A logging service can collect and visualize these logs in a graphical reporting solution.
5. The Prometheus Pod scrapes metrics from the Microgateway Engine Containers that can be visualized e.g., using Grafana.

1. The Microgateway Operator reads its configuration from the Microgateway Operator Configuration at startup and watches for events such as Pod create, update or delete.
2. When a Web application Pod is created with a sidecar.microgateway.airlock.com/inject label, two things happen:
• The Microgateway Operator injects the Microgateway Engine and Session Agent container.
• The Microgateway CNI plugin configures the routing within the Web application Pod so that all traffic is led through the Microgateway Engine.
• The Microgateway Network Validator performs a quick sanity check of the network routing configured by the Microgateway CNI plugin.
3. The CustomResource SidecarGateway includes a podSelector that selects the group of Pods to which the configuration applies.
4. The CustomResource SidecarGateway refers to other resources that should be applied.
5. The Microgateway Operator reads the involved configuration and sends it to the Microgateway Engine.
6. The Microgateway Operator watches the Microgateway Engine configuration resources. If these resources have been altered, the Microgateway Operator sends an update to the Microgateway Engine with the new configuration.

1. The Istiod provides service discovery, configuration and certificate management for the injected Istio proxy sidecars. The Istiod contains Pilot, Citadel and Galley components that form the Istio control plane.
2. The Istio proxy sidecars transparently route the traffic from and to the Microgateway Engine. These proxy sidecars are part of the Istio data plane.

This article shows the architecture of a small Cilium setup with only one Airlock Microgateway-protected web application deployed in a Kubernetes cluster. Cilium is deployed to bring their features for the lower OSI layers (routing, observability, ...) with eBPF. Meanwhile, Airlock Microgateway brings security on layer 7 as a WAAP (web application and API protection, formerly known as WAF - web application firewall.

The simple example shows a setup with a single web application, the Microgateway Operator and the Cilium agent in a single Node. In the Web application Pod the Microgateway Engine is injected as sidecar.

The Microgateway Operator container injects the Microgateway Engine Container into Web application Pods, labeled with sidecar.microgateway.airlock.com/inject: "true".

• The Operator configures the Engine based on Custom Resources that contain the Engine configuration.
• The Microgateway CNI plugin of the Node configures the network routing between Engine and Web application container.
• The Cilium CNI plugin of the Node is used to bring the network capabilities provided by Cilium.

1. A Web client wants to access the Web application. The request is sent to the Ingress controller of the Kubernetes cluster.
2. The Ingress controller accepts the incoming traffic from outside the cluster and forwards it to the Web application Service.
3. The Web application Service forwards the traffic to the Web application Pod.
   In this Pod, all traffic is routed through the Microgateway Engine container and subsequently to the Web application container as configured by the Microgateway CNI plugin.
4. The Microgateway Engine container writes logs to /dev/stdout. A logging service can collect and visualize these logs in a graphical reporting solution.
5. The Prometheus Pod scrapes metrics from the Microgateway Engine containers that can be visualized, e.g., using Grafana.

1. The Microgateway Operator reads its configuration from the Microgateway Operator Configuration at startup and watches for events such as Pod create, update , or delete.
2. When a Web application Pod is created with a sidecar.microgateway.airlock.com/inject label, the following happens:
1. The Microgateway Operator injects the Microgateway Engine and Session Agent container.
2. The Microgateway CNI plugin configures the routing within the Web application Pod so that all traffic is routed through the Microgateway Engine.


The CNI configuration is used to chain the Cilium with the Microgateway CNI plugin and use both products together.

3. The Microgateway Network Validator performs a quick sanity check of the network routing configured by the Microgateway CNI plugin.
3. The CustomResource SidecarGateway includes a podSelector that selects the group of Pods to which the configuration applies.
4. The CustomResource SidecarGateway refers to other resources that should be applied.
5. The Microgateway Operator reads the involved configuration and sends it to the Microgateway Engine.
6. The Microgateway Operator watches the Microgateway Engine configuration resources. If these resources have been altered, the Microgateway Operator updates the Microgateway Engine with the new configuration.