gem-netsec-cloud-armor

Activate Cloud Shell

Cloud Shell is a virtual machine that is loaded with development tools. It offers a persistent 5GB home directory and runs on the Google Cloud. Cloud Shell provides command-line access to your Google Cloud resources.

1. Click Activate Cloud Shell at the top of the Google Cloud console.

When you are connected, you are already authenticated, and the project is set to your PROJECT_ID. The output contains a line that declares the PROJECT_ID for this session:

Your Cloud Platform project in this session is set to YOUR_PROJECT_ID

gcloud is the command-line tool for Google Cloud. It comes pre-installed on Cloud Shell and supports tab-completion.

2. (Optional) You can list the active account name with this command:

gcloud auth list

3. Click Authorize.

4. Your output should now look like this:

Output:

ACTIVE: * ACCOUNT: student-01-xxxxxxxxxxxx@qwiklabs.net To set the active account, run: $ gcloud config set account `ACCOUNT`

5. (Optional) You can list the project ID with this command:

gcloud config list project

Output:

[core] project = <project_ID>

Example output:

[core] project = qwiklabs-gcp-44776a13dea667a6 Note: For full documentation of gcloud, in Google Cloud, refer to the gcloud CLI overview guide.

Overview

In this lab, you will explore Cloud Armor's geoblocking capabilities. You will create a Cloud Armor security policy and implement rules to deny and allow traffic based on geographic location to observe Cloud Armor's behavior. This lab provides hands-on experience with securing your Google Cloud applications using Cloud Armor.

Task 1. Setup and Initial Configuration

In this task, you will set up the environment, including enabling the necessary APIs and creating a backend service.

1. Set the project ID.

   gcloud config set project {{{ project_0.project_id | "PROJECT_ID" }}} Note:
   This command sets your active project. All subsequent `gcloud` commands will be executed within this project.

2. Set your default region to .

   gcloud config set compute/region {{{ project_0.default_region | "REGION" }}} Note:
   This command sets the default compute region. Resources will be created in this region.

3. Set your default zone to .

   gcloud config set compute/zone {{{ project_0.default_zone | "ZONE" }}} Note:
   This command sets the default compute zone. Resources will be created in this zone within the specified region.

4. Enable the necessary APIs.

   gcloud services enable compute.googleapis.com container.googleapis.com iap.googleapis.com Note:
   This command enables the Compute Engine, Kubernetes Engine, and Identity-Aware Proxy APIs, which are required for this lab.

Task 2. Create the VPC Network and Subnet

Create a VPC network named test-vpc with subnets test-subnet-us and test-subnet-eu. This VPC will host the instances used for testing.

1. Create the VPC network test-vpc.

   gcloud compute networks create test-vpc --subnet-mode=custom Note:
   This command creates a new VPC network with custom subnet mode, providing flexibility in defining subnets.

2. Create a subnet test-subnet-us in the test-vpc network within the specified region. Use the IP range 10.10.10.0/24.

   gcloud compute networks subnets create test-subnet-us --network=test-vpc --region={{{ project_0.default_region | "REGION" }}} --range=10.10.10.0/24 Note:
   This command creates a subnet in the specified VPC network with the IP address range `10.10.10.0/24`.

3. Create a subnet test-subnet-eu in the test-vpc network within the europe-west1 region. Use the IP range 10.20.20.0/24.

   gcloud compute networks subnets create test-subnet-eu \ --network=test-vpc \ --region=europe-west1 \ --range=10.20.20.0/24 Note:
   This command creates a subnet in the specified VPC network with the IP address range `10.20.20.0/24`.

4. Add a firewall rule for IAP access.

   gcloud compute firewall-rules create allow-iap-ssh \ --direction=INGRESS \ --priority=1000 \ --network=test-vpc \ --action=ALLOW \ --rules=tcp:22 \ --source-ranges=35.235.240.0/20 \ --target-tags=iap-gce Note:
   This command creates a firewall rule to allow IAP access to instances with the `iap-gce` tag.

