Are you currently experiencing an attack?

Are you currently experiencing an attack?

Google Cloud Armor: A Deep Dive, Part 2

As the main web security tool for GCP, Cloud Armor needs to provide a lot of functionality. In Google Cloud Armor: A Deep Dive, Part 1, we described the basic features of Google’s cloud web application firewall (WAF). We discussed its defenses against standard web attacks (such as SQL injection, cross-site scripting, etc.), along with its implementation of rate limiting and adaptive protection. We also discussed its limitations in production environments: non-granular configuration, difficulties in setup and maintenance, inflexibility for complex architectures, lack of reporting and monitoring, and others.

When considering web security for Google Cloud Platform, several other issues must also be considered. Here in Part 2, we’ll continue our exploration of Cloud Armor by discussing its API Protection, Bot Management, and Threat Intelligence capabilities.

As with Part 1, we’ll begin by noting that the observations below were valid at the time of this writing, but they are subject to change, because Cloud Armor is constantly being modified by the GCP team. 

API Protection

Organizations that need robust API protection (in other words, every organization that has an Internet-facing API) won’t get it from Cloud Armor. Unlike many web security solutions, Cloud Armor doesn’t include API security. 

Instead, Google offers separate services for this purpose: API Gateway and Apigee, each of which has a separate pricing model. This obviously increases an organization’s security expenses above that of Cloud Armor alone. It also increases the demands on users, since admins must configure and maintain two (or possibly three, depending on architecture) security services, each of which has different capabilities and somewhat different approaches.

Bot Management

In Part 1, we discussed Cloud Armor’s rate limiting and IP blacklisting capabilities. Although these have some applicability to blocking malicious bot traffic, in production environments organizations need much more.

Modern botnets bypass these basic protection methods by attacking from multiple IP addresses located all over the world, frequently changing user agents, and so on. To adequately protect applications, more effective protection is required.

Cloud Armor itself does not provide full hostile bot management. But it does integrate relatively easily with Google’s reCAPTCHA Enterprise solution, which is meant to protect GCP users from malicious bots. 

reCAPTCHA: Harming the User Experience

reCAPTCHA has a long history of being one of the most hated protection mechanisms. Its puzzles, which force users to select images (of fire hydrants, buses, crosswalks, etc.), can be a UX nightmare. While this form of reCAPTCHA is still supported, Google recently introduced more user-friendly versions (reCAPTCHA v3 and reCAPTCHA Enterprise) that rely on the analysis of user behavior and, most of the time, do not require users to solve any puzzles. 

However, there are some drawbacks. First, they can create False Positives, because some users with non-standard behavior will be classified as bots. And when this happens, they will need to solve puzzles again, which even Google admits creates user friction.

Google’s service also raises significant privacy concerns. (We’ve written about this before: for example in Hostile Bot Detection Part 1: Replacing reCAPTCHA.) Because of these issues, some user demographics try to shun sites that use reCAPTCHA, and in some countries, privacy regulators frown upon it as well. Before adopting reCAPTCHA, these issues should be considered.

From an implementation perspective, reCAPTCHA will require changes to your frontend, mobile apps (an SDK is available), and possibly backend as well; the latter depends on the way you integrate the solution, as reCAPTCHA assessments might be conducted on Cloud Armor instead of the backend. In general, reCAPTCHA Enterprise requires some engineering effort from multiple teams.

How effective is reCAPTCHA Enterprise? For many use cases, it’s not as effective as you might expect. On the darkweb, there are a variety of paid reCAPTCHA-solving services available to threat actors. While Google offers some flexibility on configuring the human/bot recognition threshold (which in theory might mitigate this problem somewhat), this creates a dilemma for admins: to accept a high rate of False Positives and exclude many legitimate users, or to allow a large number of hostile bots to access their sites, applications, and APIs. Neither option is palatable.

How Much Does It Cost?

Adopting reCAPTCHA Enterprise means paying for yet another service. The cost depends on the number of reCAPTCHA assessments performed on behalf of your users. The first million assessments per month are free; after that, it’s $1 for every 1,000 assessments.

