Google Cloud Armor security policy overview

Overview

Use Google Cloud Armor security policies to protect your load-balanced applications from Distributed Denial of Service (DDoS) and other web-based attacks, whether the applications are deployed on Google Cloud, in a hybrid deployment, or in a multi-cloud architecture.

Google Cloud Armor security policies are made up of rules that filter traffic based on layer 3, 4, and 7 attributes. For example, you can specify conditions that match on an incoming request's IP address, IP range, region code, or request headers.

Google Cloud Armor security policies are available only for backend services behind an external HTTP(S) load balancer. The load balancer can be in Premium Tier or Standard Tier. DDoS protection is automatically provided for HTTP(S) Load Balancing, SSL Proxy Load Balancing, and TCP Proxy Load Balancing.

The HTTP, HTTPS, HTTP/2, and QUIC protocols are all supported. For information about configuring Google Cloud Armor on Google Kubernetes Engine, see Configuring Google Cloud Armor through Ingress.

The backends to the backend service can be VMs in an instance group, zonal network endpoint groups (zonal NEGs), or internet network endpoint groups (internet NEGs). When you use Google Cloud Armor to protect a hybrid deployment or multi-cloud architecture, the backends must be internet NEGs.

Edge security with Google Cloud Armor security policies

Google Cloud HTTP(S) Load Balancing is implemented at the edge of Google's network in Google's points of presence around the world. In Premium Tier, user traffic directed to an external HTTP(S) load balancer enters the POP closest to the user and is then load balanced over Google's global network to the closest backend that has sufficient capacity available. In Standard Tier, user traffic enters Google's network through peering, ISP, or transit networks in the region where you have deployed your Google Cloud resources.

Google Cloud Armor security policies enable you to allow or deny access to your external HTTP(S) load balancer at the Google Cloud edge, as close as possible to the source of incoming traffic. This prevents unwelcome traffic from consuming resources or entering your Virtual Private Cloud (VPC) networks.

The following diagram illustrates the location of the external HTTP(S) load balancers, the Google network, and Google data centers.

Google Cloud Armor policy at network edge
Google Cloud Armor policy at network edge (click to enlarge)

Google Cloud Armor requirements

  • The load balancer must be an external HTTP(S) load balancer.
  • The backend service's load balancing scheme must be EXTERNAL.
  • The backend service's protocol must be one of HTTP, HTTPS, or HTTP/2.

Google Cloud Armor features

Google Cloud Armor security policies have the following core features.

  • You can optionally use the QUIC protocol with load balancers that use Google Cloud Armor.

  • You can use Google Cloud Armor with external HTTP(S) load balancers that are in either Standard or Premium Network Service Tier.

  • You can use security policies with Google Kubernetes Engine and the default Ingress controller. For more information, see Configuring Google Cloud Armor.

Security policies for HTTP(S) Load Balancing

  • Each backend service of an external HTTP(S) load balancer can reference a single Google Cloud Armor security policy. You can use the same security policy with more than one backend service on the same or different external HTTP(S) load balancers.
  • You designate the priority (evaluation order) when multiple rules are configured.

IP address allow list and deny list rules

You can create IP address allow list and deny list rules within a security policy:

  • Deny listing for IP address / CIDR provides the ability to block a source IP address or CIDR range from accessing external HTTP(S) load balancers.
  • Allow listing for IP address / CIDR provides the ability to allow a source IP address or CIDR range to access external HTTP(S) load balancers.
  • IPv4 and IPv6 addresses are supported in allow list and deny list rules.
  • IP address rules that block or allow individual source IP addresses or CIDRs. Both IPv4 and IPv6 source addresses are supported, but IPv6 addresses must have subnet masks no larger than /64.
  • Deny rules can return an HTTP 403 (Unauthorized), 404 (Access Denied), or 502 (Bad Gateway) response.

Rules language and enforcement engine

  • Ability to write custom rule expressions that can match on various layer 3 through layer 7 attributes of incoming requests. Google Cloud Armor provides a flexible language for writing custom match conditions.
  • Ability to combine multiple sub-expressions in a single rule.
  • Ability to deny or allow requests based on the incoming request's region code. The region codes are based on the ISO 3166-1 alpha 2 codes. The region codes sometimes correspond to specific countries, but some encompass a country plus its associated areas. For example, the US code includes all states of the United States, one district, and six outlying areas.

