Why a Microgateway?

With the advent of microservice architectures and DevOps practices, central security gateways concentrating many tasks for all services on a single system have increasingly been challenged.

While this approach allows dealing with issues "once and for all", it requires coordination between different application managers, between administrators and developers, and between the security team and all the others. Stakeholders may have differing requirements, timelines and policies for the single system they share.

Security professionals argue for security to be part of a deployment pipeline from the very first minute - as adding security as a last step before going into production is a recipe for disaster. It leads to the security team being blamed for missed deadlines, to unhealthy compromises and ongoing tension between teams.

Following DevOps principles, developers are asked to embrace operational responsibility for their services.

  • Hence, it is necessary to support DevOps teams with a dedicated security component that:
  • is lightweight (for coupling with microservices),
  • belongs to them (so they can take responsibility) and
  • follows DevOps best practices for automation and configuration.

This is where the Airlock Microgateway - as an addition to the Airlock Gateway appliance - comes in.

An architecture for securing microservices

The following architecture overview shows an Airlock Gateway and Airlock Microgateways in a cascaded setup - each with individual tasks and responsibilities.

Airlock Gateway - Appliance versus Microgateway
Figure: Airlock Gateway and Airlock Microgateway

Having a central Airlock Gateway in front of the Airlock Microgateway is no technical requirement. However, we believe it makes a lot of sense to distinguish between edge-oriented tasks and tasks tightly connected to the services.

The distinction between Airlock Gateway and Airlock Microgateway tasks may vary in specific setups.

In this scenario, the Airlock Gateway represents the central enterprise gateway. It controls all incoming traffic and acts as a policy enforcement point for authentication, authorization and API access. For this task, the Airlock Gateway requires a rather generic configuration, enabling quick and seamless integration of new services protected by individual Airlock Microgateway instances.

The Airlock Microgateway has detailed knowledge about its protected service. Typical integration tasks, such as adding deny rule exceptions, are done on the Microgateway. Thus, all service-specific details are located close to the service itself, minimizing role conflicts and handover problems at the central gateway.

To meet the different requirements of an edge gateway and a microgateway setup, Airlock has designed the Airlock Gateway and the Airlock Microgateway under complementary considerations.

Task split between Airlock Gateway and Airlock Microgateway

The following table indicates the main use cases for which the two components were designed:


Airlock Gateway

Airlock Microgateway

Main task

Publish web applications

Secure web applications


Appliance with hardened OS


High Availability

Loadbalancing and failover for Back-end service

Managed by container platform
offers probes for health checks

Authentication / Authorization

Policy Enforcement Point
Proxy for SSO
Interaction with Airlock IAM
Injection of internal token

Internal token validation


Baseline security

  • TLS ciphers and protocols
  • Session hijacking prevention
  • Threat Intelligence
  • Geo location blocking
  • HSM integration
  • Connection to Malware scanner
  • Connection to co-browsing solutions
  • ...

Strict security

  • Authentication enforcement
  • Allow rules
  • Deny rules and its exceptions
  • Enforcing OpenAPI spec.
  • ...

Service Integration

Generic turnkey configuration

Specific service integration

API Keys
API Usage Plans

Policy Enforcement Point
Interaction with Airlock IAM

Internal token validation


  • Graphical UI
  • REST API (imperative)
  • YAML file (declarative)