Application Gateway WAF vor AKS: AGIC oder AGFC?

Robin, Azure und Kubernetes bei Pexon Consulting | 10 Min. Lesezeit | 02.09.2026

TL;DR

Application Gateway WAF AKS hängt am klassischen Ingress Controller (AGIC) oder an Application Gateway for Containers mit Gateway API. AGIC ist der Bestandsweg, AGFC die Microsoft-Richtung. Beide nutzen dieselbe WAF-Policy. Der Unterschied sitzt bei TLS, Regelpflege und Team-Skills. Wer False Positives und SIEM nicht betreibt, bleibt im POC.

Warum Application Gateway WAF AKS keine zweite Firewall ist

Wer HTTP-Workloads auf AKS stellt, braucht eine Schicht vor dem Service, nicht vor dem API-Server. Application Gateway WAF AKS ist die Policy auf dem Application Gateway: OWASP-Regeln, Custom Rules, Bot-Manager. Der Cluster-API-Zugang ist ein anderes Tor. Den privaten API-Pfad ohne Jump Box beschreibt der private AKS-API-Zugang mit Azure Bastion.

Die häufige Verwechslung: „Wir haben schon NSG und Private Cluster, also brauchen wir keine WAF.“ NSG filtert Ports und CIDR. WAF liest HTTP. Health-Checks, Bingbot, SOAP-Endpunkte und alte Query-Parameter landen in den Logs als Treffer, obwohl der Request fachlich erlaubt ist. Ohne Tuning wird die Policy zum Ausfall.

Bei Energie-IT und Versicherungen, die Kundenportale vor AKS stellen, ist genau das der Einstieg: nicht ein zweites Gerät kaufen, sondern die Policy auf dem Gateway betreiben und False Positives in den ersten Wochen aktiv abbauen.

AGIC oder AGFC: welcher Controller trägt die Policy

AGIC (Application Gateway Ingress Controller) mappt Kubernetes-Ingress auf ein bestehendes Application Gateway. Das ist der Weg, den die meisten Bestände 2024/2025 live haben. Annotationen steuern Backend, Cookie-Affinity, TLS und teilweise WAF-Pfadregeln.

Application Gateway for Containers (AGFC) spricht Gateway API. Microsoft schiebt neue Features dorthin. Wer Greenfield macht und das Team Gateway-API schon in anderen Clustern nutzt, startet hier. Wer zwanzig Ingress-Objekte und Runbooks für Annotationen hat, bleibt bei AGIC, bis der Schnitt dokumentiert ist.

Beide Wege können dieselbe Azure-WAF-Policy binden. Der Architekturbruch entsteht, wenn das Team AGFC erwartet und das Gateway noch klassisch per AGIC beschrieben ist. Dann fehlen Listener, die Policy hängt am falschen Pfad, Health-Probes laufen auf HTTP statt HTTPS.

Microsoft Learn zu Azure WAF on Application Gateway bleibt die Referenz für Policy-Modus (Detection vs Prevention), Managed Rulesets und Custom Rules. Der Blog hier entscheidet den Controller, nicht das Regelwerk-Handbuch.

Ingress gegen Gateway API: ein YAML-Schnitt

Klassischer Ingress für AGIC, Host und Backend klar, WAF-Policy über Annotation am Pfad:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: portal
  namespace: apps
  annotations:
    appgw.ingress.kubernetes.io/ssl-redirect: "true"
    appgw.ingress.kubernetes.io/appgw-ssl-certificate: "portal-tls"
    appgw.ingress.kubernetes.io/waf-policy-for-path: "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-agw/providers/Microsoft.Network/ApplicationGatewayWebApplicationFirewallPolicies/portal-waf"
spec:
  ingressClassName: azure-application-gateway
  rules:
    - host: portal.example.de
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: portal
                port:
                  number: 80

Dieselbe App als HTTPRoute vor einem AGFC-Gateway. Die WAF-Policy hängt am Gateway in Azure, nicht an einer Ingress-Annotation:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: portal
  namespace: apps
spec:
  parentRefs:
    - name: agfc-gateway
      namespace: gateway-system
  hostnames:
    - portal.example.de
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /
      backendRefs:
        - name: portal
          port: 80

Die Subscription-ID im AGIC-Beispiel ist Platzhalter. In Production kommt der Resource-ID-String aus Terraform oder Bicep, nicht aus Copy-Paste in Git ohne Review. Wer den Cluster selbst noch nicht stehen hat, klärt zuerst AKS Consulting und Implementierung, nicht die WAF-Policy.

False Positives: das, was den Go-Live frisst

OWASP CRS trifft auf Portale mit Legacy-Query, Datei-Upload und XML. Typische erste Woche:

1. Health-Probe des Gateways landet in Custom Rules als Scan, bis der Probe-Path allowlisted ist.
2. Such-Query mit Sonderzeichen triggert SQLi-Regeln. Detection-Modus zuerst, dann gezielte Exclusions, nicht Prevention von Tag eins auf /.
3. Bot-Manager stuft Crawler der eigenen Monitoring-Suite falsch ein. User-Agent und IP-Range dokumentieren, sonst sterben synthetische Checks.
4. SOAP- oder XML-Body an Fachverfahren. Request-Body-Inspection limitiert oder Exclusion auf den einen Pfad, nicht Policy aus.

Ohne SIEM-Anbindung sieht niemand die Treffer. Diagnostic Settings am Application Gateway nach Log Analytics oder Sentinel. Erst wenn Exclusion und Alert dieselbe Ticket-Nummer haben, ist die Policy betreibbar.

Genau diesen Schnitt sehen wir bei Energie-IT, die Kundenportale vor AKS mit Azure WAF schützen: Regelwerk ist in zwei Tagen portiert, Betrieb (False Positives, Alerting, Freigabe-Prozess) fehlt Monate.

Production-Gap: Policy steht, Betrieb fehlt

Der Hub Kubernetes Beratung bleibt der Einstieg, wenn Cluster-Schnitt, Managed Service und Security-Audit noch offen sind. Dieser Artikel entscheidet nur Controller und Policy-Betrieb vor HTTP.

Häufig gestellte Fragen

Reicht eine NSG vor AKS statt WAF?

Nein. NSG kennt kein HTTP-Regelwerk. WAF liest Header, Body und OWASP-Sets. Beide Schichten, unterschiedliche Frage.

Ist AGFC Pflicht, weil Microsoft es so positioniert?

Nein. AGIC bleibt für Bestände mit Ingress-Betrieb der kürzere Weg. AGFC, wenn Gateway API schon Standard im Plattform-Team ist.

Kann ich WAF-Policy zwischen AGIC und AGFC wiederverwenden?

Die Policy-Ressource in Azure ist wiederverwendbar. Binding, Listener und Health-Probes musst du neu schneiden. Copy-Paste der Ingress-Annotationen nach HTTPRoute funktioniert nicht.

Was ist mit Front Door WAF statt Application Gateway?

Front Door sitzt global davor. Application Gateway WAF AKS bleibt regional vor dem Cluster. Manche Landschaften nutzen beides, mit klarer Zuständigkeit pro Regel.

Brauche ich WAF, wenn das Portal nur intern erreichbar ist?

Private Listener ändert nicht, dass HTTP-Payload geprüft werden soll. Interne Portale mit Legacy-APIs erzeugen oft mehr False Positives, nicht weniger.

Nächster Schritt

Verwandte Themen