Kubernetes cluster with Cilium

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, annotated 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 annotation, the following happens:
1. The Microgateway Operator injects the Microgateway Engine 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.
7. The Microgateway License Guard is configured by the Microgateway Operator, depending on the current license. The License Guard monitors the traffic of Microgateway Engine Pods to enforce threshold limits.

• Internal links:
• Cilium