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 external HTTP(S) 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 22.214.171.124/24 and CIDR range 126.96.36.199/24 to access your external 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 external HTTP(S) 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 an external HTTP(S) 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
188.8.131.52external IP address.
- Configure a Google Cloud Armor security policy that allows traffic from 184.108.40.206/24 and 220.127.116.11/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 external HTTP(S) load balancer. For more information, see Firewall rules.
Google Cloud Armor with HTTP(S) Load Balancing 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 external HTTP(S) 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 an external HTTP(S) load balancer.
If Google Cloud Armor security policies and IAP are both enabled for a backend service of an external HTTP(S) load balancer, the IAP evaluation happens first. If IAP blocks a request, Google Cloud Armor does not evaluate the request. If IAP successfully authenticates a request, Google Cloud Armor then evaluates the request. The request is blocked if a Google Cloud Armor security policy produces a deny decision.
For more information about IAP and related configurations, see the Identity-Aware Proxy documentation.
Google Cloud Armor with hybrid deployments
In a hybrid deployment, an external HTTP(S) 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 external HTTP(S) 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 external HTTP(S) 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 serverless apps
However, when you use Google Cloud Armor with serverless NEGs and 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 Cloud Functions service can bypass the load balancer and go directly to the service URL. This bypasses Google Cloud Armor security policies. You cannot disable the URLs that Google Cloud automatically assigns to Cloud Functions services.
To ensure that your access controls are applied to all incoming traffic, you can
when you configure Cloud Functions, which allows only internal traffic
and traffic sent to a public IP address exposed by the external HTTP(S) 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 external HTTP(S) load balancer.
- Configure security policies, rules, and expressions
- Learn about the features in Managed Protection tiers
- Troubleshoot issues