Announcing general availability of Cloud Armor’s new edge security policies, and support for proxy load balancers

Whether workloads are deployed in public clouds, on-premises, or other infrastructure providers, DDoS and Layer 7 attacks target all web applications, APIs, and services. That’s why Google Cloud continues to expand our scope of DDoS and web application firewall (WAF) protection for web applications, APIs, and services with Google Cloud Armor, so customers can defend internet-facing workloads no matter which architecture they choose.

Today, we are announcing two major capabilities that expand Cloud Armor’s coverage to more types of workloads. First, we are launching edge security policies to help defend workloads using Cloud CDN, Media CDN, and Cloud Storage and filter requests before they are served from cache. Second, Cloud Armor now supports the TCP Proxy and SSL Proxy Load Balancers, to help block malicious traffic attempting to reach backends behind these load balancers. 

Many of our customers already protect mission-critical, internet-facing services with Cloud Armor. Cloud Armor provides advanced protection of web applications, services, and APIs against DDoS, Layer 7 attacks, and fraud from bots, at planet-scale, for hybrid, multi-cloud architectures.

Extending Support for Hybrid, Multi-cloud, and High Performance Deployments

Web teams want to accelerate deployments and optimize content delivery through the use of increasingly complex applications, and do so across a variety of load balancers and caches in hybrid, multi-cloud environments.

Google Cloud has been steadily expanding its coverage for various types of workloads, adding the ability to help protect and provide services to more and more workloads in a broader set of locations, including those on Google Cloud, on-premise, in colocation, and in multiple public clouds. Cloud Armor can help customers to deploy a consistent, secure edge regardless of where their workloads ultimately reside. 

Two years ago, Google Cloud introduced support for Internet Network Endpoint Groups (NEGs) and Hybrid NEGs, giving customers the ability to route traffic from Google Cloud’s edge to their workloads, either over the public internet, through private interconnect, or VPN tunnels. This update transformed Google Cloud Load Balancer and Cloud Armor into cloud services able to front and protect workloads wherever they may reside.

In addition, for performance improvement and scale, customers are adopting a variety of Google Cloud services to accelerate and optimize application and content delivery, including:

• Google Cloud CDN

• Google Media CDN (recently announced, see blog)

• Google Cloud Storage (buckets)

• SSL Proxy Load Balancer for encrypted (SSL and TLS), non-HTTP traffic 

• TCP Proxy Load Balancer in order to handle their own SSL/TLS termination downstream

To further help our customers take on the challenge of protecting web applications and services across these diverse edge points, Cloud Armor now provides expanded coverage in two key areas: 

• Edge Security Policies for Cloud CDN, Media CDN, and Cloud Storage

• Support for both the TCP Proxy and SSL Proxy Load Balancers

Edge Security Policies Filter Requests Before Serving From Cache

Cloud Armor edge security policies allow customers to filter traffic before it is served from Cloud CDN and the newly released Media CDN caches, as well as Cloud Storage backend buckets. Customers can also enforce geography-based access controls and security policies at the edge of the Google network and cache upstreams.

The edge security policies and backend security policies can coexist on backend services fronted by the HTTP/S Load Balancer. When present, the edge security policies are evaluated so they can filter requests whether or not they would result in a cache hit and be served from cache. Backend security policies evaluate Cloud CDN Cache misses as well as requests for dynamic content that will be served from backend services, as seen above in Figure 1. For backend buckets, only edge security policies can be applied, then the traffic permitted through the policy will be forwarded by the load balancer to the destination bucket(s).  

Logs from edge security policies can capture evidence that controls such as IP filtering and enforcement of location-based restrictions are in place to facilitate compliance audits and inspection of CDN and bucket-bound connections.

Here is an example using Google Cloud Console to create an Edge Security Policy:

Cloud Armor for TCP Proxy and SSL Proxy Load Balancers Helps Block Malicious Traffic

In addition to the Google Cloud External HTTP Load Balancer, Google Cloud offers the SSL Proxy Load Balancer for encrypted (SSL and TLS), non-HTTP traffic, and the TCP Proxy Load Balancer. Customers can use these proxy endpoints to leverage the Google global load balancing infrastructure to serve TCP-based workloads that don’t use the HTTP protocol. Another use-case addressed here is for customers who prefer to handle their TLS/SSL offload downstream, or who require mTLS support.

Cloud Armor support for both these load balancers is now available for customers. These capabilities allow customers to leverage the network edge to block and/or throttle potentially malicious traffic based on IP address and end-user geolocation. Customers can also enable per-connection rate-limiting to ensure no individual end-user sends more than the desired amount of traffic. Read more about our newly released rate-limiting capability in this blog. 

Using the gcloud command line interface (CLI), customers can create security policies, enforce filters, and configure rate limits on new connection requests. Policies can be reused across HTTP/S load balancer and TCP/SSL proxy load balancers, leveraging fields like IP address, geolocation, and rate limiting rules to consolidate and simplify configuration and operations. In order to configure Cloud Armor to filter traffic headed to TCP and SSL Proxies, policies can be attached to a TCP/SSL Proxy Load Balancer-protected backend service. Connection Logs including Cloud Armor decisions can be sent to Cloud Logging by the TCP/SSL Proxy Load Balancers, which can be enabled via the CLI.

You can create and enable your policy for TCP/SSL Proxy Load Balancers using the following gcloud CLI commands:

1. Create a Cloud Armor security policy “example-one”:

2. Add a rate limiting rule to Cloud Armor security policy “example-one”:

3. Attach policy to TCP/SSL Proxy Load Balancer backend service “my-service-two”:

4. Enable logging on TCP/SSL Proxy Load Balancer “my-service-two”

Edge Protection for More of Your Environments

With Cloud Armor, your organization can benefit from DDoS protection and WAF. Cloud Armor now helps detect and mitigate attacks against both cache points and backend service workloads, including those load-balanced by External HTTP/S Load Balancer, as well as the TCP and SSL Proxy Load Balancers. And these workloads can run anywhere: on-prem, in colocation data centers, in Google Cloud, and on other cloud platforms.

With Cloud Armor you also get a machine learning mechanism to identify and block Layer 7 DDoS attacks, the ability to mitigate OWASP Top 10 risks with pre-defined WAF rules, and bot management–so you can stop fraud at the edge. To learn more about Cloud Armor, visit our website. 

Cloud Armor is also announcing a set of features that can improve network security. To learn more, explore the following resources:

• Introducing new Cloud Armor features including rate limiting, adaptive protection, and bot defense

• Rate Limiting overview

• Bot Management overview

• Preconfigured WAF rules

• Configure Threat Intelligence

• Apply Adaptive Protection

• Get better cost predictability and volume pricing, advanced features, and two additional support services with Cloud Armor Managed Protection Plus.