Zum Hauptinhalt springen

Airlock Microgateway

Airlock Microgateway ist eine Kubernetes-native Web Application Firewall (WAF), die deine Workloads vor gaengigen Webangriffen schuetzt. Auf der Nine Kubernetes Engine betreiben wir den Airlock-Microgateway-Operator fuer dich und stellen ein oder mehrere Kubernetes Gateways bereit, an die du deine Anwendungen ueber die standardisierte Kubernetes Gateway API anbindest.

info

Airlock Microgateway auf NKE befindet sich in einer fruehen Phase. Damit wir es auf deinem Cluster einrichten koennen, kontaktiere unseren Support. Dieser Artikel behandelt die Grundlagen und wird mit der Zeit erweitert.

Verfuegbarkeit​

Airlock Microgateway ist als optionaler Dienst fuer NKE-Cluster verfuegbar. Es ist noch nicht per Self-Service nutzbar: Kontaktiere uns, und wir installieren den Operator und erstellen die Gateways auf deinem Cluster.

Der Airlock-Microgateway-Operator ist eine clusterweite Komponente, daher gibt es einen Operator pro NKE-Cluster. Dieser eine Operator kann mehrere Gateways bereitstellen, sodass du auf demselben Cluster so viele Gateways anfordern kannst, wie du benoetigst.

Funktionsweise​

Sobald du Airlock Microgateway fuer einen Cluster anfragst, machen wir Folgendes:

  • Wir installieren den Airlock-Microgateway-Operator auf deinem NKE-Cluster.
  • Wir erstellen ein oder mehrere Gateways im von Nine verwalteten Namespace nine-system. Jedes Gateway erhaelt einen eigenen Load Balancer mit einer oeffentlichen IP-Adresse und einen stabilen Hostnamen (zum Beispiel production.<hash>.airlockgateway.nineapis.ch), auf den du deine eigenen Domains zeigen lassen kannst.
  • Wir richten Let's Encrypt-ClusterIssuer-Ressourcen ein, damit Zertifikate fuer deine Domains automatisch ausgestellt und erneuert werden.

Anschliessend bindest du deine eigenen Gateway-API-Ressourcen (ListenerSet, HTTPRoute) in deinen Anwendungs-Namespaces an, um den Traffic durch das Gateway zu leiten.

Warum die Gateway API​

Airlock Microgateway wird ausschliesslich ueber die Kubernetes Gateway API konfiguriert. Es funktioniert nicht mit den Ingress-Ressourcen, die anderswo auf NKE verwendet werden. Die Gateway API trennt die Zustaendigkeiten bewusst: Nine besitzt die gemeinsam genutzte Infrastruktur (das Gateway und seinen Load Balancer), waehrend du die anwendungsspezifischen Routing- und Sicherheitsressourcen (ListenerSet, HTTPRoute und die Airlock-Policies) in deinen eigenen Namespaces besitzt. Diese Aufteilung ermoeglicht es uns, das Gateway fuer dich zu betreiben und abzusichern, waehrend du die volle Kontrolle darueber behaeltst, wie dein Traffic geroutet und geschuetzt wird.

Verwendung​

Die folgenden Beispiele gehen davon aus, dass fuer dich ein Gateway namens airlock-production im Namespace nine-system erstellt wurde und dass deine Anwendung im Namespace my-app laeuft.

HTTPS-Listener mit automatischem TLS hinzufuegen​

Erstelle ein ListenerSet in deinem Anwendungs-Namespace, um dem Gateway einen HTTPS-Listener hinzuzufuegen. Wenn die Annotation cert-manager.io/cluster-issuer vorhanden ist, stellt cert-manager das Zertifikat fuer den angegebenen Hostnamen automatisch aus und erneuert es.

apiVersion: gateway.networking.k8s.io/v1
kind: ListenerSet
metadata:
  name: my-listeners
  namespace: my-app
  annotations:
    cert-manager.io/cluster-issuer: airlock-letsencrypt-production
spec:
  parentRef:
    name: airlock-production
    namespace: nine-system
  listeners:
    - name: https
      hostname: "myapp.example.com"
      port: 443
      protocol: HTTPS
      tls:
        mode: Terminate
        certificateRefs:
          - name: myapp-tls
            namespace: my-app
      allowedRoutes:
        namespaces:
          from: Same

