Cloud Armor and Network Security

Introduction to Google Cloud Armor

For a Professional Cloud Architect, application security at the edge is paramount. Google Cloud Armor is Google's enterprise-grade Web Application Firewall (WAF) and Distributed Denial of Service (DDoS) protection service. It leverages the same infrastructure that protects Google's own services (Search, Gmail, YouTube) to defend your applications.

Plain-Language Explanation: Google Cloud Armor

Cloud Armor is like the elite security team at the entrance of a high-profile event.

Analogy 1 — The Nightclub Bouncer (WAF)

Imagine a popular nightclub. Cloud Armor is the Bouncer at the door. The bouncer doesn't just check if you have an ID; they also look at your behavior. If you're carrying a hidden spray-paint can (SQL Injection) or trying to sneak in through the vent (Cross-Site Scripting), the bouncer stops you immediately. They have a "blacklist" of known troublemakers (IP Denylists) and a set of "house rules" (Security Policies).

Analogy 2 — The Flood Barrier (DDoS Protection)

A DDoS attack is like a flash flood of millions of people all trying to enter the nightclub at once, just to clog the doorway. Cloud Armor is a Massive Flood Barrier. Because it's built on Google's global network, it can absorb a "flood" of traffic that would drown a normal server, filtering out the fake "water" (attack traffic) and letting the real people through.

Analogy 3 — The Bot Sniper (Bot Management)

Some visitors aren't people; they're Robots trying to buy all the tickets to scalp them later. Bot Management is like a Sniper who can tell the difference between a real human heartbeat and a machine's click. It uses reCAPTCHA and behavioral analysis to stop the robots without slowing down the humans.

Key Features of Cloud Armor

1. WAF with Preconfigured Rules

Cloud Armor comes with pre-built rules based on the OWASP Top 10 vulnerabilities:

• SQL Injection (SQLi)
• Cross-Site Scripting (XSS)
• Remote File Inclusion (RFI)
• Local File Inclusion (LFI)

2. DDoS Protection

• Standard: Included for all GCP customers. Protects against common Layer 3 and 4 attacks.
• Managed Protection Plus: A subscription service that provides advanced Layer 7 protection, adaptive protection (ML-based), and DDoS cost protection (credits for scaling during an attack).

3. Adaptive Protection

Using machine learning, Cloud Armor analyzes your normal traffic patterns. If it detects a suspicious anomaly, it automatically suggests a new security rule to block the attack before it impacts your service.

4. Rate Limiting

Prevent users (or bots) from overwhelming your backend by limiting the number of requests they can make per second/minute based on IP, cookie, or header.

5. Bot Management & reCAPTCHA Enterprise

Integrates with reCAPTCHA to challenge suspicious traffic and block known malicious bots while allowing search engine crawlers.

Cloud Armor Security Policies

Policies are collections of rules that you attach to a Backend Service of an HTTP(S) Load Balancer.

• Priority: Rules are evaluated from lowest number to highest (e.g., a rule with priority 1000 is evaluated before 2000).
• Matching: Rules can match based on IP ranges, regions (Geo-blocking), or complex expressions (e.g., request.headers['user-agent'].contains('BadBot')).
• Actions: Allow, Deny (403, 404, or 502), Rate Limit, or Redirect to reCAPTCHA.

Edge Security Architecture

For a robust architecture, Cloud Armor should be the first line of defense:

1. Global HTTP(S) Load Balancer: Receives traffic at the Google Edge.
2. Cloud Armor: Inspects traffic before it reaches your VPC.
3. VPC Firewall: Restricts access so that your backends only accept traffic from the Load Balancer's IP ranges.
4. Backend (GCE, GKE, Cloud Run): Processes the cleaned, authorized traffic.

Adaptive Protection: Bayesian Anomaly Detection for L7 DDoS

Adaptive Protection is the ML-driven flagship of Managed Protection Plus. Unlike static WAF rules that match known signatures, it builds a per-security-policy baseline traffic model (typically requires 1+ hour of traffic to stabilise) using a Bayesian classifier over request attributes — URI patterns, source IPs, regions, user agents, JA3/JA4 fingerprints, ASN, and HTTP headers.

How the alert pipeline works