5. Create a firewall rule to allow HTTP traffic to the backend.

   gcloud compute firewall-rules create allow-http \ --direction=INGRESS \ --priority=1500 \ --network=test-vpc \ --allow=tcp:80,tcp:443 \ --source-ranges=0.0.0.0/0 \ --target-tags=http-server,https-server Note:
   This command creates a firewall rule that allows HTTP and HTTPS traffic from any source to instances with the `http-server` and `https-server` tags.

Task 3. Implement a Backend Service with Health checks

In this task, you will implement health checks and create a backend service.

1. Create a health check.

   gcloud compute health-checks create http health-check-http \ --port=80 Note:
   This command creates an HTTP health check on port 80.

2. Create a backend service.

   gcloud compute backend-services create backend-service \ --health-checks=health-check-http \ --global Note:
   This command creates a global backend service using the health check created in the previous step.

Task 4. Create the Instance Template and Managed Instance Group

First, create an instance template, which is a blueprint for your VMs. Then, use this template to create a Managed Instance Group (MIG). The MIG will automatically manage the VMs, providing autohealing and autoscaling capabilities.

1. Create an instance template.

   gcloud compute instance-templates create backend-template \ --machine-type=e2-medium \ --image-family=debian-11 \ --image-project=debian-cloud \ --subnet=test-subnet-us \ --tags=http-server,https-server,iap-gce \ --metadata=startup-script='#! /bin/bash apt-get update apt-get install -y apache2 php libapache2-mod-php a2ensite default-ssl a2enmod ssl systemctl restart apache2 rm /var/www/html/index.html echo "

   Query string:

   " > /var/www/html/index.php systemctl restart apache2' Note:
   This command creates an instance template that defines the configuration for the backend VMs.

2. Create a managed instance group.

   gcloud compute instance-groups managed create backend-mig \ --base-instance-name=backend-vm \ --size=2 \ --template=backend-template \ --zone={{{ project_0.default_zone | "ZONE" }}} Note:
   This command creates a managed instance group (MIG) with an initial size of 2 VMs.

3. Add the managed instance group to the backend service.

   gcloud compute backend-services add-backend backend-service \ --instance-group=backend-mig \ --instance-group-zone={{{ project_0.default_zone | "ZONE" }}} \ --global Note:
   This command adds the managed instance group as a backend to the `backend-service`.

4. Create a health check.

   gcloud compute health-checks create http http-health-check \ --request-path=/ Note:
   This command creates a health check that sends requests to the root path (`/`).

5. Apply the health check to the backend service.

   gcloud compute backend-services update backend-service \ --health-checks=http-health-check \ --global Note:
   This command associates the health check with the `backend-service`.

Task 5. Create the frontend configuration

The frontend configuration is what your users will interact with. This involves a URL map, a proxy, a global IP address, and a forwarding rule.

1. Create a URL map.

   gcloud compute url-maps create url-map \ --default-service=backend-service Note:
   This command creates a URL map that routes all traffic to the `backend-service`.

2. Create a global HTTP proxy.

   gcloud compute target-http-proxies create http-proxy \ --url-map=url-map Note:
   This command creates a global HTTP proxy using the URL map created in the previous step.

3. Create a global static IP address.

   gcloud compute addresses create global-ip-address --global Note:
   This command creates a globally accessible static IP address.

4. Create a global forwarding rule.

   gcloud compute forwarding-rules create http-forwarding-rule \ --address=$(gcloud compute addresses describe global-ip-address \ --global --format='value(address)') \ --global \ --target-http-proxy=http-proxy \ --ports=80 Note:
   This command creates a global forwarding rule to direct traffic to the HTTP proxy using the created IP address.

Task 6. Implement Geoblocking with Cloud Armor

You will now create a Cloud Armor security policy and implement a rule to deny traffic from a specific region. Cloud Armor rules are processed in ascending order of priority; a lower priority number means the rule is evaluated first.

1. Create a Cloud Armor security policy.

   gcloud compute security-policies create "geoblocking-policy" \ --description="Blocks traffic from specific countries" Note:
   This command creates a Cloud Armor security policy named `geoblocking-policy`.

2. Add a rule to allow traffic from the United States (US).

   gcloud compute security-policies rules create 1000 \ --security-policy="geoblocking-policy" \ --description="Allow traffic from US" \ --expression="origin.region_code == 'US'" \ --action=allow Note:
   This command creates a rule that allows traffic from the United States. This rule has a high priority number (1000) so it is evaluated after the deny rules. It's a best practice to explicitly allow traffic from regions you want to serve, but for geoblocking, it's not strictly necessary unless you're implementing a "deny all, allow specific" policy. The priority is essential for the rule's position in the policy.

