Google Cloud Armor best practices

This page provides best practices for optimizing and tuning Google Cloud Armor deployments.

Google Cloud Armor is deployed with either the global external Application Load Balancer, the classic Application Load Balancer, or the external proxy Network Load Balancer. When you deploy Google Cloud Armor, you attach a security policy to the load balancer backend service that you want to protect. A security policy consists of a collection of pre-configured and custom rules that you determine.

Security policy and rule creation

The following sections contain best practices and recommendations for new security policies and rules.

Provide rule descriptions

Use rule descriptions to provide additional context about why each rule was created and the intended function of the rule. The description field is limited to 64 characters, so references to configuration management databases or other repositories are the most efficient way to capture context.

Consider priority spacing

When you initially configure rules, leave an interval of at least 10 between each rule priority value. For example, the first two rules in a security policy could have priorities 20 and 30. This lets you insert more rules when you need them. In addition, we recommend that you group similar rules into blocks, leaving larger intervals between groups.

Use preview mode

Security policy rules, including Open Web Application Security Project (OWASP) signatures, can have unpredictable effects on your application. Use preview mode, to evaluate whether the introduction of a rule will have a negative impact on production traffic.

Enable Google Cloud Armor Adaptive Protection

Enable Adaptive Protection for additional protection of your applications. Adaptive Protection monitors traffic and (as necessary) recommends new rules for your security policies. In addition, we recommend that you put an alerting policy in place to ensure that the right people are alerted about potential attacks. Adaptive Protection is best suited for volumetric protection. Attacks that are not volumetric might not trigger Adaptive Protection.

Enable JSON parsing

If your application sends JSON content in the body of POST requests, ensure that you enable JSON parsing. If you do not enable JSON parsing, Google Cloud Armor does not parse the JSON content of POST bodies for preconfigured WAF rules, and the results can be noisy and generate false positives. For additional information, see JSON parsing.

Test your logic

A rule is triggered when its match condition evaluates to true; for example, the match condition origin.region_code == 'AU' evaluates to true if the region code of the request is AU. If a higher priority rule evaluates to true, then the action in a lower priority rule is ignored. In the following example, imagine that you want to create a security policy to block users from the AU region, except for traffic within the IP address range 10.10.10.0/24. Consider the following security policy with two rules:

Rule1
expr: inIPRange(origin.ip, '10.10.10.0/24')
action: allow
priority: 1
Rule2
expr: origin.region_code == 'AU'
action: deny(403)
priority: 2

In this example, Rule1 allows traffic that originates from the IP address range 10.10.10.0/24. Because Rule1 is the higher-priority rule, such traffic is allowed before it is evaluated against Rule2, meaning that Google Cloud Armor does not evaluate it against Rule2 (or any other remaining rules).

When you create Google Cloud Armor policies, test the logic of your rules to ensure that you achieve the intended behavior. To do so, we recommend that you generate synthetic traffic to understand which rules are blocking traffic, and verify that your results are consistent with your rule design decisions. If you're unsure of how a request might flow through the system, use preview mode to see which rule matches the request.

Identify the source IP addresses of your scanners

Your security scanners can be located inside or outside of Google. If you want an outside and unfiltered assessment of your application, you can explicitly allow traffic based on IP address (or other token) prior to evaluating it against any other rules.

Group and sort rules in your security policy

Your applications might serve different subsets of your customers. In the following example, you want to deny traffic from certain geographical areas or IP ranges, and therefore you configure the first rule in your policy to deny such traffic. Additionally, you want to explicitly allow some traffic into the application without the security policy processing it. For this example, we recommend the following structure of rule priority, from greatest-priority to least-priority:

  1. Explicit deny rules (ASN, region, IP ranges)
  2. Trusted explicit allow rules (scanners, trusted systems - use with extreme caution)
  3. Security rules (OWASP, custom rules)
  4. Explicit allow rules (ASN, presence of header value, IP range)
  5. Default deny rules

Use reCAPTCHA for bot management

Google Cloud Armor integrates with Google's reCAPTCHA for bot detection at the WAF layer. In this integration, reCAPTCHA generates reCAPTCHA tokens, and Google Cloud Armor performs the token assessment process instead of reCAPTCHA. This reduces origin load, potentially reducing your costs, and puts security controls closer to the end user than your backends. For more information, see the bot management overview.

Set rate limiting thresholds

Rate limiting is a a flexible and valuable capability to prevent abuse and mitigate high volume threats like credential stuffing or L7 DDoS attacks. When you deploy rate limiting for the first time, it is important to choose a threshold that makes sense for your application. We recommend that you start with enforcement in preview mode. As you analyze and understand the traffic profile, you can adjust the rate limiting parameters. In addition, it is important to consider the priority that you assign to the rate limiting rule. Traffic might be explicitly allowed or denied by a higher priority rule before it is evaluated against the rate limiting rule.