1. Traffic baseline: Continuous observation establishes "normal" probability distributions per backend service.
2. Anomaly score: When request distributions diverge (e.g., a sudden spike from one ASN hitting /login), Adaptive Protection emits an alert with a confidence score (0.0–1.0) and a likelihood.
3. Suggested rule: The alert ships a pre-formatted Cloud Armor rule expression (e.g., request.headers['user-agent'].contains('python-requests') && origin.region_code == 'XX') plus an impacted baseline ratio showing how much legitimate traffic the rule would also block.
4. Operator action: You review in Security Command Center or Cloud Logging (jsonPayload.enforcedSecurityPolicy.adaptiveProtection), then either auto-apply (via Cloud Functions trigger on the log sink) or manually attach.

Tuning knobs

• adaptiveProtectionConfig.layer7DdosDefenseConfig.enable = true per security policy.
• ruleVisibility = STANDARD | PREMIUM — Premium reveals attack signatures and impacted-baseline details.
• Alert threshold: Default fires at confidence ≥ 0.5; lower for noisy detection, raise for high-precision auto-mitigation.

Preconfigured WAF Rules: ModSecurity OWASP CRS Mapping

Cloud Armor ships preconfigured WAF rules derived from the OWASP ModSecurity Core Rule Set (CRS) 3.3. Each rule group is exposed as an evaluatePreconfiguredWaf() expression with a tunable sensitivity level (0–4) and optional opt_in_rule_ids / opt_out_rule_ids for granular control.

Rule group catalogue (selected)

Example rule expression

gcloud compute security-policies rules create 1000 \
  --security-policy=prod-armor \
  --expression="evaluatePreconfiguredWaf('sqli-v33-stable', {'sensitivity': 1})" \
  --action=deny-403

Sensitivity tuning trade-offs

• Level 1 (paranoid OFF): Lowest false-positive rate — only paranoia-level-1 ModSecurity rules fire. Default for production APIs handling structured payloads.
• Level 2–3: Adds heuristic rules (URL-encoded payloads, unusual character classes). Recommended for static sites or marketing pages.
• Level 4 (paranoid ON): Activates the full CRS paranoia level — expect false positives on legitimate base64 uploads, GraphQL queries, or rich-text editors. Tune via opt_out_rule_ids after enabling preview mode for at least 7 days.

Rate-Based Ban Rules: Beyond Throttling

Cloud Armor distinguishes two rate-limit actions: throttle (drop excess requests, allow legitimate ones through) and rate-based-ban (block the offending key entirely for a ban duration once a threshold is crossed).

Rate-based ban anatomy

gcloud compute security-policies rules create 2000 \
  --security-policy=prod-armor \
  --expression="true" \
  --action=rate-based-ban \
  --rate-limit-threshold-count=100 \
  --rate-limit-threshold-interval-sec=60 \
  --ban-duration-sec=600 \
  --ban-threshold-count=10000 \
  --ban-threshold-interval-sec=600 \
  --conform-action=allow \
  --exceed-action=deny-429 \
  --enforce-on-key=IP

Enforce-on-key options

• IP — Default; most scenarios.
• ALL — Single global counter; rarely useful except for "shut down everything during incident".
• HTTP_HEADER + key name — Ban per X-API-Key (best for authenticated APIs where IPs are NATed).
• XFF_IP — Trust the leftmost X-Forwarded-For (only when terminating CDN/proxy you control).
• HTTP_COOKIE — Per-session ban.
• HTTP_PATH — Path-aware bursts (limit /login separately from /health).
• SNI — Per-hostname under wildcard certs.
• REGION_CODE — Country-scoped ban (rare).

Two-tier protection pattern

A robust login endpoint uses stacked rules:

1. Priority 1000 — throttle 10 req/min/IP on /login (smooths bursts).
2. Priority 1100 — rate-based-ban 100 req/10-min/IP with 1-hour ban (kills brute-force).
3. Priority 1200 — rate-based-ban 500 req/hour by HTTP_HEADER:X-API-Key (catches credential-stuffing across IPs).

The throttle handles legitimate retry storms (user double-clicks); the ban handles persistent attackers.

Edge Security Policies + Cloud CDN Integration

Cloud Armor exposes two security-policy types:

