System architectures

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. Also, mind the section Data plane modes of Airlock Microgateway in this article.

Airlock Gateway

Airlock Microgateway

Architecture

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

  • Data plane mode

    • Sidecar
    • Kubernetes Gateway API

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.

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

Data plane mode

  • Sidecar:
    Same version for web applications in the same namespace.
  • Kubernetes Gateway API:
    Web applications could share same Airlock Microgateway or use a dedicated version.

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.

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

Data plane modes of Airlock Microgateway

Airlock Microgateway can be deployed in two data plane modes: sidecar to extend an application Pod with security or sidecarless with the Kubernetes Gateway API.
The following comparison chart lists the important differences between both data plane modes and can be used as a decision helper to select the best matching mode for your requirements:

Data plane mode:

Sidecar

Sidecarless with K8s Gateway API

Total resource consumption (CPU/Memory)

Low

Even lower

3rd party solutions licensing number of containers (e.g. DataDog)

Higher 3rd party license costs.

Lower 3rd party license costs.

Airlock Microgateway CNI plugin

Required

Not required

Supported service mesh compatibility

Istio and Cilium

No special compatibility requirements.

Update Microgateway Engine

Rollover of the application Pod.

Rollover of Microgateway​ (no impact on the application).

Traffic filtering with Airlock Microgateway

Automatically in-line​ (traffic is redirected first to Microgateway).

Filtering ensured with routing and network policies in Kubernetes.

Protected web application

Runs inside of Kubernetes.

Runs inside or outside of Kubernetes.

North-South traffic

Yes, for the protected Pod.

Yes

East-West traffic

Yes

Yes, by routing the traffic accordingly.

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.
For simplicity, drawings showing the Airlock Microgateway only show the sidecar-based data plane mode.

Architecture A

Architecture B

Architecture C

Architecture D

Applicable Airlock Microgateway data plane modes

  • Not applicable
  • Sidecar
  • K8s Gateway API
  • K8s Gateway API
  • Sidecar
  • K8s Gateway API

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 microservices.
  • 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. This requires descrete Airlock Microgateways per web application.
  • Short development lifecycle and therefore the need to bundle the security policies with the web application.
  • No need for a classic perimeter.
  • No classic workloads to protect.
  • Kubernetes workloads must be protected.
  • Establishes DevSecOps principles with shared responsibility.
  • Zero Trust architecture.
  • 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. 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
  • 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
  • ...