Microgateway architecture and interfaces

Airlock Microgateway provides advanced security features for protecting HTTP/HTTPS back-end applications and APIs. Since version 2.0, Airlock Microgateway uses the Kubernetes init container concept, which uses one container for configuration generation and one for runtime deployment. This separation of initialization and runtime aspects helps to minimize the resource footprint of the runtime container.

Accordingly, the Microgateway is split into two containers: The Microgateway Configbuilder, which reads the domain-specific language and additional provided files, and the runtime container which filters the traffic. The illustration below outlines the two containers along with the most important interfaces, involved files and services.

• reads ...
• the config.yaml file, which contains the DSL.
• the license file.
• the certificates (optional).
• custom error pages (optional).
• other files referenced in the DSL(optional).

• writes ...
• the configuration files for the Microgateway runtime container in /resources-gen/, based on the provided configuration (DSL, license file, certificates, ...).
• log messages to stdout.
• the termination log file /dev/termination-log with content:
  {result: "successful"|"error", message: "<Log message for success or failure>"}

• reads the configuration files provided in /resources-gen/
• accepts, filters and forwards the external traffic to the back-end service.
• writes log messages to stdout.
• writes and reads session data into the redis database (optional).
• provides metrics which could be scraped with Prometheus.