IAM protects whatever has an identity. But the visitor crawling AlpinaShop's catalogue at a thousand requests per second to copy the prices has no identity. Nor does the one trying ten thousand passwords against the sign-in form, nor the one typing ' OR 1=1-- into the search box to see what happens. That traffic arrives at alpinashop-lb-ip like any legitimate customer and, with nothing in front, ends up on the MIG instances.

Cloud Armor is Google Cloud's application firewall (WAF) and denial-of-service protection system. Like Cloud CDN, it is not a product deployed separately: it is a policy attached to the backend service of the load balancer you built in 03-02, and it is applied at the edge of Google's network, at the same points of presence where the load balancing and the caching happen. Malicious traffic is dropped thousands of kilometres from europe-west1, without consuming a single cycle of your instances.

This lesson has a concrete case: AlpinaShop's autumn campaign. Marta spots two simultaneous problems. A competitor is crawling the entire catalogue every night, which triggers the MIG's autoscaling and sinks the CDN hit ratio. And the sign-in form is receiving brute-force attempts from several hundred addresses. We are going to build the pol-catalogo-web policy that solves both, and above all we are going to roll it out the right way, which consists of blocking nothing until we are sure.

Important warning. A WAF is no substitute for secure code, and a badly calibrated security policy blocks legitimate customers, which is a commercial incident just as real as the one you were trying to avoid. Everything that follows is a valid teaching model, but before applying blocking rules in a real production environment, the design must be reviewed by a security professional, and any geography-based filtering decision must also be validated by the legal and commercial lead.

1. What a WAF is, what it covers and what it does not
2. Where Cloud Armor acts: a request's journey
3. Policies, rules, priorities and the default rule
4. Rules by IP address
5. Rules by geography and their implications
6. Preconfigured OWASP Top 10 rules
7. False positives: a WAF's real problem
8. The expression language: bespoke rules for AlpinaShop
9. Preview mode: the only correct way to deploy
10. Rate limiting and rate-based-ban
11. Adaptive protection against layer 7 DDoS
12. reCAPTCHA Enterprise for telling people from bots
13. The Standard and Enterprise tiers, and cost
14. The complete autumn campaign policy

A web application firewall inspects the content of HTTP requests — path, headers, parameters, body — and decides whether to let them through. It is different from the VPC firewall you configured in 03-01: that one works with IP addresses and ports and has no idea what is travelling inside; this one understands HTTP.

What Cloud Armor covers well:

• Injection attacks in the parameters: SQLi, XSS, local and remote file inclusion, remote command execution.
• Volumetric denial of service (layers 3 and 4), automatically and with no configuration, simply by virtue of sitting behind the global load balancer.
• Application denial of service (layer 7): mass crawling, brute force, abuse of expensive endpoints.
• Filtering by origin: addresses, ranges, countries, IP reputation.
• Basic bots and automated scanners.

What it does not cover, which is just as important to know:

• Business logic flaws. If your endpoint lets someone request another customer's order by changing an identifier in the URL, every request is perfectly legitimate in the WAF's eyes. That flaw is fixed in the code.
• Stolen credentials. A sign-in with the correct password is a correct sign-in.
• Vulnerabilities in your dependencies. It can mitigate the exploitation of some known ones, and it buys you time while you patch, but it patches nothing.
• Permission misconfigurations. That is IAM.
• Attacks from inside or that do not pass through the load balancer. If a VM has a public IP and can be reached directly, the WAF never knows.

A WAF is a mitigation layer, not an absolution. It is what gives you room to fix things, not what fixes them.

The four facts that matter in this diagram:

1. Cloud Armor is evaluated at the edge, at the same point of presence the client enters through. The malicious packet never travels to europe-west1.
2. It is evaluated before the cache. A blocked request neither consults the cache nor consumes fill; and conversely, enabling the CDN does not create a path by which traffic can bypass the WAF.
3. It is evaluated before IAP. The bot attacking the reporting dashboard is dropped before it even reaches the sign-in screen.
4. The blocking response is generated by the edge. Your instances never see the request, do not record it in their logs and burn no CPU.

Policies are attached to a backend service:

For backend buckets like bb-catalogo-imagenes there is a variant called an edge security policy (--edge-security-policy), which supports fewer rule types — filtering by IP, geography and some basic expressions — but is also applied to content served from cache. It is the way of protecting the images without giving up the CDN.

A security policy is an ordered container of rules. Each rule has:

• A priority (an integer). They are evaluated from lowest to highest and the first one that matches wins; the rest are not even looked at.
• A condition: either a list of IP ranges, or an expression.
• An action: allow, deny-403, deny-404, deny-502, throttle, rate-based-ban, redirect.