Rule tuning

Web applications might allow requests that appear to be attacks, and they might allow, or even require, that users send requests that match the signatures in preconfigured WAF rules. It is critical that you validate your Google Cloud Armor rules against your application and address any findings that might not be relevant for your application prior to promoting the rule by disabling preview mode on a production application. The following sections contain best practices and recommendations for tuning the preconfigured WAF rules.

Choose your preconfigured WAF rule sensitivity level

When you implement any of the preconfigured WAF rules, you can choose an appropriate sensitivity level based on your security requirements and timelines. We recommend that you begin with a sensitivity level of 1 for most applications that must meet your organization's security requirements. Rules configured for sensitivity 1 use high fidelity signatures and reduce potential noise from the rule. Signatures associated with higher sensitivities might detect and prevent a larger set of exploit attempts, at the expense of potential noise for some protected applications. However, workloads subject to more strict security requirements might prefer the highest sensitivity level. For these use-cases, there might be a great amount of noise or irrelevant findings, which you must address using tuning before the security policy goes into production.

Enable verbose logging

If you require additional information about which request attributes and payloads are triggering a particular WAF rule, enable verbose logging. Verbose logging provides details from requests that trigger particular rules, including a snippet of the offending portion of the request, which is helpful for troubleshooting and tuning Google Cloud Armor. Because verbose logging can cause end-user request content to be logged in Cloud Logging, there is a chance that you accumulate end-user PII in your logs. As a result, we do not recommend running production workloads with verbose logging enabled for long periods of time.

Use stable or canary rules

There are two types of Google Cloud Armor preconfigured WAF rules: stable and canary. When new rules are added to the current ModSecurity Core Rule Set (CRS), we publish them to the canary rule builds before automatically publishing them into the stable rule builds. We recommend that you deploy the canary rules in a testing environment so that you can see the effects of any changes and additions in your environment. You can check rule names on the Tuning Google Cloud Armor WAF rules page to verify whether the canary build is in sync with the stable build.

Logging and monitoring

The following sections contain best practices and recommendations for configuring logging and monitoring.

Use the Security Command Center

Google Cloud Armor integrates automatically with the Security Command Center. Google Cloud Armor exports different findings to the Security Command Center:

  • Allowed Traffic Spike
  • Increasing Deny Ratio

Make sure that your web security personnel examine these findings.

Choose a Cloud Logging sampling rate

Google Cloud Armor per-request logs use the global external Application Load Balancer or the classic Application Load Balancer's logging infrastructure. As a result, Google Cloud Armor log generation is subject to the log sampling rate configured on the load balancer. We recommend keeping the sampling rate to 1 when you are actively tuning and implementing Google Cloud Armor. After you finish tuning and implementing Google Cloud Armor, we recommend that you keep full request logging turned on; however, you might prefer to down-sample to a lower rate. Both the global external Application Load Balancer and the classic Application Load Balancer do not enable logs by default, so it is important that you enable logging manually.

Use the Cloud Monitoring dashboard

Having a clear view of what is happening in your Google Cloud Armor configuration is essential. To make this easier, you can use the security dashboard. Additionally, you can export Google Cloud Armor logs directly from Logging to your own platform. If you are using Adaptive Protection, it is important to have an escalation path for any Adaptive Protection alerts that are triggered.

General management

The following contain additional best practices and recommendations for configuring Google Cloud Armor.

Set up Identity and Access Management access control

In accordance with general Google Cloud IAM best practices, ensure that the right people have access to Google Cloud Armor. The Compute Security Admin role is required to configure, modify, update, and delete Google Cloud Armor security policies. Additionally, the Compute Network Admin role or compute.backendServices.setSecurityPolicy permission is required to attach a Google Cloud Armor security policy to a backend service.

Minimize the number of policies

A Google Cloud Armor policy can be reused across multiple backend services. We recommend that you have a consistent set of reusable security policies.

Use Terraform

To ensure that configurations can be easily rolled back, as well as reproduced across projects, we recommend using Terraform. Google Cloud Armor has full Terraform integration for GA features.

Configure Google Cloud Armor with Google Kubernetes Engine

If you are using GKE, you must configure Google Cloud Armor and other ingress features through BackendConfig parameters. We recommend that you do not manually configure a global external Application Load Balancer or a classic Application Load Balancer to serve as an ingress point. For more information about configuring Google Cloud Armor with GKE, see Configuring ingress features.