Secure data exchange ingress/egress setups allow for access to/from clients and resources separated by Service Perimeters. Access is defined by ingress and egress rules.
For an overview of ingress and egress rules, see Ingress and egress rules.
For instructions on how to apply ingress and egress rule policies, see Configuring ingress and egress policies.
Configuration examples of secure data exchange use cases
This section contains the following examples for secure data exchange use cases:
- Allow access to a Google Cloud resource outside the perimeter
- Sharing via Pub/Sub between two organizations where both are using VPC Service Controls
- PHI, anonymized data segment, and partner org
- Third party Compute Engine disk image
- Allow private access from a VPC network outside the perimeter to access a BigQuery dataset
- Allow private access from a VPC network outside the perimeter to load into a Cloud Storage bucket (write)
- Allow projects from multiple perimeters to share logs in a separate perimeter
Allow access to a Google Cloud resource outside the perimeter
Assume that you have defined the following perimeter, found by listing the perimeter with gcloud:
name: accessPolicies/222/servicePerimeters/Example status: resources: - projects/111 restrictedServices: - bigquery.googleapis.com - containerregistry.googleapis.com title: Example
You now wish to grant read access to a Cloud Storage bucket in project 999
(which is in a different org). You would define the following egress rule and
save it as gcs.yaml
:
echo """ - egressTo: operations: - serviceName: storage.googleapis.com methodSelectors: - method: google.storage.objects.get resources: - projects/999 egressFrom: identityType: ANY_IDENTITY """ > gcs.yaml
Apply the egress rule by running the following command:
gcloud beta access-context-manager perimeters update Example --set-egress-policies=gcs.yaml
Sharing via Pub/Sub between two organizations where both are using VPC Service Controls
In this example, two organizations, Org1 and Org2, using VPC Service Controls want to share data via a Pub/Sub topic.
Assume that you have defined the following perimeters, found by listing the perimeters with gcloud:
# Org 1 Perimeter Definition name: accessPolicies/222/servicePerimeters/Example1 status: resources: - projects/111 restrictedServices: - pubsub.googleapis.com title: Example1
# Org 2 Perimeter Definition name: accessPolicies/333/servicePerimeters/Example2 status: resources: - projects/222 restrictedServices: - pubsub.googleapis.com title: Example2
To enable this exchange, Org1 must define an egress rule allowing the subscription.
# Org1: Org1's perimeter must allow a Pub/Sub subscription to project 222. echo """ - egressTo: operations: - serviceName: pubsub.googleapis.com methodSelectors: - method: Subscriber.CreateSubscription resources: - projects/222 egressFrom: identityType: ANY_IDENTITY """ > org1egress.yaml
Org2 must define a corresponding ingress rule allowing the subscription.
# Org 2: Org2's perimeter must allow a Pub/Sub subscription from network project 111 in Org1. echo """ - ingressFrom: identityType: ANY_IDENTITY sources: - resource: projects/111 ingressTo: operations: - serviceName: pubsub.googleapis.com methodSelectors: - method: Subscriber.CreateSubscription """ > org2ingress.yaml
Apply the ingress and egress rules by running the following commands:
gcloud beta access-context-manager perimeters update Example2 1--set-egress-policies=org1egress.yaml
gcloud beta access-context-manager perimeters update Example1 1--set-ingress-policies=org2ingress.yaml
PHI, anonymized data segment, and partner org
In this example, you want to define a perimeter around a Protected Health Information (PHI) data segment and a second perimeter around an anonymized data segment. You want to enable sharing anonymized data with a partner organization while allowing your PHI segment to manipulate the data in the anonymized data segment.
Assume that you have defined the following two perimeters, found by listing the perimeter with gcloud:
# PhiPerimeter name: accessPolicies/222/servicePerimeters/PhiPerimeter status: resources: - projects/111 restrictedServices: - storage.googleapis.com - bigquery.googleapis.com vpcAccessibleServices: enableRestriction: true allowedServices: - RESTRICTED_SERVICES title: PhiPerimeter
# AnonPerimeter name: accessPolicies/222/servicePerimeters/AnonPerimeter status: resources: - projects/222 restrictedServices: - storage.googleapis.com vpcAccessibleServices: enableRestriction: true allowedServices: - RESTRICTED_SERVICES title: AnonPerimeter
We also assume that the partner org project is 999. You would define the following directional policy rules:
# Anon Perimeter echo """ - ingressFrom: identityType: ANY_IDENTITY sources: - resource: projects/111 ingressTo: operations: - serviceName: storage.googleapis.com methodSelectors: - method: google.storage.Write - method: google.storage.objects.create """ > anoningress.yaml
echo """ - egressTo: operations: - serviceName: storage.googleapis.com methodSelectors: - method: google.storage.Write - method: google.storage.objects.create resources: - projects/999 egressFrom: identityType: ANY_IDENTITY """ > anonegress.yaml
# PHI Perimeter echo """ - egressTo: operations: - serviceName: storage.googleapis.com methodSelectors: - method: \"*\" resources: - projects/222 egressFrom: identityType: ANY_IDENTITY """ > phiegress.yaml
Apply the egress rules by running the following commands:
gcloud beta access-context-manager perimeters update AnonPerimeter --set-ingress-policies=anoningress.yaml --set-egress-policies=anonegress.yaml
gcloud beta access-context-manager perimeters update PhiPerimeter --set-egress-policies=phiegress.yaml
Third party Compute Engine disk image
In this example, you want to authorize the use of a Compute Engine disk image in a third party image project that is outside of all perimeters.
Assume that you have defined the following perimeter, found by listing the perimeter with gcloud:
name: accessPolicies/222/servicePerimeters/Example status: resources: - projects/111 - projects/222 restrictedServices: - compute.googleapis.com - containerregistry.googleapis.com title: Example
You now wish to grant read access to disk images in project 999 (which is in a different org). You would define the following egress rule:
echo """ - egressTo: operations: - serviceName: compute.googleapis.com methodSelectors: - method: InstancesService.Insert resources: - projects/999 egressFrom: identityType: ANY_IDENTITY """ > compute.yaml
Apply the egress rule by running the following command:
gcloud beta access-context-manager perimeters update Example --set-egress-policies=compute.yaml
Allow private access from a VPC network outside the perimeter to access a BigQuery dataset
In this example, we assume the same perimeter as example 1:
name: accessPolicies/222/servicePerimeters/Example status: resources: - projects/111 restrictedServices: - bigquery.googleapis.com - containerregistry.googleapis.com title: Example
Now your goal is to allow access from a VPC network outside the perimeter of various partners, which you can accomplish by defining an ingress rule:
echo """ - ingressFrom: identityType: ANY_IDENTITY sources: - resource: projects/888 - resource: projects/999 ingressTo: operations: - serviceName: bigquery.googleapis.com methodSelectors: - method: \"*\" """ > partneringress.yaml
Apply the ingress rule by running the following command:
gcloud beta access-context-manager perimeters update Example --set-ingress-policies=partneringress.yaml
Allow private access from a VPC network outside the perimeter to load into a Cloud Storage bucket (write)
In this example, we assume the same perimeter as example 1:
name: accessPolicies/222/servicePerimeters/Example status: resources: - projects/111 restrictedServices: - storage.googleapis.com - containerregistry.googleapis.com title: Example
Now your goal is to allow access from a VPC network outside the perimeter to enable a partner to load data into the perimeter, which you can accomplish by defining an ingress rule:
echo """ - ingressFrom: identityType: ANY_IDENTITY sources: - resource: projects/222 ingressTo: operations: - serviceName: storage.googleapis.com methodSelectors: - method: google.storage.objects.create """ > partneringress.yaml
Apply the ingress rule by running the following command:
gcloud beta access-context-manager perimeters update Example --set-ingress-policies=partneringress.yaml
Allow projects from multiple perimeters to share logs in a separate perimeter
In this use case, an enterprise has a shared project for collection of logging data from across their Google Cloud deployment. They wish to be able to log data from multiple different VPC Service Controls perimeters into this shared logs project, which is in its own perimeter. They do not want the logs project to be able to access any resources other than the logs themselves.
Assume that you have defined the following three perimeters, found by listing the perimeters with gcloud:
# Sensitive 1 name: accessPolicies/222/servicePerimeters/Sensitive1 status: resources: - projects/111 restrictedServices: - bigquery.googleapis.com - containerregistry.googleapis.com - logging.googleapis.com vpcAccessibleServices: enableRestriction: true allowedServices: - RESTRICTED_SERVICES title: Sensitive Data 1
# Sensitive 2 name: accessPolicies/222/servicePerimeters/Sensitive2 status: resources: - projects/222 restrictedServices: - bigquery.googleapis.com - containerregistry.googleapis.com - logging.googleapis.com vpcAccessibleServices: enableRestriction: true allowedServices: - RESTRICTED_SERVICES title: Sensitive Data 2
#Logs name: accessPolicies/222/servicePerimeters/Logs status: resources: - projects/777 restrictedServices: - logging.googleapis.com vpcAccessibleServices: enableRestriction: true allowedServices: - RESTRICTED_SERVICES title: Logs Perimeter
To allow Sensitive1 and Sensitive2 to write logs to Logs, the following should be used:
echo """ - egressTo: operations: - serviceName: logging.googleapis.com methodsSelectors: - method: LoggingServiceV2.WriteLogEntries - method: LoggingService.WriteLogEntries resources: - projects/999 egressFrom: identityType: ANY_IDENTITY """ > logsegress.yaml
Apply the egress rules by running the following commands:
gcloud beta access-context-manager perimeters update Sensitive1 --set-egress-policies=logsegress.yaml
gcloud beta access-context-manager perimeters update Sensitive2 --set-egress-policies=logsegress.yaml
A similar configuration can be specified for any other sensitive data perimeter that needs to write to the logs perimeter.