When you create it, Google automatically adds the default rule, with priority 2147483647 (the largest signed 32-bit integer) and the allow action. It is the one that catches everything that matched nothing earlier.

That rule raises the lesson's most important design decision:

For AlpinaShop's public catalogue the model is necessarily a blocklist: anyone in the world must be able to view a backpack. For an internal API or an admin dashboard, an allowlist is viable and is the right thing.

Always leave a gap in the priorities. Number in hundreds (1000, 1100, 1200…) so you can insert rules in between without renumbering everything:

The simplest rule and the one that must always go first: AlpinaShop's office and the load testing provider must never be blocked by anything, not even by a badly calibrated OWASP rule.

Practical details:

• Up to several thousand ranges per policy are supported, but maintaining huge lists by hand is unsustainable. That is what the Enterprise tier's threat intelligence is for (section 13).
• Blocking by IP has a shelf life. Home addresses are dynamic: today's attacker address is tomorrow's customer. Document the review date in the description, as in the example, and review those lists.
• Behind a proxy or another CDN, origin.ip is the proxy's. If that is your case, the correct expression uses the IP from the trusted X-Forwarded-For; configure it carefully, because that header can be forged by the client if it is not validated properly.

Cloud Armor knows the country each request comes from and exposes it as origin.region_code, with two-letter ISO codes.

And a far more reasonable variant: instead of blocking the whole catalogue, restrict only the admin dashboard, which does have a perfectly well-defined legitimate origin.

Note deny-404 instead of deny-403: we do not confirm to the attacker that an admin dashboard exists. It is a small difference that reduces the information you give away.

The three warnings about geographic blocking, and none of them is technical:

1. It is trivial to bypass. A three-euro-a-month VPN nullifies it. It stops automated noise, not a determined attacker.
2. It blocks real customers. A Spanish customer on holiday, an expatriate, somebody behind a corporate VPN. In a shop, every block is a lost sale and a call to customer service.
3. It can have legal and commercial implications. Blocking countries is a business decision, and in some contexts a regulatory compliance one. The technical team must not take it alone.

The recommended stance: use geography to restrict sensitive paths (/admin, /api/interna) and to score risk in combination with other signals, not to close the shop to a continent.

Here is the main value of a managed WAF. Google maintains rule sets based on the ModSecurity Core Rule Set, updated by its security team, invoked with the evaluatePreconfiguredWaf() function.

Creating the rules, with sensitivity and always in preview the first time:

Sensitivity runs from 1 to 4 and works as a cumulative threshold:

A warning that saves a lot of time: if your application is Python with Flask and PostgreSQL, do not enable php-v33-stable, nodejs-v33-stable or java-v33-stable. They add no protection and every active rule costs money and adds false positive probability.

This is the part the brochures do not tell you. The OWASP rules work by looking for patterns, and many legitimate patterns look like an attack. Real cases that occur in a shop like AlpinaShop:

There are three ways of solving it, in order of preference:

1. Disable specific rules from the set, instead of lowering the global sensitivity:

The rule identifiers come from the log: every block records exactly which rule in the set fired. This is surgery, as opposed to the axe of lowering the sensitivity.

2. Exclude specific paths from the analysis, when you know an endpoint receives free text by design:

With one very serious condition: if you exclude a path from the WAF, that path has to be impeccably validated in the code. You are giving up the safety net exactly where arbitrary text comes in.

3. Lower the sensitivity. It is the fastest and the least precise. Valid as a temporary measure during an incident.

And the advice that covers all three: the correct procedure is not to react to false positives in production, but to discover them beforehand with preview mode.

Cloud Armor uses CEL (Common Expression Language), the same language as the IAM conditions you saw in 03-04. The available attributes:

Case 1: the bot hammering the catalogue. The competitor crawls with a client that identifies itself and does not run JavaScript. It is recognised by the combination of user agent and absence of real browser headers:

The !has(request.headers['accept-language']) condition is the most useful of the four: practically every real browser sends that header and practically no simple script bothers to set it. And it is precisely the one that should spend the longest in preview, because some legitimate clients omit it too.

Case 2: protecting an expensive endpoint. The CSV catalogue export takes seconds and hits the database. It should only be used from the office:

Case 3: rejecting methods the application does not use. The catalogue only serves GET, HEAD and POST:

Case 4: preventing access by direct IP. Every legitimate request arrives with the correct Host; those arriving with the IP in the Host are indiscriminate scanning:

