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 188.8.131.52/24 and CIDR range 184.108.40.206/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.
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-west1region and another in the
- 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
220.127.116.11external IP address.
- Configure a Google Cloud Armor security policy that allows traffic from 18.104.22.168/24 and 22.214.171.124/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 of a global external Application Load Balancer or a classic Application Load Balancer, the 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 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.
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
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.
For more information about Cloud CDN, see the Cloud CDN documentation.
Google Cloud Armor with Cloud Run, App Engine, or Cloud Functions
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
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
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.
- Configure security policies, rules, and expressions
- Learn about the features in Managed Protection tiers
- Troubleshoot issues