Pre-configured rules for XSS, SQLi, LFI, RFI, and RCE

  • Mitigate the following attacks by using pre-configured rules:
    • Cross-site scripting (XSS)
    • SQL injection (SQLi) attacks
    • Local file inclusion (LFI) attacks
    • Remote file inclusion (RFI) attacks
    • Remote code execution (RCE) attacks
  • These rules are based on the OWASP Modsecurity core rule set version 3.0.1.

Pre-configured rules for named IP lists

  • Integrates third-party providers' named IP lists with Google Cloud Armor.
  • Simplifies maintenance of allowed or denied IP address ranges
  • Daily synchronization of third-party providers' lists
  • Increases your capacity for configuring IP addresses and ranges in security policies because named IP lists are not subject to limit on the number of IP addresses per rule

Preview mode

You can preview the effects of a rule without enforcing it. In preview mode, actions are noted in Cloud Monitoring. You can choose to preview individual rules in a security policy, or you can preview every rule in the policy.

Logging

  • The Google Cloud Armor security policy name, matched rule priority, associated action, and related information are logged for HTTP(S) requests to your external HTTP(S) load balancer. You must enable logging for HTTP(S) requests to record Google Cloud Armor logging information.

About Google Cloud Armor security policies

Google Cloud Armor security policies are sets of rules you define to enforce application layer firewall rules protecting externally facing applications or services. Each rule is evaluated with respect to incoming traffic.

A Google Cloud Armor security policy rule consists of a match condition and an action to take when that condition is met. Conditions can be as simple as whether the incoming traffic's source IP address matches a specific IP address or CIDR range (also known as IP address allow list and deny list rules). Alternatively, by using the Google Cloud Armor custom rules language, you can create custom conditions that match on various attributes of the incoming traffic, such as the URL path, request method, or request header values.

When a condition is met, the action is either to allow or deny traffic. By default, this action is enforced, but a preview option is available. When you set the preview option to true, the previewed action is logged but not enforced.

You can associate a Google Cloud Armor security policy with one or more backend services. A backend service can have only one Google Cloud Armor security policy associated with it.

A Google Cloud Armor security policy can't be deleted if it is associated with any backend service. A backend service can be deleted regardless of whether it has an associated Google Cloud Armor security policy.

If multiple forwarding rules point to a backend service that has an associated Google Cloud Armor security policy, the policy rules are enforced for all traffic coming in to each of these forwarding rule IP addresses.

In the illustration below, the Google Cloud Armor security policy internal-users-policy is associated with the backend service test-network.

Google Cloud Armor security policy at network edge
Google Cloud Armor security policy at network edge (click to enlarge)

Rule evaluation order

Rule evaluation order is determined by two factors: the rule priority and the rule type.

You assign a priority to rules, from the lowest to highest number. The rule with the lowest numeric value assigned has the highest logical priority and is evaluated prior to rules with lower logical priorities. The minimum numeric priority is 0. The priority of a rule decreases as its number increases (1, 2, 3, N+1). You cannot configure two or more rules with the same priority. The priority for each rule must be set to a number from 0 to 2147483646 inclusive. The priority value 2147483647, also known as INT-MAX, is reserved for the default rule.

Priority numbers can have gaps, which enable you to add or remove rules in the future without affecting the rest of the rules. For example, 1, 2, 3, 4, 5, 9, 12, 16 is a valid series of priority numbers to which you could add rules numbered from 6 to 8, 10 to 11, and 13 to 15 in the future without any change to the existing rules except for the change in the order of execution.

Typically, the highest priority rule that matches the request is applied. However, there is an exception when running HTTP POST requests through pre-configured rules configured using 'evaluatePreconfiguredExpr()'. The exception is as follows:

For HTTP POST requests, Google Cloud Armor receives the request's header before the body (payload). Because Google Cloud Armor receives the header information first, it evaluates rules that match against the header, but it does not match any pre-configured rules on the body. If there are multiple header-based rules, Google Cloud Armor evaluates them based on their priority as expected.

After Google Cloud Armor receives the HTTP POST body, it evaluates rules that apply to both the request header and body. As a result, it's possible that lower priority rules that check a request's header are matched before higher priority rules that check the request's body.

Example

In the following example, rules 1, 2, and 3 are evaluated in that order for the IP and HTTP header fields. But, if an IP 9.9.9.1 launches a XSS attack in the HTTP POST body, only the body is blocked (by rule 2); the HTTP header passes through to the backend (by rule 3).