Every rule accepts --preview. In that mode, the rule is evaluated and logged, but not enforced. The request carries on as normal.

This is not a convenience: it is the procedure. An OWASP rule with a badly chosen sensitivity can block your shop's search box on the biggest sales day of the year, and the worst part is that you will not find out through an alert, but through a drop in conversion that nobody connects with the WAF.

The deployment procedure, step by step:

The previewSecurityPolicy.preconfiguredExprIds field is the one that gives the specific rule identifiers from the OWASP set, which are what you need for the opt_out_rule_ids in section 7.

An aggregate count, so you can decide with numbers instead of impressions:

That count reads like this: rule 1000 as it stands would block 847 legitimate searches in a week. It is not enabled: it is debugged with opt_out_rule_ids or the search path is excluded, and it goes back into preview for another week.

The distinction between the two log fields is the key to this whole section:

And an operational golden rule: never enable new rules the day before a campaign. AlpinaShop's autumn campaign starts on 15 September; the rules go into preview on 1 August and are enabled by 1 September at the latest.

Marta's second problem is brute force against /acceso. Here there is no malicious pattern to detect: each individual request is legitimate. What is anomalous is the frequency.

Cloud Armor offers two actions:

• throttle: above the threshold, the excess requests are rejected, but as soon as the rate drops, service resumes. It is a continuous limiter.
• rate-based-ban: above the threshold, that client is banned for a fixed period, even if it stops trying. It is the punishment.

The grouping key (--enforce-on-key) decides who the counting is done for, and choosing it badly invalidates the protection:

Two calibration tips worth more than any rule:

• Measure before choosing a number. The 99th percentile of requests per minute per IP for your real traffic is in the load balancer log. Set the threshold at two or three times that value, not at a round number picked by eye.
• deny-429 and not deny-403. The 429 code (Too Many Requests) is the semantically correct one, legitimate clients know to retry with a wait, and search engines read it as "come back later" instead of "this is forbidden", which protects your ranking.

The previous rules depend on somebody having foreseen the attack. Adaptive protection does not: it trains models on your application's normal traffic and detects anomalous deviations, proposing concrete rules.

How it works in practice:

1. It needs between several days and a week of traffic to establish a baseline. Enable it long before you need it.
2. When it detects an anomaly, it generates an alert with the attack's signature: user agents involved, source ranges, paths attacked, and a confidence score.
3. It suggests a Cloud Armor rule ready to apply, with an estimated impact on legitimate traffic.
4. The decision to apply it is still yours. It can be applied automatically, but in a shop human review is preferable.

It is worth being clear about what it protects and what it does not: volumetric layer 3 and 4 attacks (SYN floods, UDP amplification) are absorbed automatically by Google's infrastructure simply by virtue of sitting behind the global load balancer, with nothing to configure. Adaptive protection is for layer 7 attacks, the ones consisting of perfectly formed HTTP requests in anomalous quantity and pattern, which are far harder to tell apart from real traffic.

When the bot is sophisticated — it runs JavaScript, rotates IP addresses, sends real browser headers — no static rule tells it apart. The answer is reCAPTCHA Enterprise, natively integrated with Cloud Armor.

The flow is interesting because it is not the classic "select the traffic lights" CAPTCHA:

1. The application includes the reCAPTCHA script, which assesses the user's behaviour in the background and issues a token with a score from 0.0 (almost certainly a bot) to 1.0 (almost certainly a person).
2. Cloud Armor reads that token at the edge and acts according to the score.
3. Only if the score is doubtful is a visible challenge shown. Most users never see anything.

The design decision here is redirect and not deny: when in doubt, in a shop you never block, you ask. A false positive with deny is a lost sale; with redirect, a second of friction. That criterion — block the obvious, challenge the doubtful — is what separates a usable security policy from one that loses money.

Threat intelligence deserves a mention because it solves section 4's problem: instead of maintaining IP lists by hand, Google maintains categorised, up-to-date lists:

Other available lists include Tor exit nodes, anonymous proxies, search scanners and the ranges of the major cloud providers (useful: hardly any legitimate shop customer browses from a data centre).

Indicative Standard cost, as an order of magnitude:

With this lesson's policy (about fifteen rules) and around 10 million requests a month, that comes to something like $25-30/month. Compared with what an incident costs, or simply with what the extra instances the autoscaler spins up during a mass crawl cost, it is one of the platform's best-value investments. Always check the current rates in the official documentation, because they change and vary by region.

Enterprise's bill protection against DDoS deserves a thought: in a large volumetric attack, the cost is not in the damage, it is in the egress and compute bill generated by absorbing it. That insurance is the main reason a company with real exposure buys Enterprise.

