Integrating Google Cloud Armor with other Google products

The following sections discuss how Google Cloud Armor interacts with other Google Cloud features and products.

Google Cloud Armor and VPC firewall rules

Google Cloud Armor security policies and VPC firewall rules have different functions:

Google Cloud Armor security policies provide edge security and act on client traffic to Google Front Ends (GFEs).
VPC firewall rules allow or deny traffic to and from your backends. You must create ingress allow firewall rules, whose targets are the load-balanced backend VMs, and whose sources are IP ranges used by global external Application Load Balancers or classic Application Load Balancers. These rules allow GFEs and the health check systems to communicate with your backend VMs.

For example, consider a scenario in which you want to allow traffic only from CIDR range 100.1.1.0/24 and CIDR range 100.1.2.0/24 to access your global external Application Load Balancer or classic Application 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 global external Application Load Balancer or the classic Application Load Balancer with an associated security policy should reach the instances.

Using Google Cloud Armor security policy with ingress firewalls
to restrict access. — Using Google Cloud Armor security policy with ingress firewalls to restrict access (click to enlarge).

In the previous illustration, you accomplish your security objectives by configuring your Google Cloud deployment as follows:

Create two instance groups, one in the us-west1 region and another in the europe-west1 region.
Deploy backend application instances to the VMs in the instance groups.
Create a global external Application Load Balancer or a classic Application Load Balancer in Premium Tier. Configure a simple URL map and a single backend service whose backends are the two instance groups that you created in the previous step. Ensure that the load balancer's forwarding rule uses the 120.1.1.1 external IP address.
Configure a 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.
Associate this policy with the load balancer's backend service. For instructions, see Configuring security policies. External HTTP(S) load balancers with more complex URL maps can reference multiple backend services. You can associate the security policy with one or more of the backend services as needed.
Configure ingress allow firewall rules to permit traffic from the global external Application Load Balancer or the classic Application Load Balancer. For more information, see Firewall rules.

Google Cloud Armor with external Application Load Balancers and IAP

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 global external Application Load Balancer or the classic Application Load Balancer, you enable it on the load balancer's backend services. Similarly, edge Google Cloud Armor security policies are attached to the backend services of a global external Application Load Balancer or a classic Application Load Balancer.

If Google Cloud Armor security policies and IAP are both enabled for a backend service, the order of their evaluation depends on the type of the load balancer:

For a backend service of a global external Application Load Balancer, Google Cloud Armor evaluation happens first. If Google Cloud Armor blocks a request, IAP does not evaluate the request. If Google Cloud Armor allows a request, IAP then evaluates the request. The request is blocked if IAP does not authenticate the request.
For a backend service of a classic Application Load Balancer, IAP evaluation happens first. If IAP authenticates a request, then Google Cloud Armor evaluates the request. If a request fails IAP authentication, then Google Cloud Armor does not evaluate the request.

Using IP address denylists and allowlists with IAP. — Using IP address denylists and allowlists with IAP (click to enlarge).

For more information about IAP and related configurations, see the Identity-Aware Proxy documentation.

Google Cloud Armor with hybrid deployments

In a hybrid deployment, a global external Application Load Balancer or a classic Application Load Balancer needs access to an application or content source that runs outside Google Cloud, for example, in another cloud provider's infrastructure. You can use Google Cloud Armor to protect such deployments.

In the following diagram, the load balancer has two backend services. One has an instance group as its backend. The other backend service has an internet NEG as its backend, and the internet NEG is associated with an application that is running in a third-party provider's data center.

Google Cloud Armor for hybrid deployments. — Google Cloud Armor for hybrid deployments (click to enlarge).

When you attach a Google Cloud Armor security policy to the backend service that has an internet NEG as the backend, Google Cloud Armor inspects every L7 request that arrives at the global external Application Load Balancer or classic Application Load Balancer that is destined for that backend service.

Google Cloud Armor protection for hybrid deployments is subject to the same limitations that apply to internet NEGs.

Google Cloud Armor with Google Kubernetes Engine (GKE) Ingress

After you configure a Google Cloud Armor security policy, you can use Kubernetes Ingress to enable it with GKE.

You can reference your security policy with a BackendConfig resource by adding the name of your security policy to the BackendConfig. The following BackendConfig manifest specifies a security policy named example-security-policy:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  namespace: cloud-armor-how-to
  name: my-backendconfig
spec:
  securityPolicy:
    name: "example-security-policy"

For more information about Ingress features, see Configuring Ingress features.

Google Cloud Armor with Cloud CDN

To protect CDN origin servers, you can use Google Cloud Armor with Cloud CDN. Google Cloud Armor protects your CDN origin server from application attacks, mitigates OWASP Top 10 risks, and enforces Layer 7 filtering policies. There are two types of security policy that affect how Google Cloud Armor works with Cloud CDN: edge security policies and backend security policies.

Edge security policies

You can use edge security policies for Cloud CDN-enabled backend services and Cloud Storage backend buckets behind the global external Application Load Balancer or the classic Application Load Balancer. Use edge security policies to filter requests before content is served from cache.

Backend security policies

When Google Cloud Armor backend security policies are applied to backend services with Cloud CDN enabled, they apply only to requests routed to the backend service. These requests include dynamic content requests and cache misses—that is, requests that miss or bypass the Cloud CDN cache.

Requests are always first evaluated against edge security policies. For requests allowed by the edge security policies, the request is served to the user and is not evaluated against the backend security policy. Otherwise, the request is evaluated again, this time against the backend security policy.

The following diagram shows exclusively how backend security policies work with Cloud CDN origins, after the requests have been allowed by the edge security policies.

Using Google Cloud Armor backend security policies with Cloud CDN. — Using Google Cloud Armor backend security policies with Cloud CDN (click to enlarge).

For more information about Cloud CDN, see the Cloud CDN documentation.

Google Cloud Armor with Cloud Run, App Engine, or Cloud Functions

You can use Google Cloud Armor security policies with a serverless NEG backend that points to a Cloud Run, App Engine, or Cloud Functions service.

However, when you use Google Cloud Armor with serverless NEGs, Cloud Run, or Cloud Functions, you must take special steps to ensure that all access to the serverless endpoint is filtered through a Google Cloud Armor security policy.

Users who have the default URL for a serverless application can bypass the load balancer and go directly to the service URL. This bypasses Google Cloud Armor security policies. In addition, you cannot disable the URLs that Google Cloud automatically assigns to Cloud Run or Cloud Functions services. To protect these applications, you can use App Engine ingress controls or Cloud Run ingress controls.

To ensure that your access controls are applied to all incoming traffic, you can use internal-and-gclb when you configure Cloud Functions or Cloud Run. This allows only internal traffic and traffic sent to an external IP address exposed by the global external Application Load Balancer or the classic Application Load Balancer. Traffic sent to cloudfunctions.net or any other custom domain set up through Cloud Functions is blocked. This prevents users from circumventing any access controls (such as Google Cloud Armor security policies) set up through the global external Application Load Balancer or classic Application Load Balancer.

For more information about serverless NEGs, see Serverless network endpoint groups overview and Setting up serverless NEGs.