Ingress and egress rules

This page explains ingress and egress rules for VPC Service Controls. VPC Service Controls use ingress and egress rules to allow access to and from the resources and clients protected by service perimeters.

The ingress and egress rule blocks specify the direction of allowed access to and from different identities and resources. Ingress and egress rules can replace and simplify use cases that previously required one or more perimeter bridges.

To learn how to apply ingress and egress policies to your service perimeter, see Configuring ingress and egress policies.

For a list of secure data exchange use cases and samples, see Secure data exchange with ingress and egress rules.

For a list of context-aware access use cases and samples, see Context-aware access with ingress rules.

Benefits of ingress and egress rules

  1. Ingress and egress rules allow you to privately and efficiently exchange data within and across organizations using Google Cloud service APIs.
  2. Ingress and egress rules allow you to grant access to Google Cloud resources in a perimeter based on the context of the API request:
    1. Constrain identity types or identities that can be used given a source network, IP address, or device.
    2. Constrain Google Cloud APIs and methods that can be accessed given the source network, IP address, device, and identity type.
  3. Minimize exfiltration risk by constraining the exact service, methods, Google Cloud projects, and identities used to execute the data exchange.
  4. Grant read-only access to external datasets and images that are not managed by you.
  5. Ensure that clients in less privileged segments do not have access to Google Cloud resources in more privileged segments; while allowing access in the other direction.
  6. Simplify configurations which have previously required one or more perimeter bridges.

Definition of ingress and egress

  • Ingress: Refers to any access by an API client from outside the service perimeter to resources within a service perimeter. Example:

    • A Cloud Storage client outside a service perimeter calling Cloud Storage read, write, or copy operations on a Cloud Storage resource within the perimeter.
  • Egress Refers to any access that involves an API client or resources within the service perimeter and resources outside a service perimeter. Examples:

    • A Compute Engine client within a service perimeter calling a Compute Engine create operation where the image resource is outside the perimeter.
    • A Cloud Storage client – within or outside the perimeter – that calls a copy command where one bucket is within the perimeter and the other bucket is outside it.

Policy model

An ingress or egress rule consists of from and to blocks where:

  • from references the attributes of the API client.
  • to references the attributes of Google Cloud services and resources.

Multiple ingress and egress rules can be associated with a service perimeter. A Google Cloud service call is allowed or denied based on the following semantics:

  • A request from a client outside the perimeter to a Google Cloud resource within the perimeter is allowed if the conditions of the necessary ingress rule are satisfied.
  • A request from a client within the perimeter to a Google Cloud resource outside the perimeter is allowed if the conditions of the necessary egress rule are satisfied.
  • An API call that involves a Google Cloud resource within the perimeter and a Google Cloud resource outside the perimeter is allowed if there is an ingress rule that the client satisfies (if the client is not within the perimeter), and an egress rule that the external resource satisfies.

Examples of API requests allowed by ingress rules

  • A Cloud Storage client outside the perimeter downloading objects from a Cloud Storage bucket inside the perimeter to the local machine (for example using the gsutil cp command).
  • A BigQuery client outside the perimeter using a BigQuery job in a project inside the perimeter to query a BigQuery dataset inside the perimeter (for example using the bq query command).

Examples of API requests allowed by egress rules

  • A Cloud Storage client inside the perimeter copying objects between a Cloud Storage bucket outside the perimeter and a bucket inside the perimeter (for example using the gsutil cp command).
  • A BigQuery client inside the perimeter using a BigQuery job in a project outside the perimeter to query a BigQuery dataset inside the perimeter (for example using the bq query command).

Examples of API requests allowed by combination of ingress and egress rules

  • A Cloud Storage client outside the perimeter copying objects between a Cloud Storage bucket outside the perimeter and a bucket inside the perimeter (for example using the gsutil cp command).
  • A BigQuery client outside the perimeter using a BigQuery job in a project outside the perimeter to query a BigQuery dataset inside the perimeter (for example using the bq query command).

API requests involving multiple service perimeters

When the accessed resources and/or the API client belong to different service perimeters, the policies of all the involved perimeters must allow the API request. Example:

  • To allow a Cloud Storage client inside perimeter A to copy objects between a Cloud Storage bucket a inside perimeter A and a Cloud Storage bucket b inside perimeter B, the following ingress/egress rules are required:

    • an egress rule in perimeter A to allow the access to Cloud Storage bucket b ,
    • an egress rule in perimeter B to allow the access to Cloud Storage bucket a,
    • an ingress rule in perimeter B to allow the access for the Cloud Storage client that is outside the perimeter B.

Ingress rules reference

Ingress rules can be configured using the Google Cloud Console, a JSON file, or a YAML file. The following sample uses the .yaml format:

- ingressFrom:
    identityType: ANY_IDENTITY
    *OR*
    identities:
    - serviceAccount:service-account
    sources:
    - resource: projects/project
      *OR*
    - accessLevel: access-level
  ingressTo:
    operations:
    - serviceName: service
      methodSelectors:
      - method: method
      *OR*
      - permission: permission
    resources:
    - projects/project