• CLOUD_ARMOR (backend security policy) — Attached to a backend service. Evaluated after the LB has done URL-map routing and content selection.
• CLOUD_ARMOR_EDGE (edge security policy) — Attached to a backend service OR backend bucket fronted by Cloud CDN. Evaluated at the Google edge before the CDN cache lookup.

Why edge security policies matter for CDN

When Cloud CDN serves a response from the edge cache, the request never reaches the origin — and traditional backend security policies only fire on cache misses. An attacker hammering a cached /popular-asset.jpg would consume edge bandwidth but never trigger your WAF. Edge security policies plug this gap by inspecting the request at the cache layer itself.

Edge policy capabilities

• IP allow/deny (CIDR, IP lists, Address Groups).
• Geo blocking (origin.region_code).
• ASN blocking (origin.asn).
• Request method filtering.
• Not supported at edge: Preconfigured WAF rules, Adaptive Protection, rate limiting (those are backend-policy only — they need full L7 inspection that the edge cache layer skips for perf).

Layered pattern

Client → Edge Security Policy (IP/geo block) → Cloud CDN cache
                                                    ↓ (miss)
                                       Backend Security Policy (WAF, rate limit, Adaptive)
                                                    ↓
                                                Backend Service

A scraper from a banned ASN gets dropped at the edge with zero CDN cost. A legitimate cache miss flows through the full WAF on the way to origin. Configure both with gcloud compute security-policies create my-edge --type=CLOUD_ARMOR_EDGE then --security-policy=my-edge --edge-security-policy=my-edge on the backend bucket/service.

IAP and Cloud Armor: Defense in Depth for Internal Apps

Identity-Aware Proxy (IAP) authenticates users at the LB using Google identities, while Cloud Armor filters traffic before authentication. Combining them yields a two-layer perimeter for internal/employee-facing apps.

Evaluation order

For an external HTTPS LB with both enabled:

1. Request arrives at Google edge.
2. Cloud Armor edge policy (if attached) evaluates IP/geo.
3. Cloud Armor backend policy evaluates WAF, rate limit, Adaptive Protection.
4. IAP intercepts: checks for valid _iap cookie or initiates OAuth2 flow.
5. IAP-authenticated request gets x-goog-iap-jwt-assertion header injected.
6. Backend service receives request with IAP signed JWT.

Why both?

• IAP assumes the user can reach the LB. Without Cloud Armor, an attacker can still launch DDoS, credential stuffing on IAP's OAuth callback, or scan for misconfigured backends.
• Cloud Armor doesn't know the user identity. It cannot enforce "only employees in Engineering group can hit /admin" — that's IAP + Cloud Identity groups.

Pattern for an internal admin console

• Cloud Armor: Geo-restrict to corporate regions, rate-limit /login, deny known bad ASNs.
• IAP: Restrict access to group:[email protected].
• Backend: Validate x-goog-iap-jwt-assertion signature; reject requests without it (defense against IAP bypass via direct backend hits — which is why VPC firewall lock-down from the earlier section is mandatory).

This stack means an external attacker must bypass three independent controls: edge IP filtering, WAF/rate limit, and Google OAuth with group enforcement.

Hybrid NEG + Anycast: Protecting On-Prem and Multi-Cloud Origins

Cloud Armor protection is not limited to GCP-hosted backends. Via Hybrid Connectivity Network Endpoint Groups (Hybrid NEGs), an external HTTPS LB can front:

• On-premises datacenters (reached via Cloud Interconnect / Cloud VPN).
• AWS / Azure workloads (reached via internet endpoints or interconnect).
• Third-party SaaS the customer wants to put behind their WAF.

Architecture flow

Anycast IP (Google Global LB) → Cloud Armor → Hybrid NEG (FQDN or IP:port)
                                                     ↓
                                       Cloud Interconnect / Internet
                                                     ↓
                                          On-prem F5 / AWS ALB / Azure App GW

The Google Frontend (GFE) terminates the public Anycast IP and absorbs L3/L4 floods. Cloud Armor runs Adaptive Protection and WAF rules on the L7 payload. Only the cleaned traffic egresses to the on-prem origin over your Interconnect — meaning your on-prem network never sees the raw DDoS and your private bandwidth isn't saturated.

Anycast advantage

Google's Anycast IP is announced from 180+ PoPs globally. A 1-Tbps volumetric attack is automatically split across PoPs — no single ingress saturates. This is why even tiny on-prem origins (a single 1 Gbps Interconnect) can survive multi-hundred-Gbps attacks: the attack is filtered at the edge, only legitimate traffic crosses the Interconnect.

Caveats

• Hybrid NEG backends require the on-prem firewall to allow Google LB health-check ranges (130.211.0.0/22, 35.191.0.0/16) for the health probes.
• Latency floor = client → nearest GFE PoP + GFE → on-prem origin. The second hop is bounded by your Interconnect topology, so pick PoPs close to your DC.
• Cloud CDN does not cache Hybrid NEG responses by default; enable explicitly per backend service if cacheable.

Managed Protection Plus vs Standard: Tier Comparison

Cloud Armor ships two tiers. Pick wrong and you either overspend on a static site or underprotect a financial API.

Standard (included with HTTPS LB)

• L3/L4 DDoS protection: Volumetric (UDP flood, SYN flood, reflection) absorbed at GFE — always-on, no config.
• Manual security policies: IP/CIDR allow-deny, geo-blocking, custom CEL expressions.
• Preconfigured WAF rules: OWASP CRS 3.3 rule groups (SQLi, XSS, etc.) — manually attached.
• Rate limiting: throttle and rate-based-ban actions.
• Edge security policies: Available.
• Cost: $0 for the platform; $1/policy/month + $0.75/rule/month + $0.75 per million requests evaluated.

Managed Protection Plus (subscription)

• Everything in Standard, plus:
• Adaptive Protection (L7 ML defense) — Bayesian anomaly detection with auto-generated rule suggestions.
• Curated detections: Google SRE-maintained rules for emerging CVEs (Log4Shell-tier) deployed within hours of disclosure.
• Premium ruleset visibility: Detailed signature breakdowns in Security Command Center.
• Threat Intelligence: Named IP lists for Tor exit nodes, known malicious IPs, public clouds, search engines.
• DDoS bill protection: Service credits for autoscaling and egress costs incurred during a confirmed Cloud-Armor-detected attack — caps your "DDoS as a bill" exposure.
• 24/7 DDoS Response Team (DRT) access for active incidents.
• Cost: $3,000/month base + $30/protected resource/month (typically 1-year commitment).

Decision matrix

Exam shortcut

If a PCA scenario mentions any of: "machine learning detection", "DDoS cost during attack", "curated threat intel", "24/7 response team", or "zero-day mitigation" — the answer is Managed Protection Plus. If it only mentions OWASP, SQLi, geo-blocking, or rate limiting, Standard tier is the cheaper correct answer.

FAQ — Cloud Armor WAF and DDoS Protection

Q1. Do I need Cloud Armor if I have a VPC Firewall?

Yes. VPC Firewalls only look at IP addresses and ports (Layer 3/4). They cannot see "inside" the HTTP request to stop things like SQL Injection or XSS. You need Cloud Armor for Layer 7 protection.

Q2. Can Cloud Armor block traffic from specific countries?

Yes. You can use Geo-blocking rules to allow or deny traffic based on the geographic origin of the IP address.

Q3. Does Cloud Armor work with Cloud Storage (GCS)?

Cloud Armor can be used with GCS if the bucket is configured as a backend for an HTTP(S) Load Balancer. This is common for protecting static websites or private assets.

Q4. What is "Adaptive Protection"?

It is an ML-powered feature that detects "zero-day" or sophisticated attacks by learning your application's normal behavior and alerting you to deviations.

Q5. How do I see what Cloud Armor is blocking?

All matches and blocks are logged in Cloud Logging. You can create dashboards in Cloud Monitoring to track attack trends and rule effectiveness.

Final Architect Tip

For the PCA exam, Cloud Armor is your "Edge Defense" solution. If a scenario mentions "OWASP," "Layer 7 attacks," "SQL Injection," or "DDoS at the Load Balancer," Cloud Armor is the answer. Remember that it requires an HTTP(S) Load Balancer (Standard or Global). If the question is about "mitigating costs during a DDoS attack," the answer is Managed Protection Plus.