gcp VPC Service Controls - ghdrako/doc_snipets GitHub Wiki

VPC-SC

VPC Service Controls improves your ability to mitigate the risk of data exfiltration from Google Cloud services such as Cloud Storage and BigQuery. You can use VPC Service Controls to create perimeters that protect the resources and data of services that you explicitly specify.

VPC Service Controls secures your Google Cloud services by defining the following controls:

Clients within a perimeter that have private access to resources do not have access to unauthorized (potentially public) resources outside the perimeter.
Data cannot be copied to unauthorized resources outside the perimeter using service operations such as gsutil cp or bq mk.
Data exchange between clients and resources separated by perimeters is secured by using ingress and egress rules.
Context-aware access to resources is based on client attributes, such as identity type (service account or user), identity, device data, and network origin (IP address or VPC network). The following are examples of context-aware access:
Clients outside the perimeter that are on Google Cloud or on-premises are within authorized VPC networks and use Private Google Access to access resources within a perimeter.

service perimeter

A service perimeter around Google-managed resources. Allows free communication within the perimeter but, by default, blocks all communication across the perimeter.

VPC-SC Bridges can be created to let communication between different perimeters as needed.

dry-run mode

A VPC-SC perimeter can be created in “dry-run” mode before being enforced. This feature will log the violations for the perimeter in Cloud Logging, but it will not effectively block those API request. The logs can be extracted into a BigQuery table to be better queried and analyzed. The article I mentioned before describes how to do that.

Be careful to review the list of products supported by VPC-SC and their limitations.

Checking logs across projects can be challenging. My suggestion would be to create a log export sync to Bigquery at folder or organization level. You can create one with the following gcloud command:

gcloud beta logging sinks create SINK_NAME\
bigquery.googleapis.com/projects/PROJECT_ID/datasets/DATASET_NAME \
 - folder=FOLDER_ID \
 - include-children \
 - log-filter='protoPayload.metadata.[@type](http://twitter.com/type):"type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata"' \
 - use-partitioned-tables

You can create a Data Studio dataset with the following query:

SELECT
   *,
    CASE
      WHEN REGEXP_CONTAINS(protopayload_auditlog.status.message,'(Dry Run Mode)*') THEN 'Dry Run'
      ELSE 'Enforced'
    END enforced_type,
    CASE
      WHEN REGEXP_CONTAINS(protopayload_auditlog.requestMetadata.callerIp, r"(^127\.)|(^10\.)|(^172\.1[6-9]\.)|(^172\.2[0-9]\.)|(^172\.3[0-1]\.)|(^192\.168\.)") OR protopayload_auditlog.requestMetadata.callerIp = 'private' THEN 1
      ELSE 0
    END internal_ip,
    REGEXP_EXTRACT(protopayload_auditlog.metadataJson, r'servicePerimeterName":"[a-zA-Z]+\/[\d]+\/[a-zA-Z]+\/([a-zA-Z]+)') as perimeter,
    REGEXP_EXTRACT(protopayload_auditlog.metadataJson, r'violationReason":"([a-zA-Z_]+)') as violation_reason,    
FROM 
  `PROJECT_ID.DATASET_NAME.cloudaudit_googleapis_com_policy`

Some Google Cloud services are not supported while others might have limitations when used in a VPC-SC context.

An example is Cloud Build which works well with VPC-SC only when private pools are used. The reason is that by default Cloud Build uses Google compute resources (outside of the customer’s perimeters) to run the build steps, while with private pools the customer dedicates private compute resources (inside of a VPC-SC perimeter) to run their builds.

Manage exceptions with Access Levels, Ingress/Egress policies and VPC-SC Bridges

When you need to allow communication between protected services in different GCP projects that belong to different VPC-SC perimeters you can simply create a VPC-SC perimeter bridge containing those projects.

When, instead, the source or destination of the communication is outside any VPC-SC perimeter (e.g. Internet, on-prem, a GCP project not in a perimeter) then ingress/egress policies can be used (ingress/egress policies could also be used instead of VPC-SC bridges for a better control).

Incoming requests (from outside to the perimeter) are covered by ingress policies. They allow us to specify the type of source and identity we want to allow on which destination project and service.

In the same way Egress policies are reserved for requests leaving the perimeter and also allow us to specify the identities who can make requests to services outside of the perimeter as well as the destination projects and services.

I want to remark that these are exceptions and they shouldn’t become the rule. If you’re having too many of them you should probably step back for a moment and re-think the design of your perimeters. Shared VPCs

Sharing a VPC of a host project to one or more service projects is a popular way to separate responsibility between the team that manages the network and those teams taking care of the different application projects.

The virtual machines (or other compute services) running in this setup will present a behavior that might confuse some people.

The point is that, even if a VM belongs to the service project, it effectively uses the VPC network shared by the host project. For this reason if the host project and the service project are in different perimeters the VM will have access only to the protected services of the host project’s perimeter (and can’t access protected resources inside its own project).

To get around these limitations we can use one of the following approaches:

Put the service projects and host projects in the same perimeter
Create bridges only for those cross-perimeter communications that should be allowed
Use [Private Service Connect endpoints to access Google APIs](https://cloud.google.com/vpc/docs/configure-private-service-connect-apis) (see next section)
Configure ingress/egress policies on the perimeters for specific identities, projects and services.

Use Private Service Connect endpoints for Google APIs to access resources inside the perimeters from the outside (even from on-prem)

Private Service Connect endpoints can be created inside a VPC of a project protected by a VPC-SC perimeter to give access to the Google APIs.

We can leverage these endpoints by using DNS and routes to let them resolve the requests to the Google APIs.

The interesting part is that when an API request resolves via one of these endpoints it will grant access to the protected services of the perimeter containing that endpoint, even when the request comes from a project in a different perimeter or from on-prem.

If you’re interested in the details of this procedure you can read my other article where I leveraged the same concept to invoke a private Cloud Function from on-prem: Calling a private Google Cloud Function from on-prem. Conclusions