Rule1
expr: inIPRange(origin.ip, '10.10.10.0/24')
action: deny(403)
priority: 1
Rule2
expr: evaluatePreconfiguredExpr('xss-stable')
action: deny(403)
priority: 2
Rule3
expr: inIPRange(origin.ip, '9.9.9.0/24')
action: allow
priority: 3
Rule-default
action: deny(403)
priority: INT-MAX

In the following example, the policy allows 9.9.9.1 without scanning against XSS attacks:

Rule1
expr: inIPRange(origin.ip, '10.10.10.0/24')
action: deny(403)
priority: 1
Rule2
expr: inIPRange(origin.ip, '9.9.9.0/24')
action: allow
priority: 2
Rule3
expr: evaluatePreconfiguredExpr('xss-stable')
action: deny(403)
priority: 3
Rule-default
action: allow
priority: INT-MAX

Default rule

Each Google Cloud Armor security policy contains a default rule that is matched if none of the higher priority rules are matched or if there are no other rules in the policy. The default rule is automatically assigned a priority of 2147483647 (INT-MAX) and it is always present in the Google Cloud Armor security policy. You cannot delete the default rule, but you can modify it. The default action for the default rule is deny, but you can change the action to allow.

Fingerprint

Each Google Cloud Armor security policy has a field fingerprint. The fingerprint is a hash of the contents stored in the policy. When you create a new policy, do not provide the value of this field. If you provide a value, it is ignored. However, when you update a Google Cloud Armor security policy, you must specify the current fingerprint, which you get when you export or describe the policy.

The fingerprint protects you from overriding another user's update. If the fingerprint that you provide is out of date, it means the Google Cloud Armor security policy was updated since you last retrieved the fingerprint. Describe the Google Cloud Armor security policy to check for any differences and to retrieve the latest fingerprint.

How WebSocket connections are handled

External HTTP(S) Load Balancing has native support for the WebSocket protocol. WebSocket channels are initiated from HTTP(S) requests. Google Cloud Armor can block a WebSocket channel from being established, for example, if an IP address deny list blocks the originating IP address. However, subsequent transactions in the channel do not conform to the HTTP protocol and Google Cloud Armor does not evaluate any messages after the first request.

Google Cloud Armor security policies for HTTP(S) Load Balancing and VPC firewall rules

Google Cloud Armor security policies and VPC firewall rules have different functions.

  • Google Cloud Armor security policies provide edge security and act on client traffic to Google Front Ends (GFEs).
  • VPC firewall rules allow or deny traffic to and from your backends. You must create ingress allow firewall rules, whose targets are the load-balanced backend VMs, and whose sources are IP ranges used by external HTTP(S) load balancers. These rules allow GFEs and the health check systems to communicate with your backend VMs.

For instance, consider a scenario in which you want to allow traffic only from CIDR range 100.1.1.0/24 and CIDR range 100.1.2.0/24 to access your external HTTP(S) load balancer. Your goal is to ensure that traffic cannot directly reach the backend load balanced instances; in other words, only external traffic proxied through the external HTTP(S) load balancer with an associated security policy should reach the instances.

Using Google Cloud Armor security policy with ingress firewalls
       to restrict access
Using Google Cloud Armor security policy with ingress firewalls to restrict access (click to enlarge)

In the previous illustration, you accomplish your security objectives by configuring your Google Cloud deployment as follows:

  1. Create two instance groups, one in the us-west1 region and another in the europe-west1 region.
  2. Deploy backend application instances to the VMs in the instance groups.
  3. Create an external HTTP(S) load balancer in Premium Tier. Configure a simple URL map and a single backend service whose backends are the two instance groups that you created in the previous step. Ensure that the load balancer's forwarding rule uses the 120.1.1.1 external IP address.
  4. Configure a Google Cloud Armor security policy that allows traffic from 100.1.1.0/24 and 100.1.2.0/24 and denies all other traffic.
  5. Associate this policy with the load balancer's backend service. See Configuring security policies for instructions. External HTTP(S) load balancers with more complex URL maps can reference multiple backend services. You can associate the security policy with one or more of the backend services, as needed.
  6. Configure ingress allow firewall rules to permit traffic from the external HTTP(S) load balancer. For more information, see Firewall rules.