3. Add a rule to deny traffic from Belgium (BE).

   gcloud compute security-policies rules create 10 \ --security-policy="geoblocking-policy" \ --description="Deny traffic from Belgium" \ --expression="origin.region_code == 'BE'" \ --action=deny-403 Note:
   This command blocks traffic from Belgium before the allow rules are considered. The `deny-403` action returns an HTTP 403 Forbidden error. The `origin.region_code` expression matches traffic originating from Belgium.

4. Attach the security policy to the backend service.

   gcloud compute backend-services update backend-service \ --security-policy="geoblocking-policy" \ --global Note:
   This command attaches the security policy to the backend service, applying the policy's rules to all traffic directed to the backend service.

Task 7. Test Geoblocking using regional resources

You will now test the Cloud Armor security policy to assess the geoblocking from multiple locations.

1. Create a Compute Engine instance named test-vm-us in the test-subnet-us.

   gcloud compute instances create test-vm-us \ --subnet=test-subnet-us \ --machine-type=e2-medium \ --tags=iap-gce \ --zone={{{ project_0.default_zone | "ZONE" }}} Note:
   This command creates a Compute Engine instance in the specified subnet.

2. Create a Compute Engine instance named test-vm-europe in the test-subnet-eu.

   gcloud compute instances create test-vm-europe \ --subnet=test-subnet-eu \ --machine-type=e2-medium \ --tags=iap-gce \ --zone=europe-west1-b Note:
   This command creates a Compute Engine instance in the specified subnet.

3. Get the IP address of the backend service.

   BACKEND_IP=$(gcloud compute addresses describe global-ip-address --global --format='value(address)') && echo $BACKEND_IP Note:
   This command retrieves the IP address associated with the backend service, which will be used to test geoblocking.

4. In the following steps, you may see an SSH prompt similar to that below.

   Do you want to continue (Y/n)? Y Generating public/private rsa key pair. Enter passphrase (empty for no passphrase): Enter same passphrase again: Note:
   The initial SSH communication will alert you to a new host connection and ask if you wish to enter a passphrase. For this lab exercise, a passphrase is not required, so press the Enter key to confirm.

5. Test the deny rule from a US GCE instance.

   gcloud compute ssh test-vm-us \ --zone={{{ project_0.default_zone | "ZONE" }}} \ --tunnel-through-iap \ --command "curl -v $BACKEND_IP" Note:
   This command connects to the US instance via SSH and uses `curl` to test the geoblocking policy. A 200 OK response indicates that the request is originating from the US.

   EXPECTED OUTPUT

   GET / HTTP/1.1 Host: 34.144.245.10 User-Agent: curl/7.88.1 Accept: */* HTTP/1.1 200 OK Date: Wed, 06 Aug 2025 04:02:08 GMT Server: Apache/2.4.62 (Debian) Content-Length: 65 Content-Type: text/html; charset=UTF-8 Via: 1.1 google

6. Test the deny rule from a European GCE instance.

   gcloud compute ssh test-vm-europe \ --zone=europe-west1-b \ --tunnel-through-iap \ --command "curl -v $BACKEND_IP" Note:
   This command connects to the European instance via SSH and uses `curl` to test the geoblocking policy. A 403 Forbidden error is expected.

   EXPECTED OUTPUT

   GET / HTTP/1.1 Host: 34.144.245.10 User-Agent: curl/7.88.1 Accept: */* HTTP/1.1 403 Forbidden Content-Length: 134 Content-Type: text/html; charset=UTF-8 Date: Wed, 06 Aug 2025 04:02:36 GMT

Congratulations!

You've successfully configured Cloud Armor to implement geoblocking. You learned how to create and apply security policies and define rules based on geographic origin. This lab provides a foundation for securing your Google Cloud applications with Cloud Armor.

Additional Resources

• Cloud Armor Documentation
• Cloud Armor Security Policies

Manual Last Updated Aug 06, 2025

Lab Last Tested Aug 06, 2025