Configuration concepts
Microgateway configuration concepts

General concept

When following the principle of microservices, every service should accomplish a single task - the task it was designed for. This also applies to the Microgateway.

While chapter Cascaded services already gave a high-level overview of how services can and should be protected, this chapter illustrates how the configuration must be organized.

All example configurations outlined below consist of the following parts:

  • The end-user who wants to access a web application
  • The Microgateway which is protecting the web application(s). It can be split into the configuration parts below:
    • 1.
      The whole Microgateway, including the external files as outlined in Microgateway architecture and interfaces.
    • 2.
      global settings, which are applied to the whole Microgateway.
    • 3.
      apps, which are composed of virtual_host and mapping configurations.
    • 4.
      virtual_host, which defines the listener settings and the connection to the mappings.
    • 5.
      mappings, which define the security and integration settings that are applied to the requests passed to the back-end. If more than one mapping is underneath the virtual_host, the one with the most specific entry_path.value will be used.
    • 6.
      backend, which defines the service the request should be sent to. It is possible to configure more than one backend.hosts. If so, the Microgateway will randomly select a host and ensure session affinity for mappings in sessionful mode.

    Further information about the defaults and the structure of the configuration can be found in Configuration.

  • The back-end service (web application) itself.

Simple configuration

This configuration fits well for a simple web application which does not require special treatments for different kind of requests.


All requests received by the virtual_host will be processed according to the settings in the mappings virtinc. Finally, the request will be forwarded to the backend webapp.cluster.local, which is a service within Kubernetes/OpenShift.

Whenever possible, use this kind of setup to simplify your configuration.

Advanced configuration

In case that the Simple configuration does not fit well, because some requests require different treatments, additional mappings are required. This way, specific settings can be applied for certain request paths.


All requests received by the virtual_host will be processed either according to the settings in the mappings virtinc or virtinc_api. The mapping with the most specific entry_path.value will be applied to the request. Finally, the request will be forwarded to the backend webapp.cluster.local, which is a service within Kubernetes/OpenShift.

An example for such a setup is where an OpenAPI Spec is only available for the API part of the web application but not for the rest of the app. This way the OpenAPI Spec. can be configured in the virtinc_api mapping while the other mapping does not enforce this setting.

In case of the web application requires different treatments on certain paths, this is a recommended way to accomplish that. Nevertheless, ensure to not overdo and create to many mappings. That would make operation much harder.

Complex configuration

In this example, the web application consists of several services but should be protected with the same Microgateway.


The requests received by Airlock Microgateway will be handled by the corresponding virtual_host. The settings of mapping which belongs to this virtual_host will be applied to the request and finally forwarded to the configured backend service within Kubernetes/OpenShift.

The example shows two virtual hosts, each connected through a mapping with their back-ends. Another variant could be, that only one virtual host is connected with those two mappings and their back-ends. This might be required for setups where the application itself consists out of several back-end services.

Whenever possible, try to mitigate such complex configurations. This is in fact the architecture outlined in Single Microgateway with multiple services, which is definitely not recommended. Since all back-end services share the same Microgateway, side effects could occur when changing the configuration. Therefore, the services are not independent.