Google Cloud Armor (GCA) lets you create security policies to defend load-balanced workloads. Specifically, you can use Cloud Armor to protect against DDoS, cross-site scripting (XSS), SQL injection (SQLi), and some other attacks. Further, if it is combined with other services such as Cloud Security Command Center, it can help mitigate the OWASP Top 10 security risks. Also, it comes with “Adaptive Protection,” a machine learning system trained locally on your application that works automatically and integrates seamlessly with your workloads.
We have previously written about topics such as GCP and cloud security. In this article, we’ll take a deeper dive into Cloud Armor and discuss:
- How to set it up, including policies and rules.
- Its shortcomings, and the reasons it doesn’t provide full web security.
- How to use it as part of a comprehensive system that does provide full web security.
Setup of Google Cloud Armor
To use GCA, you’ll need a Google Cloud account with billing already setup, as well as an instance group ready for use.
We’ll start by creating a load balancer. If you already have one, skip to the next section. If not, go to Networking services > Load Balancer > HTTP(S) Load Balancing and click on “start configuration.” In the next screen, choose to load-balance from the internet and use a classic HTTP(S) load balancer.
Now, you should see the following screen:
Here, name your load balancer, and either choose an already existing backend service or create a new one from your instance group. You don’t need to activate any additional options, but you will need to check that every required option is selected. The most important one is the health check, where you’ll need to choose an already existing one or create one.
Creating Your First Policy
After this, you’ll be ready to start creating and adding GCA policies. Head over to the Networking Security tab, and go into Cloud Armor. Once here, click on “Create Policy.”
You’ll see this screen:
Here’s where it can start to get a bit tricky. First, name and give a description to your policy. Then, you need to choose between the two types of policies: edge and backend.
You can apply edge security policies (which are in preview/beta at the time of this writing) to content that is stored in cache, meaning CDN-enabled services and backend buckets. However, they only support filtering based on a subset of parameters, compared to backend policies.
On the other hand, backend policies only work for backend services that don’t work off of cache, but they do provide the ability to redirect (instead of only allow/deny) and utilize other features like bot management, Adaptive Protection, Layer 7 filtering, WAF, and named IP address lists.
You can also combine the two types of policies for even better protection. Combining them is as easy as creating two separate policies and pointing them to the same target. When they’re combined, edge policies will apply first when applicable, followed by backend policies. This way, you can get the speed of edge policies and the robustness of backend policies, all in one package.
The next step is to add your rules.
They can either be basic rules, which only let you specify IP addresses or ranges, or advanced rules, which let you use Google’s custom rules language to specify multiple sub-expressions to match against incoming requests. This can be anything from request headers to country/region codes, also including IP addresses or ranges.
You can add as many rules as you want. Just note that the order in which they’re applied depends on the priority you specify for each rule, 0 being the highest priority and 2,147,483,647 being the lowest. Also, you can choose to enable the “Preview only” option, which will let you see the effects of your policy via stackdriver logs, without actually enforcing the policy.
Now, you’ll need to point the rule to a target, which will be the load balancer you set up earlier. In the case you’re creating an edge security policy, you can also choose a load balancer bucket here.
Finally, and this is optional, you can enable Adaptive Protection.
This is, however, only an option if you’re creating a backend policy, not an edge security policy. Also, Adaptive Protection will only generate alerts and will not provide rules to mitigate what was detected in those alerts if you’re not enrolled in Managed Protection Plus.
You can tune alerts based on the following metrics: confidence level (which indicates how much Adaptive Protection thinks the change in the traffic is anomalous), attack signature, suggested rule, and an estimated impacted baseline rate associated with the suggested rule.
After that, you can click on “Create policy,” and you’re done!
Here are some examples of some very basic rules:
- Allow/deny requests with a certain cookie (in this case, 80=FOO)
- has(request.headers[‘cookie’]) && request.headers[‘cookie’].contains(’80=FOO’)
- Allow/deny traffic from a specific region (the following example would block all access from the AU region when used in a deny rule)
- origin.region_code == “AU”
You can mix and match these statements to form more complex cases in which to allow or deny incoming traffic.
Shortcomings of Google Cloud Armor
So far, all of this seems straightforward. What then are the downsides of Cloud Armor? Let’s discuss a few.
One of the most severe disadvantages of GCA is that it must be manually setup and configured; the same is true for the creation and implementation of rules. While Cloud Armor offers some preconfigured rules (more on these below), and also offers Adaptive Protection to create some WAF rules based upon your regular traffic, they should be treated as complements to your other policies. In general, to create a robust security posture in Cloud Armor, a significant amount of expertise and a substantial commitment of time are required.
There is also a substantial burden associated with maintenance. Any change to infrastructure or service coverage could require modification of policies and their associated rules. Many organizations find that maintenance alone is sufficient reason to seek an alternative solution, and free up their engineers for tasks that can add business value.
More Services, More Setup
Cloud Armor includes dozens of pre-configured rules containing threat signatures. These are useful, but insufficient in today’s threat environment. (Some competing WAFs include hundreds of threat signatures out of the box.)
Additionally, while there are some additional services that Google Cloud Armor offers, like bot management and rate limiting, they also require additional setup.
For example, if you want to use reCAPTCHA Enterprise for bot management, you could include a rule like the following:
- request.path.matches(\”/login.html\”) => redirect, type=GOOGLE_RECAPTCHA
This way, every user gets redirected to the CAPTCHA page, and, if they pass the assessment, are granted an exemption cookie to avoid the CAPTCHA next time they navigate to the matched URL, until the cookie expires. This cookie is automatically attached and handled by the browser.
If you choose rate limiting, you’ll have to take into account several factors. First, you’ll need to identify clients for rate limiting (you can choose to rate limit all requests, or those from a certain IP or containing a certain header). Then, you’ll use the throttle action in a rule, with the rate_limit threshold, exceed_action and conform_action parameters, to further describe how the rate limit will work when trying to access the target of your policy.
There is a caveat though: Rate limit policies can only be created through the GCloud tool. You can read more about this here.
Cloud Armor is not a full-featured web security solution, and some of its capabilities are not the best available. For example, the section above describes the setup of reCAPTCHA, but this feature is not recommended for many organizations. It harms the user experience by interrupting sessions, and it isn’t very effective for filtering bots from motivated attackers anyway. (There are multiple darkweb services for auto-solving reCAPTCHAs.)
Multi-cloud architectures offer a number of advantages, and have become increasingly popular. However, just like all of the native cloud security tools, Cloud Armor was specifically designed for one cloud platform alone.
How to obtain a robust web security posture from Cloud Armor
Reblaze provides complete web security for Google Cloud Platform. It integrates tightly with Cloud Armor, providing end users with an autonomous system which reacts immediately to every type of attack; Reblaze identifies hostile traffic, and Cloud Armor blocks it at the edges.
Reblaze is fully integrated with, and runs natively on, Google Cloud Platform. Google has highlighted Reblaze as a technological innovator at several Google Cloud Next events, including a live demo that was given during a keynote session by the Senior Product Manager of Google Cloud. (Reblaze was demonstrated as the threat-detection engine for Google Cloud Armor, and defeated a live DDoS attack during the presentation.)
Reblaze is a unified, all-in-one web security platform; it includes a next-gen WAF, multi-layer DoS/DDoS protection, advanced bot management, precise ACL, API security, real time reporting, full traffic transparency, ATO prevention, and more, all fully integrated with GCP. The platform is fully managed, always up-to-date, and includes continual machine learning for accurate, adaptive threat recognition. Reblaze deploys in minutes, and runs on your choice of GCP and/or other clouds. For more information or to get a demo, contact us here.