Use Cloud Armor security policies to protect your load-balanced services. Cloud Armor security policies are made up of rules that allow or prohibit traffic from IP addresses or ranges defined in the rule.
Cloud Armor security policies and IP deny lists and allow lists are available only for HTTP(S) Load Balancing. The HTTP, HTTPS, and HTTP/2 protocols are all supported. For information about configuring Cloud Armor on Google Kubernetes Engine, see Configuring Cloud Armor.
Edge security with IP deny lists/allow lists
GCP HTTP(S) Load Balancing is implemented at the edge of Google's network in Google's points of presence around the world. User traffic directed to an 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.
IP deny lists/allow lists enable you to restrict or allow access to your HTTP(S) load balancer at the edge of the Google Cloud, as close as possible to the user and to malicious traffic. This prevents malicious users or traffic from consuming resources or entering your virtual private cloud (VPC) networks.
The following diagram illustrates the location of the HTTP(S) load balancers, the Google network, and Google data centers.
IP deny list/allow list for HTTP(S) Load Balancing features
IP deny list/allow list for HTTP(S) Load Balancing has the following features.
Cloud Armor security policies for HTTP(S) Load Balancing
- Ability to create Cloud Armor security policies with deny list and allow list rules.
- Ability to associate a Cloud Armor security policy with one or more HTTP(S) Load Balancing backend services.
IP address allow list and deny list rules in a Cloud Armor security policy
- Deny listing for IP address / CIDR provides the ability to block a source IP address or CIDR range from accessing HTTP(S) load balancers.
- Allow listing for IP address / CIDR provides the ability to allow a source IP address or CIDR range to access HTTP(S) load balancers.
IPv4 and IPv6 addresses are supported in allow list and deny list rules.
You can configure a deny rule to display a 403, 404, or 502 error code.
When you configure multiple rules, you can designate the order in which the rules are evaluated.
- Ability to preview the effects of the rules in a security policy in stackdriver logs without enforcing the actions in the rules
- In the Console, you can explicitly enable preview mode.
- The Cloud Armor security policy name, matched rule priority, associated action, and related information are logged for HTTP(S) requests to your HTTP(S) load balancer.
About Cloud Armor security policies
Cloud Armor security policies are sets of rules you define to enforce security conditions in your network. Each rule is evaluated with respect to incoming traffic.
An IP deny list/allow list Cloud Armor security policy rule consists of a match condition and an action to take when that condition is met. The action is either to allow or deny traffic according to the match condition. By default, the action is enforced, but a preview option is available. When you set the preview option to true, the action is not enforced.
Rules are assigned a priority and then evaluated in order of priority, from the lowest to highest number. The highest-priority rule is the rule assigned the number 0. The priority of a rule decreases as its number increases (1, 2, 3, N+1). The first rule that matches the request and is not in preview mode is applied.
You cannot configure two or more rules with the same priority. Priority for each rule must be set to a number between 0 and 2147483647 inclusive.
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 impact on existing rules.
Each 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
(max int32) and it is always present in the Cloud Armor security policy. The
default rule cannot be deleted, but it can be modified. The default action for
the default rule is
deny, but you can change the action to
You can apply an IP deny list/allow list Cloud Armor security policy to one or more backend services. A backend service can have only one Cloud Armor Security Policy associated with it.
An IP deny list/allow list Cloud Armor security policy cannot be deleted if any backend service references the policy. A backend service can be deleted regardless of whether it has an associated Cloud Armor security policy.
If multiple forwarding rules point to a backend service that has an associated Cloud Armor security policy, the policy rules are enforced for all traffic coming in to each of these forwarding rule IP addresses.
Each 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. It will be ignored. However, when a Cloud Armor
security policy is updated, you must provide an up-to-date fingerprint.
In the illustration below, the Cloud Armor security policy
internal-users-policy is associated with the backend service
This section presents three common use cases for Cloud Armor security policies and IP deny lists/allow lists.
Use case 1: Limiting access to the GCP HTTP(S) load balancer
A typical use case for placing user IP addresses on an allow list is when your external 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.
You control access to the 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 HTTP(S) load balancer. You want all other traffic to be denied.
To create this configuration, follow these steps:
- Create a Cloud Armor security policy.
- In the 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”.
- Modify the default rule in the policy from an
allowrule to a
denyrule. 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
denyblocks all traffic that does not originate in the allow listed 203.0.113.0/24.
- Associate this policy with the 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 Cloud Armor security policies that reject traffic from
an IP address or CIDR range. In the following illustration, the 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.
Use case 3: Allow traffic to the HTTPS load balancer only from an allow listed third-party security provider and other authorized users
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 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 allow listed.
IP deny lists/allow lists for HTTP(S) Load Balancing and GCP firewall rules
IP deny lists and allow lists and GCP firewall rules have complementary functions.
- IP deny lists and allow lists for HTTP(S) Load Balancing provide edge security and act on client traffic.
- Distributed firewalls on load balanced instances provide VPC-related controls and act on the proxied traffic from the load balancer.
For instance, consider a scenario in which you want to allow traffic only from corporate users in California, with the CIDR range 184.108.40.206/24, and London, with the CIDR range 220.127.116.11/24, to access your 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 HTTP(S) load balancer with deny lists and allow lists should reach the instances.
In the above illustration, you accomplish your security objectives by configuring your GCP deployment as follows:
- Deploy backend application instances in the us-west and europe regions.
- Deploy an HTTP(S) load balancer as the front end to the instance, using 18.104.22.168 as the forwarding rule.
- Configure an edge Cloud Armor security policy that allows traffic from 22.214.171.124/24 and 126.96.36.199/24 and denies all other traffic.
- Associate this policy with the HTTP(S) load balancer, or, more specifically, with the backend services. This is described in detail later in this document.
- Configure the distributed firewall rules for the instances to accept traffic only from the HTTP(S) load balancer. HTTP(S) Load Balancing is a proxy- based solution where the source IP address of the traffic changes to an internal IP address range, so you can set a firewall rule for your instances that permits only this internal range.
IP deny lists/allow lists for HTTP(S) Load Balancing and Identity-Aware Proxy
Cloud 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 HTTP(S) load balancer, you enable it on the load balancer's backend services. Similarly, edge Cloud Armor security policies with IP address deny lists and allow lists are attached to the backend services of an HTTP(S) load balancer.
If edge Cloud Armor security policies and IAP are both enabled for a backend service of an HTTP(S) load balancer, the edge Cloud Armor security policy evaluation result and the IAP result are used together to determine whether the traffic should be allowed or blocked. Traffic is blocked when either an edge Cloud Armor security policy or IAP results in a block decision.
IAM permissions for Cloud Armor security policies
The following operations require the role Security Admin (roles/compute.securityAdmin):
- Creating, modifying, updating, and deleting a Cloud Armor security policy
- API methods allowed:
- SecurityPolicies insert
- SecurityPolicies delete
- SecurityPolicies patch
- SecurityPolicies addRule
- SecurityPolicies patchRule
- SecurityPolicies removeRule
A user with the Network Admin role (roles/compute.networkAdmin) can perform the following operations:
- Setting a Cloud Armor security policy for a backend service
- API methods allowed:
- BackendServices setSecurityPolicy
Users with the roles Security Admin and Network Admin can view Cloud Armor
security policies using the API methods SecurityPolicies
IAM permissions for custom roles
The following table lists the base IAM roles' base permissions and their associated API methods.
|IAM Permission||API Methods|
|compute.securityPolicies.get|| SecurityPolicies get
- Each project is limited to a maximum of 200 (two hundred) security rules across all Cloud Armor security policies.
- Each project is limited to a maximum of 10 (ten) Cloud Armor security policies.
- Each rule is limited to a maximum of 5 (five) IP addresses or IP address ranges.
- There is a limit of 20,000 requests per second per project across all backends with a Cloud Armor security policy. Cloud Armor limits the volume of traffic that can be processed by all security policies on a per-project basis. Once the inbound request traffic volume (RPS) across all backends protected by a Cloud Armor security policy exceeds the limit, then inbound traffic covered by security policies will be throttled to be within the limit.
- Cloud Armor security policies and IP deny list/allow list are not supported for Cloud CDN. If you try to associate a Cloud Armor Security Policy for a backend service and Cloud CDN is enabled, the config will be rejected. Similarly, if you attempt to enable Cloud CDN for a backend service that has an associated Cloud Armor security policy, the configuration process will fail.
- IP deny list/allow list for HTTP(S) Load Balancing is not supported for Google Cloud Storage backends.