System architecture

The purpose of this article is to describe the differences between 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. Almost all the rest of this manual focus 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 the 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
  • Container (Sidecar)
  • 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 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

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.

The same Airlock Gateway version is used for all web applications.

  • Each web application can use its own Airlock Microgateway.

The Airlock Microgateway is not shared, each web application can use the version required.

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 version with its configuration to a particular web application version 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.

Security know how

  • Centralized in the security team
  • Decentralized in many teams

The security team is still responsible for the overall security, but security know-how must also be present in other teams. 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 another architecture blueprint fits best for you. The table below provides you with some arguments for the different architectures and should assist you in the decision-making process.

Architecture A

Architecture B

Architecture C

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.

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. Enforcement requires correct use and setup of Kubernetes tooling (see Enforce policies).

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
  • TLS ciphers and protocols (for service-to-service communication)
  • Allow rules (only allow what is required by the web application)
  • Deny rules and their exceptions
    • Strict rules
    • Handle possible false-positives with application-specific exceptions
  • Security headers (application-specific like CSP)
  • Verify authentication tokens
  • ...