Airlock Microgateway configuration with K8s Gateway API

In the sidecar-based K8s Gateway API data plane mode, the Microgateway Operator monitors and reconfigures the Microgateway Engine Pods whenever a K8s Gateway API CRs (e.g. Gateway or HTTPRoute, etc.) changes. The same happens when a ContentSecurityPolicy with additional Microgateway CRs is deployed to customize/extend the built-in Airlock Microgateway security, e.g., by adding custom deny rules or additional limits.

Configuration examples of K8s Gateway API CRs

Configured CR

Description

GatewayClass

Our example GatewayClass CR contains the Airlock Microgateway controllerName.
The name must match the Microgateway Controller name configured in the Operator Helm chart (default: microgateway.airlock.com/gatewayclass-controller.

For more information about the GatewayClass CR, see the official documentation of the GatewayClass.

copy
apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: airlock-microgateway
spec:
  controllerName: microgateway.airlock.com/gatewayclass-controller
  description: This is an example GatewayClass.

Gateway

Our example Gateway CR contains the target namespace for the Microgateway Engine Pod and other details. , the name of the Microgateway Engine Pod, and the Namespace in which this Pod will be deployed.

For another example, see the official example for a simple Gateway.

copy
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: gateway-example
  namespace: example-backend-gw
spec:
  gatewayClassName: airlock-microgateway
  listeners:
    - name: http
      hostname: "*.example.com"       
      port: 80
      protocol: HTTP
    - name: https
      hostname: "*.example.com"   
      port: 443
      protocol: HTTPS
      tls:
        mode: Terminate
        certificateRefs:
          - name: downstream-server-certificate

HTTPRoute

The HTTPRoute CR configures the routing between the Microgateway Engine Pods and back-end application(s). As our example with different Namespaces for the Microgateway Engine Pod and the example application Pod demonstrates, cross-Namespace-routing can be configured.

To secure your back-end application(s), you must configure the incoming traffic to be routed through the Microgateway Engine Pod. We strongly recommend testing your routing configuration by generating test requests and checking the Access Log.

Airlock Microgateway does currently not support Listener Isolation. For more information, see the official documentation on Listener Isolation.

For more information about the HTTPRoute CR, see the official documentation of the HTTPRoute.

copy
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: backend
  namespace: example-backend-gw
spec:
  parentRefs:
    - group: gateway.networking.k8s.io
      kind: Gateway
      name: gateway-example
  rules:
    - backendRefs:
        - group: ""
          kind: Service
          name: example-backend
          namespace: example-backend-app
          port: 8080

ReferenceGrant

Cross-namespace routing can be configured, for example, with a ​ReferenceGrant CR​. In the spec section of the following example, we allow routing access from the example-backend-gw Namespace to the example-backend-app Namespace.

For more information, see the official documentation of the ReferenceGrant.

copy
apiVersion: gateway.networking.k8s.io/v1beta1
kind: ReferenceGrant
metadata:
  name: backend
  namespace: example-backend-app
spec:
  from:
    - group: gateway.networking.k8s.io
      kind: HTTPRoute
      namespace: example-backend-gw
  to:
    - group: ""
      kind: Service
      name: example-backend

ContentSecurityPolicy CR example configuration

To implement custom deny rules, limits, etc., a ContentSecurityPolicy CR can be added. This CR is a Direct Policy Attachment for the K8s Gateway API. It allows adding Airlock Microgateway-specific CRs to secure web applications in a K8s Gateway API-based data plane mode. It does so by referencing various other CRs covering different customized web application security aspects.

Airlock Microgateway uses a security-by-default strategy and will apply the built-in security measures to traffic routed between the Microgateway Engine Pod and any back-end application. However, in some situations, such as initial application integration, it can be helpful to disable the built-in security measures temporarily. This can be done by setting up a ContentSecurityPolicy with unsecured: {}.

Configured CR

Description

ContentSecurityPolicy

The following example is a copy from our CR ContentSecurityPolicy reference documentation.

copy
apiVersion: microgateway.airlock.com/v1alpha1
kind: ContentSecurityPolicy
metadata:
  name: content-security-example
  namespace: example-backend-gw
spec:
  targetRefs:
    - group: gateway.networking.k8s.io
      kind: HTTPRoute
      name: backend
  secured:
    parserRef:
      name: parser-example
    limitsRef:
      name: limits-example
    filter:
      denyRulesRef:
        name: deny-rules-example
    apiProtection:
      openAPIRef:
        name: open-api-example
      graphQLRef:
        name: graphql-example

Grafana dashboard configuration

Airlock Microgateway offers several preconfigured Helm-based Grafana dashboard templates that can be enabled and individually disabled in the Operator Helm chart.

Configuration target

Description

Grafana dashboards

The following example makes the dashboard templates available for Grafana:

copy
helm install airlock-microgateway -n airlock-microgateway-system oci://quay.io/airlockcharts/microgateway \​ 
   --set dashboards.create=true --version 4.4.0 --wait --set=operator.gatewayAPI.enabled=true
  • Only one Microgateway Operator per cluster may be configured to provide the Grafana dashboard templates.
  • Grafana must be deployed with dashboards.create=true to enable the cluster-wide search for the dashboard templates.

TLS certificate generation and renewal

Any communication between containers in the airlock-microgateway-system namespace and, i.e., Microgateway Engine containers, is secured using TLS/mTLS.

During the Microgateway Operator startup, the following self-signed certificates are generated and stored as secrets in the airlock-microgateway-system namespace:

  • airlock-microgateway-ca-cert – the CA certificate to generate self-signed TLS certificates.
  • webhook-server-cert – the server certificate of the Microgateway Operator.

Each time an Airlock Microgateway Engine is deployed, an airlock-microgateway-bootstrap-secret is generated and saved to the Namespace of the Engine Deployment. This secret holds the required certificates and keys for mTLS-based communication between the Microgateway Engine and the Operator. The TLS certificates of the bootstrap secret are renewed automatically every 48h.

Further information and links