Airlock Gateway vs. Airlock Microgateway

The purpose of this article is to describe the differences between the components Airlock Gateway and Airlock Microgateway and how they can be combined for optimal synergy. The combination of both components allows different architectures which have their pros and cons. This article provides you with information to make a decision about which architecture is best for you.

Note that Airlock IAM is illustrated as a separate component outside Kubernetes to enhance clarity – this is not a requirement. Airlock IAM can also be deployed as a pod in Kubernetes and still serve both Airlock Gateway and Airlock Microgateway. However, with the focus on Airlock Microgateway, this aspect is not further discussed here.

 
Notice

Depending on your decision for the overall system architecture, an Airlock Gateway may or may not be positioned in front of the Kubernetes cluster. This manual focuses only on the deployment of Airlock Microgateway inside the Kubernetes cluster (e.g., deployment in OpenShift or Kubernetes, with or without service mesh, ...) and does not discuss the placement nor functionality of the Airlock Gateway. This has been done to simplify the manual and does not imply any additional meaning.

Characteristics of Gateway and Microgateway components

Both Airlock Gateway and Airlock Microgateway have distinct characteristics. One or the other may be preferable in different architectural environments. Consult the following table to find the best match for your project.

Airlock Gateway

Airlock Microgateway

Architecture

  • Appliance with hardened OS
  • Secured container images and restricted permissions

High Availability

  • Load balancing
  • Back-end failover
  • Self-healing nurses
  • External checks are possible

These functionalities are built-in, except for the external checks.

  • Load balancing
  • Failover to upstream service
  • Readiness and Liveness Probe endpoints

Kubernetes built-in functionalities are used. Microgateway supports the required integration.

Configuration interface

  • Graphical UI
  • Kubernetes CRs (Custom Resources)

Scriptable

  • Yes, through REST API.
  • Yes, with common Kubernetes tools.

GitOps friendly

  • Partly
  • A script to bootstrap the Gateway through REST API can be created and stored in Git.
  • Yes

Security model

  • Perimeter security
  • Zero Trust
  • Perimeter security with Kubernetes Gateway API

Configuration agility

Suited best to the following change frequencies:

  • moderate
  • infrequent

Suited for any change frequency:

  • frequent
  • moderate
  • infrequent

Airlock version

All web applications are protected with the same Airlock Gateway. Therefore, the same Gateway version is used for all web applications.

Web applications could share the same or use an dedicated Airlock Microgateway. Therefore, the Airlock Microgateway version to protect a web application can be controlled.

Bundle web application with Airlock

  • No

Because Airlock Gateway is shared, at least the Gateway version can not be bundled to a particular web application version.

  • Yes

Bundling a certain Airlock Microgateway configuration with a particular web application is possible.

Configuration maintained by

  • Security team
  • Security team
  • Project team
  • Developers

Shared responsibility.

Enforcing security settings
(baseline security)

  • Restricted access to configure Airlock Gateway
  • Policies for 3rd party tools like Open Policy Agent Gatekeeper, Kyverno or Kubewarden enforce certain Airlock Microgateway settings.
  • With RBAC in Kubernetes, access to certain CustomResources can be restricted.

The security team can enforce settings and control who has access to which Custom Resources in case different teams maintain the configuration.

Authentication enforcement

  • With Airlock IAM using the Airlock Control API.
  • With any IAM using OIDC.

Security know how

  • Centralized in the security team.

Depending on team responsibilities and processes the security policies can be configured in a centralized or decentralized way (or even a mix of it).
Based on that, the required know how must be present in those teams:

  • Centralized in the security team.
  • Decentralized in many teams.

Must likely the security team is still responsible for the overall security, also if the policies are configured decentralized in the teams. But in such case security know-how must also be present in other teams as well. The security team enables them with templates, guidelines and education.

Processes

 

  • Ticketing
  • Maintenance Windows
  • DevSecOps
  • Shift Left

Which architecture should I use?

Depending on your needs, a particular architecture blueprint will be best suited for you. The table below provides some arguments for the different architectures and should assist you in the decision-making process.

Architecture A

Architecture B

Architecture C

Strengths of the different architectures

  • No or not much Kubernetes workload.
  • Requires 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.
  • Perimeter to secure any enterprise workload.
  • Classic workloads must be protected.
  • Kubernetes workloads must be protected.
  • Establishes DevSecOps principles with shared responsibility for Kubernetes workload.
  • Zero Trust architecture for Kubernetes workload.
  • Short development lifecycle for Kubernetes workload. Therefore the need to bundle the security policies with the web application.
  • No need for a classic perimeter.
  • Single solution to protect classic and Kubernetes workloads.
  • Establishes DevSecOps principles with shared responsibility.
  • Zero Trust architecture for Kubernetes workload.
  • Short development lifecycle and therefore the need to bundle the security policies with the web application.

Baseline vs. fine-grained security

The idea of baseline security is to have a basic set of general security settings enforced for all web applications. These settings should be generic and have a long lifecycle, i.e., they will not change much when upgrading applications. An example of a baseline security setting is the public TLS cipher configuration.

Fine-grained security settings, however, are tightly coupled to a specific web application and enable strict security policies. These settings bring in-depth security and protect the web application from serious attacks. They are usually specific to a web application and may therefore change with new application versions. An example of a fine-grained security setting is an OpenAPI specification for API calls.

 
Risk

It is not recommended to expose web applications to the Internet only with baseline security applied.

Depending on which architecture you have chosen, the baseline security settings are configured in different components. If Airlock Gateway is in front of the Kubernetes cluster, it takes care of baseline security. It has the advantage that, since only the security team can modify the configuration, these settings are easily enforced.
If no Airlock Gateway is installed in front of the Kubernetes cluster, baseline security will also be handled by the Airlock Microgateway.

The list below provides some hints on what kind of setting is more part of baseline or fine-grained security.

Baseline security

  • TLS ciphers and protocols
  • TLS certificates (public facing)
  • Allow rules:
    • Allow traffic only from certain IP networks.
    • Allow only the standard HTTP methods.
  • Deny rules:
    • Rules with low false-positive rates.
    • Deny rule for current vulnerabilities (e.g. Log4Shell).
    • Prevent admin interfaces being exposed.
  • Security headers (HSTS, X-Frame-Options, ...)
  • Enforce authentication:
    • Allow only authenticated users to send requests to the protected services.
      (if a Gateway is in front of a Microgateway, the Microgateway will re-evaluate if the user is authorized).
  • Geolocation blocking
  • Threat Intelligence
  • Anomaly Shield (machine learning)
  • Malware scanning
  • Attach co-browsing solution
  • ...

Fine-grained security

  • OpenAPI specifications
  • GraphQL Schema validation
  • TLS ciphers and protocols (for service-to-service communication)
  • Deny rules and their exceptions:
    • Strict rules
    • Handle possible false-positives with application-specific exceptions.
  • Security headers (application-specific like CSP)
  • Verification of authentication tokens
  • ...