Common use cases for security policies

This page features common use cases for Google Cloud Armor security policies. Google Cloud Armor security policies can protect your application with features like IP address allowlists and denylists, and preconfigured rules to deter common web attacks.

Control access to your web applications and services

This section presents several ways to use Google Cloud Armor security policies to control access to your applications or services.

Enable access for users at specific IP addresses with allowlists

A typical use case for placing user IP addresses on an allowlist is when your global external Application Load Balancer or classic Application Load Balancer is accessed only by a specific set of users. In the following example, only users from your organization are allowed access to services behind your load balancer. These users have IP addresses or address blocks assigned by your organization. You can place these IP addresses or CIDR ranges on an allowlist so that only these users have access to the load balancer.

Restricting load balancer access by using an allowlist.
Restricting load balancer access by using an allowlist (click to enlarge).

You control access to the global external Application Load Balancer or the classic Application Load Balancer by configuring an allowlist with source IP addresses or source CIDR ranges from which access to your load balancer is permitted. The following section further describes this configuration.

In this configuration, you only want to allow users from your organization with IP addresses from an IP range to access the global external Application Load Balancer or the classic Application Load Balancer. You want all other traffic to be denied.

To create this configuration, follow these steps:

  1. Create a Google Cloud Armor security policy.
  2. In the security policy, add a rule that adds the range to the allowlist as the first rule. This rule has the description allow [RANGE], where [RANGE] is the desired IP range.
  3. Modify the default rule in the policy from an allow rule to a deny rule. The default rule governs traffic that does not match any of the preceding rules. It is the last rule in the policy. Changing the rule from allow to deny blocks all traffic that does not originate in the range on the allowlist.
  4. Associate this policy with the global external Application Load Balancer or the classic Application Load Balancer's backend service.

If your organization uses a third-party security provider to scrub traffic, you can add the security provider's IP address to an allowlist to ensure that only scrubbed traffic can access the global external Application Load Balancer or the classic Application Load Balancer and backends.

In the following illustration, the third-party provider is identified by the CIDR range 192.0.2.0/24, and this range is on an allowlist.

Restricting load balancer access by using an allowlist to restrict traffic from a third-party security provider.
Restricting load balancer access by using an allowlist to restrict traffic from a third-party security provider (click to enlarge).

Block access for users at specific IP addresses with denylists

Use denylists to create Google Cloud Armor security policies that reject traffic from an IP address or CIDR range. In the following illustration, the Google Cloud Armor security policy has a deny rule that blocks traffic from the IP address 198.51.100.1, where a malicious user has been identified.

Restricting load balancer access by using a denylist.
Restricting load balancer access by using a denylist (click to enlarge).

Custom rules to filter based on Layer 3 through Layer 7 parameters

Use the Google Cloud Armor custom rules language to define one or more expressions in a rule's match condition. When Google Cloud Armor receives a request, it evaluates the request against these expressions. If there is a match, the rule's action takes effect, either denying or allowing the incoming traffic.

The following examples are expressions that are written in the Google Cloud Armor extension of the Common Expression Language (CEL). For more information, see the Custom rules language reference.

To define expressions in a rule, use the gcloud --expression flag or the Google Cloud console. For more information, see Creating Google Cloud Armor security policies, rules, and expressions.

In the following example, requests from 2001:db8::/32 (such as your alpha testers) in the AU region match the following expression:

origin.region_code == "AU" && inIpRange(origin.ip, '2001:db8::/32')

The following example matches with requests from 192.0.2.0/24 and with a user agent that contains the string WordPress:

inIpRange(origin.ip, '192.0.2.0/24') && has(request.headers['user-agent']) && request.headers['user-agent'].contains('WordPress')

For additional examples, see Example expressions in the custom rules language reference.

Protect your deployment against application layer attacks and help mitigate OWASP Top 10 risks

You can use Google Cloud Armor to protect a Cloud CDN origin server from application layer (L7) attacks such as SQL injection (SQLi) and cross-site scripting (XSS). Content in a cache is static and presumably does not pose a risk of a targeted attack from the web. However, the underlying content origin server might be a dynamic application with known or potential web-app vulnerabilities. Your security or compliance requirements might require you to mitigate these risks to prevent vulnerability exploits from the internet from successfully attacking the origin server.

To mitigate the risks, follow these steps:

  1. Create or identify a backend service with CDN enabled.
  2. Create a Google Cloud Armor security policy.
  3. Create one or more rules in the security policy to deny L7 attacks.
  4. Configure one of the targets of the security policy to be the backend service that you created or identified in step 1.