Google Cloud Armor security policies for HTTP(S) Load Balancing and Identity-Aware Proxy

Identity-Aware Proxy (IAP) verifies a user's identity and then determines whether that user should be permitted to access an application. To enable IAP for the external HTTP(S) load balancer, you enable it on the load balancer's backend services. Similarly, edge Google Cloud Armor security policies are attached to the backend services of an external HTTP(S) load balancer.

If Google Cloud Armor security policies and IAP are both enabled for a backend service of an external HTTP(S) load balancer, the IAP evaluation happens first. If IAP blocks a request, Google Cloud Armor does not evaluate the request. If IAP successfully authenticates a request, the request is then evaluated by Google Cloud Armor. The request is blocked if a Google Cloud Armor security policy produces a deny decision.

Using IP deny lists and allow lists with IAP
Using IP deny lists and allow lists with IAP (click to enlarge)

For more information about IAP and related configurations, see the Identity-Aware Proxy documentation.

Google Cloud Armor with hybrid deployments

In a hybrid deployment, a Google Cloud load balancer needs access to an application or content source that runs outside Google Cloud, for example, in another cloud provider's infrastructure. You can use Google Cloud Armor to protect such deployments.

In the following diagram, the load balancer has two backend services. One has an instance group as its backend. The other backend service has an internet NEG as its backend, and the internet NEG is associated with an application that is running in a third-party provider's data center.

Google Cloud Armor for hybrid deployments
Google Cloud Armor for hybrid deployments (click to enlarge)

When you attach a Google Cloud Armor security policy to the backend service that has an internet NEG as the backend, Google Cloud Armor inspects every L7 request that arrives at the external HTTP(S) load balancer that is destined for that backend service.

Google Cloud Armor protection for hybrid deployments is subject to the same limitations that apply to internet NEGs.

Google Cloud Armor with Cloud CDN

You can use Google Cloud Armor with Cloud CDN to protect the CDN origin servers. Google Cloud Armor ensures that the CDN origin server is protected from application attacks, mitigates OWASP Top 10 risks, and enforces layer 7 filtering policies.

Google Cloud Armor enforces security policies for backend services with Cloud CDN enabled only for cache misses; that is, for requests that miss or bypass the Cloud CDN cache.

When a security policy is attached to a Cloud CDN-enabled backend service, Google Cloud Armor evaluates incoming requests that can't be served from the cache against the security policy to determine whether they should be forwarded to the origin server. If a rule matches on the request, the action that is configured in the rule is taken.

However, security policies attached to a Cloud CDN-enabled backend service are not enforced for cache hits. If a request can be served from the cache, it is served to any otherwise-valid client, regardless of what the security policy would have done for that request.

The following diagram shows how Google Cloud Armor works with Cloud CDN origins.

Using Google Cloud Armor with Cloud CDN \
Google Cloud Armor with Cloud CDN (click to enlarge)

Using Google Cloud Armor with serverless apps

You can use Google Cloud Armor security policies with a serverless NEG backend that points to a Cloud Run, App Engine, or Cloud Functions service.

However, when you use Google Cloud Armor with serverless NEGs and Cloud Functions, you must take special steps to work around a security issue.

Users who have the default URL for a Cloud Functions service can bypass the load balancer and go directly to the service URL. This bypasses Google Cloud Armor security policies. You cannot disable the URLs that Google Cloud automatically assigns to Cloud Functions services.

To avoid this security risk, you can use the internal-and-gclb when you configure Cloud Functions, which allows only internal traffic and traffic sent to a public IP address exposed by the external HTTP(S) load balancer. Traffic sent to cloudfunctions.net or any other custom domain set up through Cloud Functions is blocked. This prevents users from circumventing any access controls (such as Google Cloud Armor security policies) set up through the external HTTP(S) load balancer.

For more information about serverless NEGs, see Serverless network endpoint groups overview and Setting up serverless NEGs.

General use cases

This section presents several common use cases for Google Cloud Armor security policies.

Use case 1: Limiting access to the Google Cloud external HTTP(S) load balancer

A typical use case for placing user IP addresses on an allow list is when your external HTTP(S) load balancer is used 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 allow list so that only these users have access to the load balancer.

Restricting load balancer access with an allow list
Restricting load balancer access with an allow list (click to enlarge)

