Secure data exchange with ingress and egress rules

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:

  1. Allow access to a Google Cloud resource outside the perimeter
  2. Sharing via Pub/Sub between two organizations where both are using VPC Service Controls
  3. PHI, anonymized data segment, and partner org
  4. Third party Compute Engine disk image
  5. Allow private access from a VPC network outside the perimeter to read a BigQuery dataset
  6. Allow private access from a VPC network outside the perimeter to load into a Cloud Storage bucket (write)
  7. Allow projects from multiple perimeters to share logs in a separate perimeter

Allow access to a Google Cloud resource outside the perimeter

Egress from one 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

Egress from one perimeter and ingress to another perimeter

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

Ingress into perimeter and egress out of perimeter

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

Egress to image project

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 read a BigQuery dataset

Egress to image project

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 read 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:
      - permission: bigquery.datasets.get
      - permission: bigquery.tables.list
      - permission: bigquery.tables.get
      - permission: bigquery.tables.getData
      - permission: bigquery.jobs.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

Note that BigQuery uses - permission: methodSelectors rather than the - method: methodSelectors used by most services. This is because a single BigQuery method (RunQuery) can operate in different ways on a number of different resources, and aligning with the permissions model enables more flexibility and control.

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.