You can also use preconfigured rules to detect and block common application layer attacks. Preconfigured rules are predefined expression sets that you can add to a Google Cloud Armor security policy. To add these expression sets to a rule, use the gcloud --expression flag or Google Cloud console. For more information, see Creating security policies, rules, and expressions.

For more information about preconfigured rules, see Preconfigured rules in the custom rules language reference.

The following example uses a preconfigured rule to mitigate cross-site scripting (XSS) attacks:

evaluatePreconfiguredExpr('xss-stable')

The following example uses a preconfigured rule to mitigate SQL injection (SQLi) attacks:

evaluatePreconfiguredExpr('sqli-stable')

You can also combine preconfigured rules with other expressions. The following example uses a preconfigured rule to mitigate SQLi attacks from the 192.0.2.1/24 IP address range:

inIpRange(origin.ip, '192.0.2.1/24') && evaluatePreconfiguredExpr('sqli-stable')

OWASP Top 10 mitigation for hybrid workloads

Google Cloud Armor offers mitigations for the following attacks, whether they are deployed in Google Cloud,on-premises, or in a third-party provider:

  • SQL injection (SQLi)
  • Cross-site scripting (XSS)
  • Local File Inclusion (LFI)
  • Remote File Inclusion (RFI)
  • Remote Code Execution (RCE)

You can use these capabilities to address some of the most common web application security risks, including those risks identified in the OWASP Top 10 list.

Google Cloud Armor's preconfigured WAF rules can be added to a security policy to detect and deny unwelcome layer 7 requests containing SQLi or XSS attempts. Google Cloud Armor detects malicious requests and drops them at the edge of Google's infrastructure. The requests are not proxied to the backend service, regardless of where the backend service is deployed.

To defend a non-Google Cloud-hosted workload from these attacks at the edge of Google's network, follow these steps:

  1. Configure a global external Application Load Balancer or a classic Application Load Balancer with a backend service that has an internet NEG as a backend.
  2. Create a Google Cloud Armor security policy.
  3. Add preconfigured SQLi and XSS rules to the policy.
  4. Attach the security policy to the backend service that you created in step 1.
  5. Monitor Google Cloud Armor activity by using Cloud Logging, Cloud Monitoring, and the findings sent to Security Command Center.

Cloud CDN external origin server DDoS defense and layer 7 monitoring

Cloud CDN deployments with an external origin server can have Google's edge infrastructure as the frontend for proxying, caching, and Google Cloud Armor layer 7 filtering. Using internet NEGs, the origin server can be located on-premises or with a third-party infrastructure provider.

Google Cloud Armor and the rest of Google's edge infrastructure mitigates and drops L3/L4 attacks, alerts on suspicious Layer 7 activity, and stands ready to deny unwelcome layer 7 requests with custom rules. Google Cloud Armor logging and telemetry across Cloud Logging, Cloud Monitoring, and Security Command Center provide actionable insight for protected applications regardless of where they are deployed.

To enable Google Cloud Armor protection for CDN external origins servers, follow these steps:

  1. Configure a global external Application Load Balancer or a classic Application Load Balancer with a backend service that has an internet NEG as a backend.
  2. Enable Cloud CDN for this backend service.
  3. Create a Google Cloud Armor security policy.
  4. Attach the security policy to the backend service that you created in step 1.
  5. Access Google Cloud Armor alerts, logging and telemetry in Security Command Center, Cloud Logging, and Cloud Monitoring.

In addition, you can use edge security policies to protect content stored in cache. For more information on edge security policies, see the Security policy overview.

Layer 7 access controls and cache-busting attacks

Depending on the application architecture, you can configure one backend service to serve requests for various URLs, including cacheable and non-cacheable content. In such deployment scenarios, create Google Cloud Armor security policies that deny unwelcome traffic on certain request paths, but allow all clients to access static content on a different request path.

In other situations, even though the content is being efficiently served from cache, a malicious or faulty client might generate a high volume of requests that result in a cache miss and require the underlying origin server to fetch or generate the requested content. This can strain limited resources and have a negative impact on the availability of the application for all users. You can create a Google Cloud Armor security policy to match the signature of any clients that are causing the issue and deny the requests before they reach the origin server and affect performance.

To accomplish this, follow these steps:

  1. Create a Google Cloud Armor security policy.

  2. Configure a rule; for example, the following rule denies access to "/admin":

    request.path.contains("/admin") && !inIpRange(origin.ip, '<allowed_ip_range>')

  3. Attach the security policy from step 1 to the backend service that has Cloud CDN enabled.

What's next