Article 20 – Google Cloud Armor & DDoS Protection

When you deploy applications to the public internet, you are painting a target on your back. Automated bots, script kiddies, nation-state actors — the threats are constant. Your first line of defense is not the firewall on your VM. It is the network edge. And in Google Cloud, that defense is Cloud Armor.

Let me break down what Cloud Armor actually is, how it works, and how to configure it. No marketing fluff, just architecture, rules, and commands.

What Is Cloud Armor?

At its core, Cloud Armor is two things: a Web Application Firewall (WAF) and a DDoS mitigation service.

Here is the critical thing to understand — it is not something you install on a VM. It integrates directly with Google’s Global External Application Load Balancer to filter traffic before it ever reaches your backend services. It sits at the very edge of Google’s global network, so it can absorb and block petabyte-scale DDoS attacks and filter malicious requests like SQL injection, far away from your VPC.

How It Works — Policies and Targets

The entire model is built on two concepts:

Security Policy — A collection of rules with priorities. Each rule is an “if-then” statement:
– Priority 1000: If origin.ip is 1.2.3.4/32, then deny(403)
– Priority 2000: If request.path contains /etc/passwd, then deny(404)
– Default: allow

Target — The thing you attach the policy to. Usually a backend service.

When traffic hits your load balancer, it gets directed to a backend service. Cloud Armor intercepts the flow, evaluates the policies from top to bottom (lowest priority number first), and the first matching rule wins. It then executes the action — allow, deny, or throttle.

The nice thing is you can apply the same policy to multiple backend services, so you get consistent security across your entire application.

Core Features — Layer by Layer

Cloud Armor is not just an IP blocklist. Its capabilities span from L3 to L7.

L3/L4 DDoS Protection
This is the “always-on” protection. It defends against volumetric and protocol-based attacks like SYN floods, UDP floods, and TCP reflection attacks. This runs automatically at Google’s edge for any External Load Balancer. You do not need to configure anything.

L7 WAF Rules
This is where you will spend most of your time:

• Pre-configured WAF Rules — Apply Google-curated rulesets to instantly protect against the OWASP Top 10 vulnerabilities. One rule blocks common SQLi, XSS, Remote File Inclusion, and other attack patterns.

• Custom Rules using CEL (Common Expression Language) — Write your own rules based on any part of the HTTP request:

# Geo-blocking: Block traffic from a specific country
origin.region_code == 'KP'

# User-Agent blocking: Block a specific bot
request.headers['user-agent'].contains('BadBot')

# Complex logic: Block /admin unless from internal IP
request.path.matches('/admin/*') && !inIpRange(origin.ip, '10.0.0.0/8')

Rate Limiting
Critical for brute-force and scraping defense. You can throttle or ban clients that exceed a request threshold:
– “Allow no more than 100 requests per 5 minutes from any single IP”
– “Allow no more than 20 POST requests to /login.php per 10 minutes from any single IP”

Adaptive Protection (Enterprise Only)
Uses machine learning to analyze your normal traffic patterns. When it detects an anomalous L7 traffic spike — a potential application-layer DDoS — it generates an alert, suggests a blocking rule, and can automatically deploy it.

Threat Intelligence (Enterprise Only)
Block traffic based on Google’s own internal threat intelligence feeds — known malicious IPs, Tor exit nodes, and other indicators of compromise.

Standard vs. Enterprise

Standard is great for basic WAF and OWASP protection. Enterprise is for mission-critical applications that need automated L7 DDoS mitigation, threat intel, and financial protection.

Setting It Up — Step by Step

Let me walk you through building a security policy from the command line. Assume you already have a Global External HTTP(S) Load Balancer with a backend service called my-app-backend-service.

# Step 1: Create an empty security policy
gcloud compute security-policies create my-app-policy \
    --description "Main security policy for my-app"

Output:

Created [https://www.googleapis.com/compute/v1/projects/my-project/global/securityPolicies/my-app-policy].

# Step 2: Block a known bad IP (priority 1000 = evaluated early)
gcloud compute security-policies rules create 1000 \
    --policy my-app-policy \
    --expression "origin.ip == '198.51.100.10/32'" \
    --action "deny-403" \
    --description "Block known bad actor"

# Step 3: Apply OWASP Top 10 ruleset (priority 2000)
gcloud compute security-policies rules create 2000 \
    --policy my-app-policy \
    --expression "evaluatePreconfiguredExpr('owasp-crs-v33-stable')" \
    --action "deny-403" \
    --description "Apply OWASP Top 10 rules"

# Step 4: Set default rule to allow everything else
gcloud compute security-policies rules update default \
    --policy my-app-policy \
    --action "allow" \
    --priority 2147483647

# Step 5: Attach the policy to your backend service
gcloud compute backend-services update my-app-backend-service \
    --global \
    --security-policy my-app-policy

That is it. Your application is now protected by an IP blocklist, OWASP vulnerability rules, and Google’s edge DDoS mitigation.

Common Pitfalls and Best Practices

Pitfall: Thinking Cloud Armor only protects Compute Engine.
Best Practice: Cloud Armor protects any backend service — GCE instance groups, GKE via Ingress, Cloud Run, App Engine, and even on-prem servers configured as Internet NEGs.

Pitfall: Deploying rules directly to production without testing.
Best Practice: Use Preview Mode. Set a new rule to preview instead of enforce. It gets evaluated and logged but does not block traffic. This lets you test the impact before accidentally blocking legitimate users.

Pitfall: Forgetting to enable logging.
Best Practice: Enable logging on your load balancer’s backend service. Cloud Armor logs all actions (allowed, denied, previewed) to Cloud Logging. Without this, you are blind when troubleshooting blocked requests.

Pitfall: Starting from scratch with custom rules.
Best Practice: Always start by applying the pre-configured OWASP ruleset. It gives you a solid baseline against 90% of common attacks with zero custom development. Add custom rules on top.

Pitfall: Getting rule priority order wrong.
Best Practice: Remember — lower priority number = evaluated first. Priority 1000 runs before 2000. The default rule runs last at 2147483647. A common mistake is creating an allow rule at a high priority that accidentally bypasses a more specific deny rule.

Quick Reference

# Create a security policy
gcloud compute security-policies create [NAME]

# List all policies
gcloud compute security-policies list

# Describe a policy (see all rules)
gcloud compute security-policies describe [NAME]

# Create a rule in a policy
gcloud compute security-policies rules create [PRIORITY] \
    --policy [NAME] --expression "[CEL]" --action "deny-403"

# Update a rule
gcloud compute security-policies rules update [PRIORITY] --policy [NAME]

# Delete a rule
gcloud compute security-policies rules delete [PRIORITY] --policy [NAME]

# Attach policy to a backend service
gcloud compute backend-services update [BACKEND] \
    --global --security-policy [POLICY_NAME]