This might not seem very costly, but charges can add up quickly. For example, an ecommerce site needs to protect its authentication, account creation, and reviews at a minimum. On top of these, checkout pages, password resets, and newsletter signups should also be taken into account. If scraping or inventory denial bots appear frequently, then product pages need protection too.

For large sites, the one million free assessments might be exceeded in the first few days of the month. Moreover, if a sophisticated botnet attacks, it can send thousands of requests in a short time, while attempting to solve and bypass its reCAPTCHAs. Even if Google’s service detects that these requests are coming from bots, the assessments will still accumulate quickly.

To summarize, relying on a combination of Cloud Armor and reCAPTCHA Enterprise might block many of the bot attacks on your platform. However, when being targeted by sophisticated or determined hackers, the cost, effort, and trade-offs involved can be more problematic than initially expected.

Threat Intelligence

Threat Intelligence is an interesting feature within Cloud Armor’s Managed Protection Plus (an extra paid subscription plan that provides additional security features).

Currently, Threat Intelligence has three main groups of rules to help prevent malicious attacks on a protected resource:

  • Tor exit node IPs: A constantly updated list of IP addresses of Tor exit nodes, which are often a source of cyberattacks.
  • Known malicious IPs: A list of malicious IP addresses maintained by Google. It’s unclear how often this is updated. 
  • Public cloud IPs: IPs of Azure, AWS, and GCP cloud services that legitimate users are unlikely to use to access your applications. 

Is It Worth the Price?

These IP denylists are certainly useful when protecting applications and APIs. And although these lists are publicly available, it’s not feasible to implement them directly yourself in Cloud Armor. (As we covered in Part 1, Cloud Armor policies have some limitations for blocking multiple IP addresses from different autonomous system numbers or networks.) So, other than building a custom solution, a Cloud Armor user will probably need Threat Intelligence, which requires paying for Managed Protection Plus.

However, there are other sources of valuable threat data (e.g., Spamhaus) that Cloud Armor doesn’t include, and that are very difficult for admins to add themselves. While less advanced security teams may benefit from Threat Intelligence’s features, more sophisticated teams will quickly spot its limitations.


In Part 1, we saw that Cloud Armor has some benefits, but also some significant limitations. Now in Part 2, we see the same applies to its API protection, bot management, and threat intelligence features. 

On the positive side, Cloud Armor integrates nicely with GCP-based environments, can be quickly enabled, and relies on technologies familiar to most security teams (OWASP Core Rule Set and reCAPTCHA). 

On the negative side, relying solely on its capabilities within Google Cloud Platform will increase the cost and complexity for users, while not providing sufficient power for many organizations.

Obtaining Robust Security for GCP and Other Workloads

Reblaze is a cloud native security solution that’s fully integrated with (and runs natively on) Google Cloud Platform. It also supports the other top-tier IaaS providers (AWS and Azure), along with on-prem, hybrid, and container-based architectures.

Reblaze addresses the full spectrum of web threats. A next-gen WAF blocks web application attacks. Multi-layer DDoS protection keeps applications and APIs available and performant. Biometric bot management distinguishes bots from humans and excludes automated traffic. Full traffic transparency provides traffic visibility and control in real time. 

As a comprehensive solution, it includes a complete suite of web security technologies: advanced rate limiting, ATO (account takeover) prevention, session flow control, API security, Machine Learning, UEBA (User and Entity Behavioral Analysis), threat intelligence feeds (both admin-configurable and built-in), and more.

Reblaze is a fully managed security platform, maintained by a team of professionals, and updated automatically as new threats arise. Because it’s an all-in-one solution, everything described above is included, with no additional subscriptions or premium service tiers required.

For more information, or to get a demo, contact us here.

Ziv Grinberg is VP of Product at Reblaze

Get your price quote

Fill out your email below, and we will send you a price quote tailored to your needs

This website uses cookies to ensure you get the best experience on our website.