This is the final result for AlpinaShop, ordered by priority. Read it as a design document:

And the check that it works, which must always be done from outside the office, because rule 100 exempts you from everything:

• Enabling rules without preview. It is this lesson's serious mistake. A badly calibrated SQLi rule blocks the search box and nobody connects the drop in sales with the WAF.
• Starting at sensitivity 3 or 4. Sensitivity 1, and you only go up if the log analysis justifies it.
• Not numbering with gaps. Consecutive priorities force you to renumber to insert a rule.
• Forgetting the office exemption rule at the lowest priority. If you block yourself during an incident, debugging becomes hell.
• Testing from the office. Rule 100 always lets you through; it will look as though nothing works. Test from an external network.
• Blocking countries without consulting anyone. It is a commercial and sometimes legal decision, not a technical one.
• Confusing throttle with rate-based-ban. The first limits while the excess lasts; the second bans for a fixed period. For brute force, ban.
• Rate thresholds chosen by eye. Measure the real 99th percentile in the load balancer log and multiply by two or three.
• enforce-on-key=IP without thinking about shared IPs. A school or a company goes out through a single address; a low threshold blocks thirty legitimate people.
• Returning deny-403 from rate limiters. The correct code is 429.
• Enabling rule sets for technologies you do not use. php-v33-stable on a Python application: it costs money and adds false positives while contributing nothing.
• Believing the WAF replaces validation in the code. Parameterised queries, output escaping and input validation are still mandatory. The WAF is the second line.
• Not enabling VERBOSE logging during preview. Without the specific rule identifiers you cannot use opt_out_rule_ids and all you are left with is the axe of lowering the sensitivity.
• Tip: manage the policy as code (06-07) and export its state before every change: gcloud compute security-policies describe pol-catalogo-web --format=yaml > politica-$(date +%F).yaml.
• Tip: set an alert on the number of denied requests. A spike in blocks may be an attack, but it may also be a deployment of your own application that has started sending something the WAF does not recognise.

After seven days with all the rules in preview, the count by priority is:

A sample of rule 1000's requests shows that 90 % are of the form /buscar?q=camiseta+t%C3%A9cnica+O%27Neill and /buscar?q=%22gore-tex%22. Those from 1100 are mostly POST /api/resenas with text containing <3 and >>.

Decide, rule by rule, what to enable, what to debug and what to leave in preview, and write the commands.

AlpinaShop launches a public API for partner shops: POST /api/socios/pedidos, authenticated with an X-Alpina-Api-Key header. Requirements:

• A maximum of 100 requests per minute per API key (not per IP: several shops share an operator).
• Requests with no header are rejected at the edge, without reaching the application.
• Only POST is accepted.
• The partner shops are in Spain, Portugal and France.
• A partner who exceeds the limit three times in a row must be banned for 15 minutes.

Write the rules with their priorities and justify the order.

It is 22:00 on a Friday. The shop is extremely slow, the MIG is at 10 instances (its maximum) and Marta sees in the load balancer log that 80 % of the traffic is GET /buscar?q=<random> requests from around 4,000 different IP addresses spread across the world, with plausible browser user agents and no Referer header.

Describe the immediate response, the next 24 hours' response and the structural one. Why is a rule by IP no use here?

Solution 1

Rule 1000 (SQLi) — debug, stay in preview. The 1204 blocks are nearly all false positives: apostrophes in surnames and quotes in brand searches. Enabling it would leave customers with no search box. Two combined corrections:

The path exemption requires first verifying with Dani that the search box really does use parameterised queries. If it did not, the priority would be fixing the code, not relaxing the WAF.

Rule 1100 (XSS) — debug, stay in preview. The problem is localised in /api/resenas, an endpoint that receives free text by design. The exemption from section 7 (priority 950) is created and it is checked that reviews are escaped when rendering. With that exemption in place, another week of preview.

Rule 2000 (crawling) — preview, manual analysis. 156 in a week is little traffic: you have to look at where they come from. If they are a few sustained addresses, it is the competitor and it can be enabled. If they are scattered, there are probably legitimate clients among them (price aggregators contracted by AlpinaShop itself, for instance) and the expression needs refining first.

Rules 1400 (scanners), 1200 (LFI) and 900 (CVE) — enable now.

Low volumes and patterns with no legitimate explanation whatsoever: they are real attacks. They are enabled with no further discussion.

Solution 2

Justification of the order. Rules are evaluated from lowest to highest priority and the first match wins, so they go from the cheapest and most categorical to the most costly:

