Cloud Armor isn’t just a firewall; it’s a sophisticated Web Application Firewall (WAF) that acts as a managed, global denial-of-service (DDoS) and application attack protection service for your Google Cloud Platform (GCP) applications.
Let’s see it in action. Imagine you have a backend service, say a GKE cluster serving a web app, and you want to protect it from common web attacks like SQL injection and cross-site scripting (XSS).
First, you’d create a Cloud Armor security policy. This policy is a collection of rules that define how traffic should be handled.
gcloud compute security-policies create my-web-app-policy \
--description "WAF policy for my web application"
Now, let’s add some rules. A common one is to block traffic containing common SQL injection patterns. Cloud Armor has pre-defined WAF rules that make this easy.
gcloud compute security-policies rules create 1000 \
--security-policy my-web-app-policy \
--expression "evaluatePreconfiguredWaf('sqli-stable')" \
--action "deny-403" \
--description "Block SQL injection attempts"
Here, 1000 is the priority of the rule (lower numbers are evaluated first). evaluatePreconfiguredWaf('sqli-stable') tells Cloud Armor to use its managed SQL injection detection rules. If a match is found, the action is deny-403, meaning we return a Forbidden (403) error to the client.
You’d do the same for other common attack vectors:
gcloud compute security-policies rules create 1001 \
--security-policy my-web-app-policy \
--expression "evaluatePreconfiguredWaf('xss-stable')" \
--action "deny-403" \
--description "Block Cross-Site Scripting (XSS) attempts"
And for protecting against common vulnerabilities like the Log4Shell exploit:
gcloud compute security-policies rules create 1002 \
--security-policy my-web-app-policy \
--expression "evaluatePreconfiguredWaf('cve-2021-44228-stable')" \
--action "deny-403" \
--description "Block Log4Shell exploit attempts"
Once you have your rules defined, you associate this security policy with your backend service, typically a Global External HTTP(S) Load Balancer.
gcloud compute backend-services update my-backend-service \
--security-policy my-web-app-policy \
--global
This is where the magic happens. All incoming traffic to your my-backend-service will now first be inspected by the Cloud Armor policy. If any of the WAF rules match, the traffic is blocked before it even reaches your application instances. This offloads the burden of detecting and mitigating common attacks from your application servers.
Cloud Armor also offers custom rules, allowing you to define your own logic based on request headers, query parameters, cookies, and more. For instance, you might want to allow traffic only from specific IP ranges or block requests with suspicious user agents.
gcloud compute security-policies rules create 10 \
--security-policy my-web-app-policy \
--expression "origin.ip == '192.0.2.1'" \
--action "allow" \
--description "Allow traffic from trusted IP"
This rule, with a priority of 10, explicitly allows traffic from 192.0.2.1. Because it has a lower priority number, it’s evaluated before the WAF rules. You’d typically have a default rule at the end to deny all other traffic if you’re not using Cloud Armor’s default "deny all" behavior.
gcloud compute security-policies rules create 2147483647 \
--security-policy my-web-app-policy \
--expression "true" \
--action "deny-403" \
--description "Default deny all traffic"
The evaluatePreconfiguredWaf function is fascinating because it’s not just a static list of patterns. Google Cloud continuously updates these managed rulesets based on emerging threats and vulnerabilities. This means your WAF protection gets stronger over time without you needing to manually update rule signatures. The -stable suffix indicates you’re using the current, well-tested version of the rules. There are also -preview versions for early access to new rules.
The true power of Cloud Armor lies in its global distribution. It operates at the edge of Google’s network, meaning malicious traffic is dropped far from your application infrastructure, significantly reducing latency and the load on your backend. This global presence is key to its effectiveness against large-scale DDoS attacks as well.
When configuring Cloud Armor, remember that the order of rules matters immensely. A lower priority number means the rule is evaluated earlier. If a request matches a rule, the specified action is taken, and no further rules in that policy are evaluated for that request. This allows you to create precise control flows, like allowing specific trusted sources before applying broad WAF protections.
The next step after implementing basic WAF rules is often to explore rate limiting to prevent brute-force attacks and fine-tune custom rules based on observed traffic patterns.