Verwende beim Testen den Issuer airlock-letsencrypt-staging, um die Rate-Limits von Let's Encrypt zu vermeiden, und wechsle danach fuer echte Zertifikate zu airlock-letsencrypt-production.

Traffic an ein Backend leiten​

Binde eine HTTPRoute an den Listener an, um Anfragen an deinen Backend-Dienst weiterzuleiten:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: my-app-route
  namespace: my-app
spec:
  parentRefs:
    - group: gateway.networking.k8s.io
      kind: ListenerSet
      name: my-listeners
      namespace: my-app
      sectionName: https
  hostnames:
    - "myapp.example.com"
  rules:
    - backendRefs:
        - name: my-app-service
          port: 8080

Reiner HTTP-Traffic​

Jedes Gateway verfuegt ueber einen eingebauten HTTP-Listener auf Port 80, der auch zum Loesen der Let's-Encrypt-HTTP01-Challenges verwendet wird. Fuer reinen HTTP-Traffic kannst du eine HTTPRoute direkt an das Gateway anbinden, ohne ein ListenerSet:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: my-app-http
  namespace: my-app
spec:
  parentRefs:
    - name: airlock-production
      namespace: nine-system
      sectionName: http
  hostnames:
    - "myapp.example.com"
  rules:
    - backendRefs:
        - name: my-app-service
          port: 8080

Du kannst die Erreichbarkeit vor der DNS-Einrichtung testen, indem du den Hostnamen als Host-Header sendest:

curl -H "Host: myapp.example.com" http://<gateway-ip>/

Deine Domain auf das Gateway zeigen lassen​

Um Produktions-Traffic auszuliefern, erstelle einen CNAME-Eintrag fuer deine Domain, der auf den Hostnamen des Gateways zeigt:

myapp.example.com.  CNAME  production.<hash>.airlockgateway.nineapis.ch.

Den genauen Hostnamen fuer dein Gateway teilen wir dir bei der Einrichtung mit.

Fehlerantworten anpassen​

Airlock Microgateway kann die Antworten ersetzen, die deine Clients sehen, zum Beispiel die Fehlerseite, die bei einer blockierten Anfrage oder bei einem Fehler deines Backends zurueckgegeben wird. Definiere zuerst den Inhalt mit einer CustomResponse:

apiVersion: microgateway.airlock.com/v1alpha1
kind: CustomResponse
metadata:
  name: custom-404
  namespace: my-app
spec:
  statusCode: 404
  content:
    - contentType: text/html
      body:
        value: "<h1>Page not found</h1>"

Binde anschliessend eine CustomResponsePolicy an deine HTTPRoute an, um diese Antwort fuer passende Statuscodes auszuliefern:

apiVersion: microgateway.airlock.com/v1alpha1
kind: CustomResponsePolicy
metadata:
  name: my-app-custom-responses
  namespace: my-app
spec:
  targetRefs:
    - group: gateway.networking.k8s.io
      kind: HTTPRoute
      name: my-app-route
  policies:
    local:
      - responses:
          - statusCodeCondition:
              matcher:
                exact: 404
            customResponseRef:
              name: custom-404

Die CustomResponse, die CustomResponsePolicy und die referenzierte HTTPRoute muessen sich alle im selben Namespace befinden. Airlock bietet viele weitere Policies, etwa Traffic-Filterung, Header-Umschreibung und Rate-Limiting. Die vollstaendige Liste findest du in der Airlock-Microgateway-CRD-Referenz.

Zugriffslogs ansehen​

Das Gateway protokolliert jede Anfrage als strukturiertes JSON. Jeder Eintrag enthaelt eine Request-ID (das Feld http.request.id), mit der du eine einzelne Anfrage durchgaengig nachverfolgen kannst, zusammen mit der zugeordneten Route und der Angabe, ob Airlock die Anfrage zugelassen oder blockiert hat:

{
  "http": { "request": { "id": "4cddf510-516c-4cda-9066-3809dad0b249" } },
  "airlock": { "summary": { "action": "allowed" } }
}

Wenn Loki auf deinem Cluster aktiviert ist, werden diese Zugriffslogs automatisch gesammelt und du kannst sie in Grafana nach der Request-ID durchsuchen.

Weiterfuehrende Informationen​