Introduction

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.

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

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.

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