Security policy overview

This page describes how you can use Google Cloud Armor security policies to protect your Google Cloud deployments.

Cloud Armor security policies protect your application by providing Layer 7 filtering and by scrubbing incoming requests for common web attacks or other Layer 7 attributes to potentially block traffic before it reaches your load-balanced backend services or backend buckets. Each security policy is made up of a set of rules that can be configured on attributes from Layer 3 through Layer 7. The rules can filter traffic based on conditions such as an incoming request's IP address, IP range, region code, or request headers.

Cloud Armor security policies are available for the following load balancer and endpoint types:

  • All external Application Load Balancers, including classic Application Load Balancers
  • Regional internal Application Load Balancer
  • Global external proxy Network Load Balancer (TCP/SSL)
  • Classic proxy Network Load Balancer (TCP/SSL)
  • Regional external passthrough Network Load Balancer (TCP/UDP)
  • External protocol forwarding
  • VMs with external IPv4 addresses or external IPv6 address ranges assigned to a network interface (NIC)

The load balancer can be in Premium Tier or Standard Tier.

The backends to the backend service can be any of the following:

When you use Cloud Armor to protect a hybrid deployment or a multicloud architecture, the backends must be internet NEGs or hybrid NEGs. Cloud Armor also protects serverless NEGs when traffic is routed through a load balancer. For information about how to route traffic through your load balancer before it reaches your serverless NEG, see Ingress controls.

Cloud Armor also provides advanced network DDoS protection for regional external passthrough Network Load Balancers, protocol forwarding, and VMs with public IP addresses. For more information about advanced DDoS protection, see Configure advanced network DDoS protection.

Protect your Google Cloud deployments with Cloud Armor security policies

External load balancing is implemented at the edge of Google's network in Google's points of presence (PoPs) around the world. In Premium Tier, user traffic directed to an external load balancer enters the PoP closest to the user. It 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.

Cloud Armor security policies enable you to allow, deny, rate-limit, or redirect requests to your backend services 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 shows the location of global external Application Load Balancers, classic Application Load Balancers, the Google network, and Google data centers.

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

Requirements

These are the requirements for using Cloud Armor security policies:

  • The backend service's load balancing scheme must be EXTERNAL, EXTERNAL_MANAGED, or INTERNAL_MANAGED.
  • The backend service's protocol must be one of HTTP, HTTPS, HTTP/2, UDP, TCP, SSL, or UNSPECIFIED.

About Cloud Armor security policies

Cloud Armor security policies are sets of rules that match on attributes from Layer 3 to Layer 7 networks to protect externally facing applications or services. Each rule is evaluated with respect to incoming traffic.

A Cloud Armor security policy rule consists of a match condition and an action to take when that condition is met. For example, a condition can be whether the incoming traffic's client IP address matches a specific IP address or CIDR range (also known as IP address allowlist and denylist rules). Alternatively, by using the Cloud Armor custom rules language reference, 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 an incoming request matches a condition in a security policy rule, Cloud Armor allows, denies, or redirects the request, based on whether the rule is an allow rule, a deny rule, or a redirect rule. There can be additional action parameters to apply, like inserting request headers; this feature is part of Cloud Armor bot management. For more information about bot management, see the bot management overview.

Cloud Armor provides two categories of security policies: hierarchical security policies and service-level security policies. Hierarchical security policies are attached at the organization, folder, or project level, while service-level security policies are associated with one or more backend services. For more information about hierarchical security policies, see Hierarchical security policies overview.

A backend service can have two service-level security policies associated with it at the same time, but it can't have two backend security policies or two edge security policies at the same time. However, your backend services don't all need to be associated with the same security policies. To attach and remove security policies from supported backend services and features, see Attach and remove security policies.

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

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

In the following diagram, the Cloud Armor security policy internal-users-policy is associated with the backend service test-network.

Cloud Armor security policy at network edge.
Cloud Armor security policy at network edge (click to enlarge).
Cloud Armor security policies have the following features:

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

  • You can use Cloud Armor with load balancers that are in either of the following Network Service Tiers:

    • Premium Tier
    • Standard Tier

  • You can use backend security policies with GKE and the default ingress controller.

  • You can use a default security policy that throttles traffic over a user-specified threshold when you configure one of the following load balancers:

    • Global external Application Load Balancer
    • Classic Application Load Balancer
    • Regional external Application Load Balancer
    • Regional internal Application Load Balancer
    • Global external proxy Network Load Balancer (TCP/SSL)
    • Classic proxy Network Load Balancer (TCP/SSL)

In addition, you can configure Cloud Armor preconfigured WAF rules, which are complex web application firewall (WAF) rules with dozens of signatures that are compiled from open source industry standards. Each signature corresponds to an attack detection rule in the rule set. Google offers these rules as is. The rules allow Cloud Armor to evaluate dozens of distinct traffic signatures by referring to conveniently named rules, rather than requiring you to define each signature manually. For more information about preconfigured WAF rules, see the preconfigured WAF rules overview.

Types of security policies

The following tables show the types of service-level security policies and what you can do with them. A check mark () indicates that the type of security policy supports the feature.