You control access to the external HTTP(S) load balancer by configuring an allow list 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 203.0.113.0/24 to access the external HTTP(S) 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 Google Cloud Armor security policy, add a rule that allow lists 203.0.113.0/24 as the first rule. This rule has the description "allow 203.0.113.0/24".
  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 203.0.113.0/24, which is on an allow list.
  4. Associate this policy with the external HTTP(S) load balancer's backend service.

Use case 2: Block unauthorized or malicious traffic at the edge with deny lists

Use deny lists 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 with a deny list
Restricting load balancer access with a deny list (click to enlarge)

Use case 3: Allow traffic to the external HTTP(S) load balancer only from a third-party security provider and other authorized users that are on an allow list

If your organization uses a third-party security provider to scrub traffic, you can allow list the security provider's IP address to ensure that only scrubbed traffic can access the external HTTP(S) load balancer and backends.

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

Restricting load balancer access by allow listing traffic from a
       third-party security provider
Restricting load balancer access by allow listing traffic from a third-party security provider (click to enlarge)

Use case 4: Customize defenses with custom rules that match 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 Google Cloud Armor 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 policy and rules.

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 1.2.3.4 and with a user agent that contains the string WordPress:

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

For additional examples, see Example expressions in the rules language reference. For information on tuning rules, see Tuning Google Cloud Armor WAF rules.

Use case 5: Mitigate application layer attacks by using pre-configured rules

Use pre-configured rules to detect and block common application layer attacks, such as XSS and SQLi. Pre-configured 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 Cloud Console. For more information, see Creating Google Cloud Armor security policy and rules.

For more information about pre-configured rules, see Pre-configured rules in the rules language reference.

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

evaluatePreconfiguredExpr('xss-stable')

The following example uses a pre-configured rule to mitigate SQL injection (SQLi) attacks:

evaluatePreconfiguredExpr('sqli-stable')

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

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

Use cases for hybrid deployments

This section presents use cases for Google Cloud Armor security policies with hybrid deployments.

OWASP Top 10 mitigation for hybrid workloads

Google Cloud Armor offers SQL injection (SQLi) and cross-site scripting (XSS) mitigation for your applications, whether they are deployed in Google Cloud, on-premises, or in a third-party provider. You can use these capabilities to address some of the most common web application security risks, including those 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 SQLi or XSS attacks at the edge of Google's network:

  1. Configure an external HTTP(S) load balancer with a backend service that has an internet NEG as a backend.
  2. Create a Google Cloud Armor security policy.
  3. Add 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 Operations Logging, Operations Monitoring, and the findings sent to the Cloud 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 front end 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 Operations Logging, Operations Monitoring, and Cloud 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:

  1. Configure an external HTTP(S) 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.

Use cases with Cloud CDN

This section presents two uses cases for Google Cloud Armor with Cloud CDN.

Use case: SQLi and XSS Mitigation

You can use Google Cloud Armor to protect a Cloud CDN origin server from risks such as SQL injection (SQLi) and cross-site scripting (XSS) attacks. 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:

  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 XSS and SQLi attacks.
  4. Configure one of the targets of the security policy to be the backend service you created or identified in step 1.

Use case: Layer 7 access controls and cache-busting attacks

Depending on the application architecture, you can configure one backend service to serve requests for a variety of 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 be generating 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.

You can accomplish this by completing the following steps:

  1. Create a Google Cloud Armor security policy
  2. Configure a rule; for example, this 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.

HTTP(S) Load Balancing request logging

Each HTTP(S) request is logged through Cloud Logging. The logs provide details such as the name of the applied security policy, the matching rule, and whether the rule was enforced. Request logging for new backend service resources is disabled by default. To ensure that Google Cloud Armor requests are logged, you must enable HTTP(S) logging.

For more information, see Logging in the HTTP(S) Load Balancing documentation.

To view Google Cloud Armor logs, see Viewing logs.

Limitations

  • IP deny list/allow list for HTTP(S) Load Balancing is not supported for Cloud Storage backend buckets.
  • Google Cloud Armor is not supported with Internal HTTP(S) Load Balancing.
  • Security policies are enforced for CDN cache misses only.
    • Content is served from cache even if a rule in a security policy would have denied the request.
  • You can enable preview mode for a rule using the gcloud command-line tool and the --preview flag of gcloud compute security-policies rules update. To disable preview mode, use the --no-preview flag, which is not currently documented. You can also use the Cloud Console.

What's next