About Airlock Microgateway

Airlock Secure Access Hub consists of Airlock IAM, Airlock Gateway and Airlock Microgateway. They complement one another to provide authentication and comprehensive protection services for web applications.

Airlock Microgateway is a containerized Web Application and API Protection (WAAP) solution particularly well suited to microservice architectures, allowing to decouple security from business logic and enabling teams to live DevOps principles. Airlock Microgateway provides comprehensive protection against OWASP Top 10 vulnerabilities by analysing HTTP traffic before it is forwarded to the protected service. Security guidelines can be established and enforced company wide by the security team.

Different patterns are available to integrate Airlock Microgateway​ into the existing system architecture depending on company needs. The table below showcases different architectures to support the decision-making process. Further information is provided in chapter System architecture.

Architecture A

Architecture B

Architecture C

Architecture Gateway with Microgateway
Architecture Microgateway without Gateway
Architecture Gateway without Microgateway

Reasons to choose which architecture

  • Perimeter to secure any enterprise workload.
  • Classic workloads must be protected.
  • Kubernetes workloads must be protected.
  • Establish DevSecOps principles with shared responsibility for Kubernetes workload.
  • Zero Trust architecture for microservices.
  • Short development lifecycle for Kubernetes workload. Therefore the need to bundle the security policies with the web application.
  • No need for a perimeter.
  • No classic workloads to protect.
  • Kubernetes workloads must be protected.
  • Establish DevSecOps principles with shared responsibility.
  • Zero Trust architecture.
  • Short development lifecycle and therefore the need to bundle the security policies with the web application.
  • No or not much Kubernetes workload.
  • Not much Kubernetes know-how.
  • Classic workloads must be protected.
  • Security policies should be created and maintained by a single team (no shared responsibility).
  • No need for Zero Trust architecture.