1. Wrong method (4900) and missing header (4910) are trivial checks that discard junk traffic without evaluating anything else. The sooner the better.
2. Geography (4920) in preview, because a French partner using a proxy in Belgium would be left out and that has to be confirmed with the commercial team before enabling it.
3. Rate limiting (4930) last: it is the most expensive rule to evaluate and it only makes sense to apply it to requests that have already passed the previous filters.

The key point is --enforce-on-key=HTTP_HEADER with --enforce-on-key-name. Counting by IP would fail in both directions: it would unfairly penalise several shops sharing an operator and it would not stop an abusive partner rotating addresses. With the corresponding warning: the header is controlled by the client, so the real validation of the key is still done in the application; Cloud Armor only uses it to group the count.

Solution 3

Why a rule by IP is no use. There are 4,000 distributed addresses, probably a botnet or a residential proxy service. Blocking addresses one by one is chasing a target that moves faster than you can type.

Immediate response (minutes). What they have in common is not the origin, it is the behaviour: /buscar paths with random terms and no Referer.

The redirect to reCAPTCHA is the best tool during a bot incident in a shop: people carry on buying, bots fall over.

The next 24 hours.

• Enable adaptive protection if it was not already on (although it will take a while to have a baseline, and that is the lesson: it is enabled beforehand, not during).
• Analyse the log grouping by ranges, user agent and autonomous system, looking for a more precise signature that allows the emergency rule to be refined and its impact on real customers reduced.
• Review the collateral impact: how many legitimate searches were dropped with 429 while rule 3050 was in force.
• Temporarily raise the MIG autoscaler's maximum if there is still pressure.

Structural.

• Cache frequent searches in the CDN (03-03): a search served from the edge never touches the database.
• Look into why the search box is so expensive. A rate limit that saves the shop is a patch over an endpoint that should cope with more; perhaps an index is missing or the search should move to a dedicated service.
• Leave the emergency rules documented and with a review date, not permanent with a crisis threshold.
• Evaluate Cloud Armor Enterprise: in an attack like this, threat intelligence would have recognised a good proportion of those origins and bill protection would have covered the extra cost.

AlpinaShop no longer takes everything that comes its way. You know what a WAF is and, above all, what it does not solve: it does not fix business logic flaws, it does not detect stolen credentials and it does not patch vulnerable dependencies. It is a mitigation layer that buys time, not an absolution, and that is why parameterised queries and input validation are still mandatory in Dani's code.

You understand where Cloud Armor acts: at the edge, at the same point of presence the client enters through, before the cache and before IAP, attached as a policy to the bs-catalogo-web backend service and as an edge policy to the bb-catalogo-imagenes backend bucket. You have mastered the model of policies, rules and priorities, with the default allow rule at the far end, the office exemption at priority 100 and the habit of numbering in hundreds so you can insert.

You have built the complete pol-catalogo-web: rules by IP and by geography — with the warning that blocking countries is a commercial and legal decision, not a technical one — the preconfigured OWASP sets at sensitivity 1 and their real problem, which is the false positives from the search box and the reviews, and the three ways of dealing with them in order of precision: opt_out_rule_ids, path exemption and lowering the sensitivity. You have written your own CEL rules for the competitor's crawler, the expensive export endpoint, useless HTTP methods and requests with an invalid Host. And you have learned the procedure that makes all of this safe: --preview first, VERBOSE logging, a week of real traffic, a count by priority, debugging, phased activation and never on the eve of a campaign, reading the difference between previewSecurityPolicy and enforcedSecurityPolicy in the log.

You have protected the sign-in form with rate-based-ban and the search box with throttle, choosing the grouping key with judgement and returning 429 instead of 403. You know about layer 7 adaptive protection and why it has to be enabled before you need it, the use of reCAPTCHA Enterprise with redirect instead of deny — when in doubt, in a shop you ask, you do not block — and the difference between Standard and Enterprise, with threat intelligence and bill protection as the weighty arguments.

There remains, however, an uncomfortable matter. The password of the app_catalogo user of alpinashop-pedidos is still travelling in an environment variable of the MIG template's startup-script: in clear text, visible to anyone who can read an instance's metadata, impossible to rotate without redeploying and present in every copy of the template. We have protected the edge meticulously while the key to the database is under the doormat. In the next lesson, 03-06, Secrets and Encryption: Secret Manager and Cloud KMS, we take that password out of there and move it to a store with versions, per-secret permissions and rotation; and along the way we understand how Google Cloud encrypts your data at rest, what customer-managed encryption keys (CMEK) are and when it is worth taking on the responsibility of managing them yourself.