Google Cloud Armor Security Policy Concepts

Overview

Use Google Cloud Armor security policies to protect your load-balanced services. Google Cloud Armor security policies are made up of rules that allow or prohibit traffic from IP addresses or ranges defined in the rule.

Google 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 Google Cloud Armor on Google Kubernetes Engine, see Configuring Google 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 address deny list and allow list at network edge
IP address deny list and allow list at network edge (click to enlarge)

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.

Google Cloud Armor security policies for HTTP(S) Load Balancing

  • Ability to create Google Cloud Armor security policies with deny list and allow list rules.
  • Ability to associate a Google Cloud Armor security policy with one or more HTTP(S) Load Balancing backend services.

IP address allow list and deny list rules in a Google 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.

Preview mode

  • 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.

Logging

  • The Google 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 Google Cloud Armor security policies

Google 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 Google 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 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 (max int32) and it is always present in the Google 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 allow.

You can apply an IP deny list/allow list Google Cloud Armor security policy to one or more backend services. A backend service can have only one Google Cloud Armor Security Policy associated with it.

An IP deny list/allow list Google Cloud Armor security policy cannot be deleted if any backend service references the policy. A backend service can be deletedregardless 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.

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. It will be ignored. However, when a Google Cloud Armor security policy is updated, you must provide an up-to-date fingerprint.

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

IP address deny list and allow list at network edge
IP address deny list and allow list at network edge (click to enlarge)

Use cases

This section presents three common use cases for Google 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.

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

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:

  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 allow listed 203.0.113.0/24.
  4. 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 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 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.

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)

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 100.1.1.0/24, and London, with the CIDR range 100.1.2.0/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.

Using IP deny lists and allow lists with distributed firewalls
       to restrict access
Using IP deny lists and allow lists with distributed firewalls to restrict access (click to enlarge)

In the above illustration, you accomplish your security objectives by configuring your GCP deployment as follows:

  1. Deploy backend application instances in the us-west and europe regions.
  2. Deploy an HTTP(S) load balancer as the front end to the instance, using 120.1.1.1 as the forwarding rule.
  3. Configure an edge 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.
  4. 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.
  5. 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 Google 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 Google Cloud Armor security policies and IAP are both enabled for a backend service of an HTTP(S) load balancer, the edge Google 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 Google Cloud Armor security policy or IAP results in a block decision.

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

Limits

  • Each project is limited to a maximum of 200 (two hundred) security rules across all Google Cloud Armor security policies.
  • Each project is limited to a maximum of 10 (ten) Google 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 Google Cloud Armor security policy. Google 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 Google Cloud Armor security policy exceeds the limit, then inbound traffic covered by security policies will be throttled to be within the limit.

Restrictions

  • Google Cloud Armor security policies and IP deny list/allow list are not supported for Cloud CDN. If you try to associate a Google 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 Google 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.

Next steps

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...

Google Cloud Armor Documentation