This tutorial shows you how to protect Compute Engine using a service perimeter and troubleshoot an ingress violation to allow authorized access to Compute Engine.
VPC Service Controls enables you to define a service perimeter around resources of Google-managed services to control communication to and between those services. You can establish a zero-trust perimeter around your sensitive resources, restricting access to authorized IP addresses, users, and devices. This capability lets you define security policies that prevent access to Google-managed services outside of a trusted perimeter, block access to data from untrusted locations, and mitigate data exfiltration risks.
This tutorial is intended for Google Cloud organization administrators who want to learn the basic VPC Service Controls concepts.
Objectives
- Understand the basics of VPC Service Controls.
- Create a service perimeter.
- Protect a project using VPC Service Controls.
- Troubleshoot a VPC Service Controls ingress violation.
Costs
In this document, you use the following billable components of Google Cloud:
To generate a cost estimate based on your projected usage,
use the pricing calculator.
When you finish the tasks that are described in this document, you can avoid continued billing by deleting the resources that you created. For more information, see Clean up.
Before you begin
You need to have a Google Cloud organization resource. If you don't have a Google Workspace or Cloud Identity account already, you must acquire one and that creates an organization resource automatically for you.
Create a folder,
Exercise
, at the organization level.Create two projects,
My-Project-1
andMy-Project-2
, in theExercise
folder within the same organization.Make sure that you have the following permissions and roles at the organization level:
Permissions and roles required to configure VPC Service Controls.
Permissions and roles required to manage Compute Engine.
Create a service perimeter
Create a service perimeter that protects the Compute Engine API in the
My-Project-2
project:
In the Google Cloud console, go to the VPC Service Controls page.
Make sure that you are in the organization scope.
Click Manage policies.
Create a new access policy that is scoped to the
Exercise
folder.Create a new perimeter with the following details:
Title:
MyFirstPerimeter
Perimeter type: Regular
Enforcement mode: Enforced
Resources to protect:
My-Project-2
projectRestricted services: Compute Engine API
Verify the perimeter
In this section, you can make access requests to the resources in the projects to confirm whether the perimeter protects the intended resources.
Access the
My-Project-1
project and verify that you can access Compute Engine by visiting VM instances page.You should be able to access because
My-Project-1
is not protected by the perimeter that you created earlier.Access the
My-Project-2
project and verify that you can access Compute Engine by visiting VM instances page.You should see that VPC Service Controls denies your request to access Compute Engine because the
MyFirstPerimeter
perimeter protectsMy-Project-2
and the Compute Engine API.
Troubleshoot a violation
VPC Service Controls audit logs
include details about requests to protected resources and the reason why
VPC Service Controls denied the request. You need this information to identify and
troubleshoot the violation in the My-Project-2
project.
View audit logs
Find the unique ID of the VPC Service Controls violation in the
My-Project-2
project's audit logs:-
In the Google Cloud console, go to the Logs Explorer page:
If you use the search bar to find this page, then select the result whose subheading is Logging.
Select the
My-Project-2
project.To display all audit logs, enter the following query into the query-editor field:
resource.type="audited_resource" protoPayload.metadata."@type"="type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata"
Click Run query.
This query displays all VPC Service Controls audit logs. To find the violation details for accessing the Compute Engine API in the
My-Project-2
project, check the last error log.For more information, see View logs.
-
In the Query results pane, click VPC Service Controls next to the denial that you want to troubleshoot, and then click Troubleshoot denial.
The VPC Service Controls troubleshooter page opens. This page shows the violation reason and other information such as if the violation is an ingress or egress violation.
In this tutorial, look for the following information:
"principalEmail": "USER@DOMAIN" "callerIp": "PUBLIC_IP_ADDRESS" "serviceName": "compute.googleapis.com" "servicePerimeterName": "accessPolicies/POLICY_NUMBER/servicePerimeters/MyFirstPerimeter "ingressViolations": [ { "targetResource": "projects/PROJECT_NUMBER", "servicePerimeter": "accessPolicies/POLICY_NUMBER/servicePerimeters/MyFirstPerimeter" } ], "violationReason": "NO_MATCHING_ACCESS_LEVEL", "resourceNames": "PROJECT_ID"
The violation reason is
"NO_MATCHING_ACCESS_LEVEL"
. The"NO_MATCHING_ACCESS_LEVEL"
violation occurs when the IP address, device type, or user identity doesn't match any ingress rules or access levels that are associated with the perimeter. If the caller IP address is missing or appears as an internal IP address in the log, then this violation can be due to a Google Cloud service that is not supported by VPC Service Controls.
To fix this denial in the My-Project-2
project, you have two options:
Create an access level that allows access to your system IP address to the project inside the perimeter.
Create an ingress rule that allows access to an API client from outside the perimeter to resources within the perimeter.
The following section illustrates how to troubleshoot this denial by creating an access level.
Create an access level
In the Google Cloud console, go to the Access Context Manager page at the
Exercise
folder scope.Create an access level with the following details:
For Create conditions in, select Basic mode.
For When condition is met, return, select True.
Select the IP Subnetworks attribute, specify your system's public IP address.
Select the Geographic locations attribute, specify your geographic location.
This access level allows access only when the IP address and the geographic location is matched.
Go to the VPC Service Controls page at the organization scope.
Select the access policy that you created earlier in this tutorial.
Add the access level that you created at the
Exercise
folder scope to theMyFirstPerimeter
perimeter.
Test the access
After you add the access level, verify that you can access Compute Engine
in the My-Project-2
project and create a VM instance.
In the Google Cloud console, go to the VM instances page.
After about a minute, Compute Engine creates a VM instance and this action verifies that you have full access to Compute Engine protected inside the perimeter.
Clean up
To avoid incurring charges to your Google Cloud account for the resources used in this tutorial, either delete the project that contains the resources, or keep the project and delete the individual resources.
Delete the project
- In the Google Cloud console, go to the Manage resources page.
- In the project list, select the project that you want to delete, and then click Delete.
- In the dialog, type the project ID, and then click Shut down to delete the project.
Delete individual resources
Delete VM instances
- In the Google Cloud console, go to the VM instances page.
- Select the checkbox for the instance that you want to delete.
- To delete the instance, click More actions, click Delete, and then follow the instructions.
Delete VPC Service Controls resources
Delete the access level that you created at the
Exercise
folder scope.