VPC Service Controls Basic Tutorial I

1. Introduction

VPC Service Controls (VPC-SC) is an organization level security control in Google Cloud that enables enterprise customers to mitigate data exfiltration risks. VPC Service Controls delivers zero-trust style access to multi-tenant services by enabling clients to restrict access to authorized IPs, client context, and device parameters while connecting to multi-tenant services from the internet and other services in order to reduce both intentional and unintentional losses. You can use VPC Service Controls to create perimeters that protect the resources and data of services that you explicitly specify.

The goals of this tutorial are:

• Understand the basics of VPC Service Controls
• Create a VPC service perimeter
• Protect a project with VPC Service Controls
• Troubleshoot a VPC Service Controls ingress violation

2. Setup and requirements

For this tutorial, we need the following pre-requirements:

• A GCP Organization.
• A folder under the Organization.
• 2 GCP projects within the same Organization placed under the folder.
• The required permissions at organization level.
• Billing account for both projects.

Resources setup

1. In the Google Cloud Console, create a folder under the Organization and two new projects.(you can reuse existing ones).

(If you don't already have a Google Workspace/Cloud Identity account, you must acquire one as you will need to have an Organization for this tutorial).

2. Verify you have the correct permissions for this tutorial at organizational level.

• IAM roles for folders
• Permissions and roles for the projects
• Permissions and roles required to configure VPC Service Controls
• Permissions and roles required to manage Compute Engine

You can grant yourself Owner, Folder Admin and Project Creator predefined roles at Organization level and you will have the required roles to set up the resources needed for this tutorial.

NOTE: Granting these roles violates the principle of least privilege. These roles can be used for the Codelab purpose but are not recommended to be used in production setup.

3. Ensure that both projects are available under the folder as we need to create a scoped policy at the folder level. Learn about moving a project into a folder.

Cost

You need to enable billing in the Cloud Console to use Cloud resources/APIs. Running through this codelab won't cost much, if anything at all. To shut down resources to avoid incurring billing beyond this tutorial, you can delete the resources you created or delete the project. New Google Cloud users are eligible for the $300 USD Free Trial program.

The only resource that will generate a cost is the VM Instance. An estimated cost can be found in the pricing calculator.

3. Create a Perimeter

In this laboratory we are going to perform the following steps:

1. In the Google Console, select your Organization and Access VPC Service Controls. Please ensure you are at the organization level.

2. Click "Manage Policies" to create a new access policy that is scoped to the "Codelab" folder.

3. Create a New Perimeter in enforced mode. Let's name it "SuperProtection" for this tutorial.

• When you create the perimeter, select the project to be enforced as ProjectZ.
• Select the perimeter type as "Regular".
• In the Specify services to restrict dialog, select the service to restrict as "Compute Engine".

The perimeter setup should look like this:

4. Verify that the perimeter has been enforced

1. Access ProjectX and verify if you are able to access Compute Engine API by visiting VM Instances home page. You should be able to do so because projectX is not protected by the created VPC SC perimeter.
2. Access ProjectZ and verify if you are able to access Compute Engine. You can see that the request has been prohibited by VPC Service Controls because the service perimeter SuperProtection protects the ProjectZ and Compute Engine API.

5. Troubleshooting the denial

First we have to identify what exactly is the problem here to determine how to troubleshoot it.

1. VPC Service Controls logs include details about requests to protected resources and the reason why VPC Service Controls denied the request. Let's find the VPC Service Controls Unique ID in the ProjectZ audit logs by using the following query in Logs Explorer:

resource.type="audited_resource"
protoPayload.metadata."@type"="type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata"

This will show all VPC Service Controls audit logs. We will be looking for the last error log.

You can use this sample queries to filter more granularly by adding the VPC Service Control unique ID we got while verifying the perimeter was enforced.

2. Click in the VPC Service Controls header, and select "Troubleshoot denial" which will open VPC Service Controls Troubleshooter.

This API will show us in a friendly UI the violation reason, and if this was an ingress or egress violation among other useful things.

For this exercise we will be looking for the following:

"principalEmail": "user@domain"
"callerIp": "PUBLIC_IP_ADDRESS"
"serviceName": "compute.googleapis.com"
"servicePerimeterName":
"accessPolicies/[POLICY_NUMBER]/servicePerimeters/SuperProtection
"ingressViolations": [
        {
"targetResource": "projects/[PROJECT_NUMBER]",
"servicePerimeter": "accessPolicies/[POLICY_NUMBER]/servicePerimeters/SuperProtection"
        }
      ],
"violationReason": "NO_MATCHING_ACCESS_LEVEL",
"resourceNames": "[PROJECT_ID]"

" NO_MATCHING_ACCESS_LEVEL" violation happens when the IP address, device requirement, or user identity doesn't match any ingress rules or access levels assigned to the perimeter. If the caller IP address is missing or appears as an internal IP address, then this violation might be due to a Google Cloud service that is not integrated with VPC Service Controls. Save this page to learn more about VPC Service Controls common issues.

We have two options to fix this denial in ProjectZ.

• Creating an access level to allow access to the project inside the perimeter by granting access to my system IP.
• Creating an ingress rule to allow access by an API client from outside the service perimeter to resources within a service perimeter.

In this tutorial we will troubleshoot by creating an Access Level.

1. Go to Access Context Manager at Folder (Codelab) scope, and create a new access level.
2. Use the "Basic Mode" and we will be allowing access when the IP subnetwork and Geographic location is met.

In the following lab, we used the system public IP address and its location. You need to change these values accordingly. You can check your system IP address in whatismyip.com

3. Go to VPC Service Controls at Organization scope. Select your access policy for this Codelab and edit the perimeter we previously created.
4. Add the access level created at folder scope and save.

6. Test results.

Confirm we have access to Compute Engine and are able to create a VM instance. Now that we have created the Access Level, let's try to access the Compute Engine in ProjectZ and create a VM instance.

1. Go to Compute Engine and click Create Instance

2. Leave everything as default and try to create a low-cost VM instance.

After about a minute, you should see the VM instance created and you can verify that you have full access to the Compute Engine protected inside the perimeter.

7. Cleanup

While there is no separate charge for using VPC Service Controls when the service is not in use, it's a best practice to clean up the setup used in this laboratory. You can also delete your VM instance and/or Cloud projects to avoid incurring charges. Deleting your Cloud project stops billing for all the resources used within that project.

These resources will be used in the next laboratory. You can delete them now and recreate them later, or you can skip the cleanup section and continue with the next lab.

1. To delete your VM instance, select the checkbox on the left side of your VM instance name, and then click Delete.

2. To delete the perimeter, complete the following steps:

• In the Google Cloud console, click Security, and then click VPC Service Controls at the Organization scope.
• In the VPC Service Controls page, in the table row corresponding to the perimeter that you want to delete, click "Delete Icon"

3. To delete the Access Level, complete the following steps:

• in the Google Cloud console, Open the Access Context Manager page at the Folder scope.
• In the grid, in the row for the access level that you want to delete, click "Delete Icon", and then click Delete.

4. To shutdown your Projects, complete the following steps:

• In the Google Cloud console, go to the IAM & Admin Settings page of the project you want to delete.
• On the IAM & Admin Settings page, click Shutdown.
• Enter the project ID, and click Shutdown anyway.

8. Congratulations!

In this codelab you created a VPC Service Controls perimeter, enforced it, and troubleshooted it.

Learn more

• See the VPC Service Controls documentation.
• See the Access Context Manager documentation.
• See the VPC-SC troubleshooter documentation.

License

This work is licensed under a Creative Commons Attribution 2.0 Generic License.