Protect GKE Ingress Traffic with Cloud Armor WAF (2026)

Cloud Armor WAF actually protects your GKE Ingress by acting as a shield before traffic even reaches your Kubernetes cluster.

Let’s see it in action. Imagine a common scenario: you’ve got a GKE cluster running a web application, and you want to block malicious requests.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-webapp-ingress
  annotations:
    kubernetes.io/ingress.class: "gce"
    networking.gke.io/managed-certificates: "my-cert"
    # This is the key annotation for Cloud Armor
    networking.gke.io/v1beta1.frontend-config: |-
      {"name": "my-frontend-config"}
spec:
  rules:
  - http:
      paths:
      - path: /*
        pathType: ImplementationSpecific
        backend:
          service:
            name: my-webapp-service
            port:
              number: 80

Now, you define the FrontendConfig resource that Cloud Armor will use:

apiVersion: networking.gke.io/v1beta1
kind: FrontendConfig
metadata:
  name: my-frontend-config
spec:
  # This points to your Cloud Armor security policy
  loadBalancing:
    httpsRedirect: true
  securityPolicy:
    name: "my-advanced-waf-policy"

And here’s a simplified example of that Cloud Armor security policy:

{
  "name": "my-advanced-waf-policy",
  "description": "WAF policy for GKE Ingress",
  "rules": [
    {
      "priority": 1000,
      "description": "Block common SQL injection attempts",
      "action": "deny(403)",
      "match": {
        "expr": {
          "expression": "request.headers['user-agent'].contains('sqlmap')"
        }
      }
    },
    {
      "priority": 2000,
      "description": "Allow all other traffic",
      "action": "allow"
    }
  ]
}

This setup means that when a request hits your GKE Ingress’s external IP, Google Cloud’s load balancer intercepts it. It checks the request against the rules defined in my-advanced-waf-policy. If a rule matches (like a sqlmap user-agent), the load balancer denies the request immediately with a 403 Forbidden response, without it ever reaching your my-webapp-service inside the GKE cluster. If no rules match, the load balancer forwards the request to your service.

The magic is that Cloud Armor is a managed service, so you don’t need to install or manage WAF software on your GKE nodes. It leverages Google’s global network to provide distributed denial-of-service (DDoS) protection and custom WAF rules. You control what gets in using familiar Kubernetes resource definitions and Cloud Armor’s policy language.

The priority field in Cloud Armor rules is crucial for determining the order of evaluation. Lower numbers are evaluated first. If a request matches a rule, its action is taken, and no further rules are evaluated for that request. This allows you to create a layered security approach, where specific malicious patterns are blocked with high priority, and then a general allow rule at a lower priority (higher number) permits legitimate traffic.

You can integrate Cloud Armor with other Google Cloud services for more advanced threat detection. For instance, you can use Cloud Logging to monitor WAF logs and trigger alerts or automated responses based on suspicious activity patterns identified by Cloud Armor. This allows you to move beyond static rule sets and adopt a more dynamic, intelligence-driven security posture.

The next step is often to explore pre-configured WAF rulesets provided by Cloud Armor for common threats like OWASP Top 10 vulnerabilities.