Skip to content
Threat Prevention and Detection
Cloud Armor
Google Cloud Armor helps protect your infrastructure and applications from Layer 3/Layer 4 network or protocol-based volumetric distributed denial-of-service (DDoS) attacks, volumetric Layer 7 attacks, and other targeted application attacks. It leverages Google's global network and distributed infrastructure to detect and absorb attacks and filter traffic through user-configurable security policies at the edge of Google's network, far upstream of your workloads.
Google 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.
Google Cloud Armor security policies are available for the following load balancer and endpoint types:
The backends to the backend service can be any of the following:
Google Cloud Armor also provides advanced network DDoS protection for , , and VMs with public IP addresses. For more information about advanced DDoS protection, see .
Google 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.
Google Cloud Armor policy at network edge
About Google Cloud Armor security policies
Google Cloud Armor security policies are sets of rules that match on attributes from Layer 3 to Layer 7 to protect 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 allowlist and denylist rules). Alternatively, by using the , 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, Google 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 Google Cloud Armor bot management. For more information about bot management, see the .
Example
In the following example, rules 1, 2, and 3 are evaluated in that order for the IP and HTTP header fields. However, if an IP 9.9.9.1 launches an 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
Want to print your doc?
This is not the way.
This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (
CtrlP
) instead.