Attribute reference
  • - ingressFrom: - (Required) Starts the from block which lists allowed sources and identities outside the perimeter.

  • identityType: - (This attribute or the identities attribute must be used) This attribute defines the types of identities that can be used from the specified sources (network origin). Acceptable values: ANY_IDENTITY, ANY_USER_ACCOUNT, ANY_SERVICE_ACCOUNT. ANY_IDENTITY allows all identities. ANY_USER_ACCOUNT allows all human users. ANY_SERVICE_ACCOUNT allows all service accounts.

  • identities: - (This attribute or the identityType attribute must be used) This attribute starts a list of service accounts that can access resources in the perimeter.

  • serviceAccount - A service account to which access to resources in the perimeter is given.

  • sources: - (Required) This attribute refers to a list of network origins. Each value in the list is either an Access Level or a VPC network project.

  • - resource: - (This attribute or the accessLevel attribute must be used) Specifies the project from outside the perimeter to which access is given. Access is given to the project's VPC network.

  • - accessLevel: - (This attribute or the resource attribute must be used) Specifies the access level from outside the perimeter to which access is given.

  • ingressTo: - (Required) Starts the to block which lists allowed service operations on specified Google Cloud resources within the perimeter.

  • operations: - (Required) Marks the beginning of the list of accessible services and actions/methods that a client satisfying the from block conditions is allowed to access.

  • - serviceName: - (Required) This field can be a valid service name or be set to \"*\" to allow access to all services. For example, bigquery.googleapis.com is a valid serviceName. For a list of available services, see Supported products.

  • methodSelectors: - (Required) The beginning of a list of methods that a client satisfying the from block conditions is allowed to access. For a list of restrictable methods and permissions for services, see Supported service method restrictions.

  • - method: - (This attribute or the permission attribute must be used) This field can be a valid service method, or can be set to \"*\" to allow access to all methods of the specified service.

  • - permission: - (This attribute or the method attribute must be used) This field must be a valid service permission. The access to the resources inside the perimeter are allowed for the operations that require the permission.

  • resources: - (Required) This attribute specifies the list of Google Cloud resources in the Service Perimeter that the client outside the perimeter can access. This field can be set to \"*\" to allow ingress access to any Google Cloud resource inside the perimeter.

Once you have finished configuring your ingress policy file, see Updating ingress and egress policies for instructions on applying your ingress policy file to your service perimeter.

Egress rules reference

Egress rules can be configured using the Google Cloud Console, a JSON file, or a YAML file. The following sample uses the .yaml format:

- egressTo:
    operations:
    - serviceName:service-name
      methodSelectors:
      - method: method
      *OR*
      - permission: permission
    resources:
    - projects/project
  egressFrom:
    identityType: ANY_IDENTITY
    *OR*
    identities:
    - serviceAccount:service-account
  • - egressTo: - (Required) Starts the to block which lists allowed service operations on Google Cloud resources in specified projects outside the perimeter.

  • operations: - (Required) Marks the beginning of the list of accessible services and actions/methods that a client satisfying the from block conditions is allowed to access.

  • - serviceName: - (Required) This field can be a valid service name or be set to \"*\" to allow access to all services. For a list of available services, see Supported products.

  • methodSelectors: - (Required) The beginning of a list of methods that a client satisfying the from block conditions is allowed to access. For a list of restrictable methods and permissions for services, see Supported service method restrictions.

  • - method: - (This attribute or the permission attribute must be used). This field can be a valid service method, or can be set to \"*\" to allow access to all methods of the specified service.

  • - permission: - (This attribute or the method attribute must be used) This field must be a valid service permission. The access to the specified resources outside the perimeter are allowed for the operations that require the this permission.

  • resources: - (Required) This attribute is a list of Google Cloud resources specified by their projects that clients inside a perimeter can access. This field can be set to \"*\" to allow egress access to any Google Cloud resource.

  • egressFrom: - (Required) Starts the from block which lists allowed service operations on Google Cloud resources in specified projects within the perimeter.

  • identityType: - (This attribute or the identities attribute must be used) This attribute defines the types of identities that can be used to access the specified resources outside the perimeter. Acceptable values: ANY_IDENTITY, ANY_USER_ACCOUNT, ANY_SERVICE_ACCOUNT. ANY_IDENTITY allows all identities. ANY_USER_ACCOUNT allows all human users. ANY_SERVICE_ACCOUNT allows all service accounts.

  • identities: - (This attribute or the identityType attribute must be used) This attribute starts a list of service accounts that can access the specified resources outside the perimeter.

  • serviceAccount - A service account that can access the specified resources outside the perimeter.

Once you have finished configuring your egress policy file, see Updating ingress and egress policies for instructions on applying your egress policy file to your service perimeter.

Using dry-run mode to test ingress/egress policies

When you don't want to grant access to all methods of a service, it can sometimes be difficult to determine the precise list of methods to allow. This can occur because a given method for a service can cause a different method to be invoked on a separate Google Cloud service. For example, BigQuery loading a table from a Cloud Storage bucket to run a query.

To determine the correct set of methods to allow, you can use the VPC Service Controls Dry-run mode. Do this by first enabling a perimeter in dry-run mode with no ingress or egress policies, and collect the list of methods invoked from the audit log. Then, progressively add these methods to ingress/egress policies in the dry-run mode until all violations have ceased. At that point, the configuration can be moved from dry-run mode to enforced mode.

Limitations

These are the limits when using ingress and egress rules:

Limit per service perimeter Limit per access policy
Ingress policies 100 10,000
Egress policies 100 10,000
Ingress source1 30 500
Total number of attributes in ingress or egress rules such as projects, access levels, method selectors, or identities. 2000
Identities 2000
API Operations proto messages 1000 ApiOperation proto messages can be specified inside one AccessPolicy proto message

1 The Access Level references in sources count towards the total number of Access Level references defined in service perimeters. Resources in sources count towards the total number of service perimeters allowed in Access Policy.

Unsupported features

The following features are currently unsupported for ingress and egress rules:

  1. Identifying Google Cloud resources by labels instead of projects.
  2. Specifying groups in the identities field of an ingress/egress from rule.
  3. Not all services support per-method ingress/egress rules. See Supported service method restrictions.
  4. ANY_SERVICE_ACCOUNT and ANY_USER_ACCOUNT identity types cannot be used to allow the following operations: