Sidecar mode

Within the Kubernetes cluster, the Microgateway Operator container injects and operates the Airlock Microgateway containers in the Web application Pod. This section describes how these pieces are connected together and what exactly is modified and done by the Microgateway Operator. It also covers the network configuration task of the Microgateway CNI plugin, which configures the network routing through Microgateway Engine sidecars within Web application Pods.

The following example illustrates the setup when no service mesh is used. The setup shows two namespaces, airlock-microgateway-system for the Microgateway Operator Pod and a second one for 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”. In addition, the Microgateway Operator monitors these pods and reconfigures them whenever a Custom Resource changes.

Helm Microgateway Operator chart configuration must take place before or with installation or upgrade. The configuration can be persistently adjusted in a local values.yaml file or passed with every Helm installation using the --set option.

helm install airlock-microgateway -n airlock-microgateway-system oci://quay.io/airlockcharts/microgateway \​ 
    --set operator.watchNamespaces[0]=airlock-microgateway-system --wait --version 4.5.0

helm install airlock-microgateway -n airlock-microgateway-system oci://quay.io/airlockcharts/microgateway \​ 
   --set dashboards.create=true --version 4.5.0 --wait​ 

Any communication between containers in the airlock-microgateway-system namespace and, i.e., Microgateway Engine containers in web application namespaces, is secured using TLS/mTLS.

During the Microgateway Operator startup, the following self-signed certificates are generated and stored as secrets in the airlock-microgateway-system namespace:

Each time an Airlock Microgateway Engine sidecar is injected, an airlock-microgateway-bootstrap-secret is generated and saved to the web application namespace. 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.

The Microgateway Operator injects the Microgateway Engine containers to the upstream application Pods triggered by the label following label:

sidecar.microgateway.airlock.com/inject: "true"

See also example manifests w/o Istio mesh configuration at the end of this article.

Annotations can be added to configure some general behavior of the container. The table below lists and explains the annotations the Microgateway Operator is aware of.

The following example Kubernetes manifest file contains annotations to protect the web application with Airlock Microgateway.

apiVersion: apps/v1  
kind: Deployment  
metadata:  
  labels:  
    app: echo-server  
  name: echo-server  
spec:  
  selector:  
    matchLabels:  
      app: echo-server  
  template:  
    metadata:  
      annotations:  
        sidecar.microgateway.airlock.com/excludeInboundPorts: "9998,9999" 
        sidecar.microgateway.airlock.com/serviceMesh: "none" 
       labels:  
        sidecar.microgateway.airlock.com/inject: "true"  
        app: echo-server  
        version: 1.0.0
    spec: 
      containers: 
        - image: ealen/echo-server:latest 
          name: echo-server 
          ports: 
            - containerPort: 5051

Ensure that in such a setup the annotation sidecar.microgateway.airlock.com/serviceMesh is set to none or not set at all.

The following example Kubernetes manifest file contains annotations to protect the web application with Airlock Microgateway alongside Istio service mesh:

apiVersion: apps/v1  
kind: Deployment  
metadata:  
  labels:  
    app: echo-server  
  name: echo-server  
spec:  
  selector:  
    matchLabels:  
      app: echo-server  
  template:  
    metadata:  
      annotations:  
        sidecar.microgateway.airlock.com/excludeInboundPorts: "9998,9999" 
        sidecar.microgateway.airlock.com/serviceMesh: "istio" 
        sidecar.istio.io/inject: "true"  
      labels:  
        sidecar.microgateway.airlock.com/inject: "true"  
        app: echo-server  
        version: 1.0.0
    spec: 
      containers: 
        - image: ealen/echo-server:latest 
          name: echo-server 
          ports: 
            - containerPort: 5051

Ensure that in such a setup the annotation sidecar.microgateway.airlock.com/serviceMesh is set to istio.

After labeling a Pod with sidecar.microgateway.airlock.com/inject: “true”, the Microgateway Operator injects the Microgateway Engine and Session Agent container into the labeled Pod. The Microgateway Engine is injected as a sidecar in the protected Pod to secure them. It is built based on the Envoy proxy and enriched with Airlock-specific features.

To configure the Microgateway Engine, we created the required Custom Resource Definitions. See also the Airlock Microgateway API reference documentation detailed information, such as example configurations and default settings of the CRs. When integrating or hardening a web application, only the settings within the CRs are required.

The Microgateway CNI DaemonSet should be installed in the kube-system Namespace. This should be done using our CNI Helm chart. See installation-related articles for environment-depending installation.

The CNI Helm chart also installs a ServiceAccount with the ClusterRole, ClusterRoleBinding and a ConfigMap.
OpenShift requires to install Role and RoleBinding used for SCC and a NetworkAttachmentDefinition and adapting the k8s.v1.cni.cncf.io/networks annotation to allow the CNI plugin to work together with OpenShift Multus as described in the article Installation and uninstallation.

After the installation, the airlock-microgateway-cni DaemonSet is installed in the kube-system Namespace and will deploy one Microgateway CNI plugin to every Node. Once a Microgateway CNI plugin is installed on a Node, it handles the network configuration inside containers with Microgateway Engine Pods every time an Engine is created.

The default installation values like the image registry and image name can be looked up and modified to your needs in the values.yaml file of the CNI Helm chart. For detailed information about the default configuration values and their meanings, see the explanations in the values.yaml file.

The Microgateway Session Agent is automatically injected as a sidecar with the Microgateway Engine sidecar. The Session Agent handles the session store connection to the Redis database, which caches the session information. Access control requires session handling, including a Redis deployment ( as a session store. Configuration is done in the CRDs CR RedisProvider and CR SessionHandling.