Ingress and egress rules

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

Theingressandegressrule blocks specify the direction of allowed access to and from differentidentities and resources. Ingress and egress rules can replace and simplify usecases that previously required one or moreperimeter bridges.

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

You can configureidentity groups and third-partyidentities andIAM roles(Preview) in ingress and egress rules.

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

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

Benefits of ingress and egress rules

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

Definition of ingress and egress

The definitions of ingress and egress are independent of the operation beinginvoked on the resource. Thus, the definitions refer to the direction of therequest and not to the direction of data movement.

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

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

    • A Compute Engine client within a service perimeter calling aCompute Enginecreate operation where the image resource is outside theperimeter.
    • A Cloud Storage client – within or outside the perimeter – that calls acopy command where one bucket is within the perimeter and the other bucketis outside it.
Note: VPC Service Controls allows access to a few Google-managed resources regardlessof any restrictions enforced by ingress or egress policies. For example, Container Registrycan access the read-only Google-managedgcr.io/cloud-dataflow repository irrespectiveof any restrictions enforced by the service perimeter.

Policy model

An ingress or egress rule consists offrom andto 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. AGoogle Cloud service call is allowed or denied based on the followingsemantics:

  • A request from a client outside the perimeter to a Google Cloud resourcewithin the perimeter is allowed if the conditions of the necessary ingressrule are satisfied.
  • A request from a client within the perimeter to a Google Cloud resourceoutside the perimeter is allowed if the conditions of the necessary egressrule are satisfied.
  • An API call that involves a Google Cloud resource within the perimeterand a Google Cloud resource outside the perimeter is allowed if there isan ingress rule that the client satisfies (if the client is not within theperimeter), 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 aCloud Storage bucket inside the perimeter to the local machine (for exampleusing thegcloud storage cp command).
  • A BigQuery client outside the perimeter using a BigQuery jobin a project inside the perimeter to query a BigQuery dataset insidethe perimeter (for example using thebq query command).
  • A Compute Engine VM in a VPC network that is outside the perimeter writes toa Cloud Storage bucket inside the perimeter.

Examples of API requests allowed by egress rules

  • A Cloud Storage client inside the perimeter copying objects between aCloud Storage bucket outside the perimeter and a bucket inside theperimeter (for example using thegcloud storage cp command).
Note: In this example, the same egress rule allows copying Cloud Storageobjects in both directions. Ingress and egress rules are agnostic of the APIrequest semantics and the data movement direction.
  • A BigQuery client inside the perimeter using a BigQuery jobin a project outside the perimeter to query a BigQuery dataset insidethe perimeter (for example using thebq query command).

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

  • A Cloud Storage client outside the perimeter copying objects between aCloud Storage bucket outside the perimeter and a bucket inside theperimeter (for example using thegcloud storage cp command).
  • A BigQuery client outside the perimeter using a BigQuery jobin a project outside the perimeter to query a BigQuery dataset insidethe perimeter (for example using thebq query command).
  • A Compute Engine client outside the perimeter creating a Compute Enginedisk outside the perimeter using a Cloud KMS key inside theperimeter.
Note: In this example, the egress rule must be created in the perimeter thatcontains the project containing the Cloud KMS key. The egress rule mustallow access to thecompute.googleapis.com service and thecompute.v1.ImagesService.Insert method.

In the BigQuery and Compute Engine examples, an ingress rule is notsufficient, because the BigQuery job or the Compute Engine disk isoutside the perimeter. An egress rule is required to allow an API request thatinvolves a Google Cloud resource inside the perimeter (theBigQuery dataset or the Cloud KMS key) and a resource outsidethe perimeter (the BigQuery job or the Compute Enginedisk).

API requests involving multiple service perimeters

When the accessed resources and/or the API client belong to different serviceperimeters, the policies of all the involved perimeters must allow the APIrequest. For example, consider a Cloud Storage client and bucketa within aservice perimeterA and a bucketb within a service perimeterB. In this example, for theCloud Storage client to copy objects from the bucketa to bucketb andfrom the bucketb to bucketa, the following ingress and egress rules are required:

  • an egress rule in perimeterA to allow access to the Cloud Storagebucketb ,
  • an egress rule in perimeterB to allow access to the Cloud Storagebucketa,
  • an ingress rule in perimeterB to allow access for theCloud Storage client that is outside the perimeterB.

Ingress rules reference

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

- ingressFrom:    identityType: ANY_IDENTITY | ANY_USER_ACCOUNT | ANY_SERVICE_ACCOUNT    *OR*    identities:    -PRINCIPAL_IDENTIFIER    sources:    - resource:RESOURCE      *OR*    - accessLevel:ACCESS_LEVEL  ingressTo:    operations:    - serviceName:SERVICE      methodSelectors:      - method:METHOD      *OR*      - permission:PERMISSION    *OR*    roles:    -ROLE_NAME    resources:    - projects/PROJECT  title:TITLE
  • - ingressFrom: - (Required) Starts thefrom block which lists allowedsources and identities outside the perimeter.

  • identityType: - (This attribute or theidentities attribute must be used) Thisattribute defines the types of identities that can be used from the specifiedsources (network origin). Acceptable values:ANY_IDENTITY,ANY_USER_ACCOUNT,ANY_SERVICE_ACCOUNT.ANY_IDENTITY allows requests from allidentities, including unauthenticated requests.ANY_USER_ACCOUNT allows all humanusers, andANY_SERVICE_ACCOUNT allows all service accounts, but bothANY_USER_ACCOUNTandANY_SERVICE_ACCOUNT don't allow unauthenticated requests.

    This attribute doesn't restrict the identities based on organization. Forexample,ANY_SERVICE_ACCOUNT allows a service account from any organization.

  • identities: - (This attribute or theidentityType attribute must be used) This attributestarts a list of service accounts, user accounts, Google groups, or third-partyidentities that can access resources in the perimeter.

  • PRINCIPAL_IDENTIFIER - Specify a user account, a service account,a Google group, or athird-party identityto which you want to provide access to resources in the perimeter. VPC Service Controlssupports only the following identities from theIAMv1 API Principal identifiers:

    • For user accounts and service accounts, use theuser:USER_EMAIL_ADDRESSandserviceAccount:SA_EMAIL_ADDRESS formats respectively.

    • For other identities, use the formats specified inSupported identitygroups.

    For more information about these identities, seePrincipal identifiers forallow policies.

  • sources: - (Required) This attribute refers to a list of network origins.Each value in the list is either an access level or a Google Cloud project.If you set theaccessLevel attribute to"*", the ingress policy allowsaccess from any network origin. If you set this attribute to a Google Cloud project, theingress policy allows access from a VPC network that belongs to the project.

    This value might be removed when the associated project is permanently deleted.However, the removal of this value doesn't cause an error. Always check if this value existswhile troubleshooting any issues.

  • - resource: - (Use this attribute or theaccessLevel attribute)Specifies a project or VPC network from outside the perimeter to which you want to provide access.To specify a project, use the following format:projects/PROJECT_NUMBER.To specify a VPC network, use the following format://compute.googleapis.com/projects/PROJECT_ID/global/networks/NETWORK_NAME.

  • - accessLevel: - (This attribute or theresource attribute must be used) Specifiesthe access level from outside the perimeter to which access is given. If you settheaccessLevel attribute to"*", the ingress policy allows access from any network origin.

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

  • operations: - (This attribute or theroles attribute must be used) Marks the beginning of the list of accessibleservices and actions/methods that a client satisfying thefrom blockconditions is allowed to access.

  • - serviceName: - (Required) This field can be a valid service name or be setto"*" to allow access to all services. For example,bigquery.googleapis.com is a validserviceName. For a list of availableservices, seeSupported products.

  • methodSelectors: - (Required ifserviceName is not"*") The beginningof a list of methods that a client satisfying thefrom block conditions isallowed to access. For a list of restrictable methods and permissions forservices, seeSupported service method restrictions.

    For a list of service methods that VPC Service Controls can't control, seeService method exceptions.

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

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

    When a request to a resource requires multiple permissions, you must specifyall the required permissions under the same operation for the ingress rule towork. For example, if a request to a BigQuery resource requiresthebigquery.jobs.create andbigquery.tables.create permissions, you mustspecify both these permissions under the same operation. Also, if you specifythe permissions multiple times for the same resource by using theGoogle Cloud console, the permissions are not created under the same operation. Toavoid this issue, specify all the permissions at once for the resource.

  • roles: - (This attribute or theoperations attribute must be used) Thisattribute refers to a list of IAM roles that defines the scopeof access for services specified in the rule.

  • ROLE_NAME - Specify a single role or a combination ofroles that include all the permissions required to access the services. Tospecify a role, use the role name formats mentioned inRole components,except the following format:projects/PROJECT_ID/roles/IDENTIFIER.

    For information about the supported services and roles, seeSupported products.

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

  • title: - (Optional) This attribute specifies the title of the ingress rule. Thetitle must be unique within the perimeter and can't exceed 100 characters. Withinthe access policy, the combined length of all rule titles must not exceed 240,000characters.

To make a functional ingress rule, you must specify the following attributes:

  • sources attribute. You must specify anaccessLevel or aresource (Google Cloud project or VPC network),or setaccessLevel attribute to"*".
Note: To allow ingress to resources, VPC Service Controls evaluatessourcesandidentityType attributes as an AND condition and evaluatesaccessLevelandresource attributes of thesources attribute as an OR condition. When anaccessLevel or aresource for a source is set to a specific value instead of"*", VPC Service Controls evaluates bothsources andidentityTypeattributes.
  • identityType oridentities attribute
  • resources attribute
  • serviceName attribute

Once you have finished configuring your ingress policy file, seeUpdating ingress and egress policiesfor instructions on applying your ingress policy file to your service perimeter.

If you configure multiple ingress rules in a service perimeter, VPC Service Controlsallows a request if it satisfies the conditions of any one of the ingress rules.

Egress rules reference

Egress rules can be configuredusing 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    *OR*    roles:    -ROLE_NAME    resources:    - projects/PROJECT    *OR*    externalResources:    -EXTERNAL_RESOURCE_PATH  egressFrom:    identityType: ANY_IDENTITY | ANY_USER_ACCOUNT | ANY_SERVICE_ACCOUNT    *OR*    identities:    -PRINCIPAL_IDENTIFIER    sources:    - resource:RESOURCE      *OR*    - accessLevel:ACCESS_LEVEL    sourceRestriction:RESTRICTION_STATUS  title:TITLE
  • - egressTo: - (Required) Starts theto block which lists allowed serviceoperations on Google Cloud resources in specified projects outside theperimeter.

  • operations: - (This attribute or theroles attribute must be used) Marks the beginning of the list of accessibleservices and actions/methods that a client satisfying thefrom blockconditions is allowed to access.

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

  • methodSelectors: - (Required ifserviceName is not"*") The beginningof a list of methods that a client satisfying thefrom block conditions isallowed to access. For a list of restrictable methods and permissions forservices, seeSupported service method restrictions.

    For a list of service methods that VPC Service Controls can't control, seeService method exceptions.

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

  • - permission: - (This attribute or themethod attribute must be used.) This fieldmust be a valid service permission. The access to the specified resourcesoutside the perimeter are allowed for the operations that require the permission.

    When a request to a resource requires multiple permissions, you must specifyall the required permissions under the same operation for the egress rule towork. For example, if a request to a BigQuery resource requiresthebigquery.jobs.create andbigquery.tables.create permissions, you mustspecify both these permissions under the same operation. Also, if you specifythe permissions multiple times for the same resource by using theGoogle Cloud console, the permissions are not created under the same operation. Toavoid this issue, specify all the permissions at once for the resource.

  • roles: - (This attribute or theoperations attribute must be used) Thisattribute refers to a list of IAM roles that defines the scopeof access for services specified in the rule.

  • ROLE_NAME - Specify a single role or a combination ofroles that include all the permissions required to access the services. Tospecify a role, use the role name formats mentioned inRole components,except the following format:projects/PROJECT_ID/roles/IDENTIFIER.

    For information about the supported services and roles, seeSupported products.

  • resources: - This attribute is a list of Google Cloudresources specified by their projects that clients inside a perimeter canaccess. You can set this field to"*" to allow egress access to anyGoogle Cloud resource.

  • externalResources: - This attribute is used only to specifyBigQuery Omni resources.This attribute is a list of external resources supported by BigQuery Omnithat clients inside a perimeter can access. You can specify only Amazon S3 orAzure Blob Storage resources. For Amazon S3, the supported format iss3://BUCKET_NAME.For Azure Storage, the supported format isazure://myaccount.blob.core.windows.net/CONTAINER_NAME.

  • egressFrom: - (Required) Starts thefrom block that lists allowedsources and identities within the perimeter.

  • identityType: - (This attribute or theidentities attribute must be used.) Thisattribute defines the types of identities that can be used to access thespecified resources outside the perimeter. Acceptable values:ANY_IDENTITY,ANY_USER_ACCOUNT,ANY_SERVICE_ACCOUNT.ANY_IDENTITY allows requests from allidentities, including unauthenticated requests.ANY_USER_ACCOUNT allows all humanusers, andANY_SERVICE_ACCOUNT allows all service accounts, but bothANY_USER_ACCOUNTandANY_SERVICE_ACCOUNT don't allow unauthenticated requests.

    This attribute doesn't restrict the identities based on organization. Forexample,ANY_SERVICE_ACCOUNT allows a service account from any organization.

  • identities: - (This attribute or theidentityType attribute must be used.) Thisattribute starts a list of service accounts, user accounts, Google groups, orthird-party identities that can access the specified resources outside the perimeter.

  • PRINCIPAL_IDENTIFIER - Specify a user account, a service account,a Google group, or athird-party identitythat can access the specified resources outside the perimeter. VPC Service Controlssupports only the following identities from theIAMv1 API Principal identifiers:

    • For user accounts and service accounts, use theuser:USER_EMAIL_ADDRESSandserviceAccount:SA_EMAIL_ADDRESS formats respectively.

    • For other identities, use the formats specified inSupported identitygroups.

    For more information about these identities, seePrincipal identifiers forallow policies.

  • sources: - This attribute specifies a list of network origins. The attributevalue can be a list of projects or access levels. To enforce access restrictions based on the specifiedsources, set thesourceRestriction attribute toSOURCE_RESTRICTION_ENABLED.

    VPC Service Controls evaluatesaccessLevel andresource attributes of thesourcesattribute as an OR condition.

  • - resource: - (Use this attribute or theaccessLevel attribute) Specify one or moreGoogle Cloud resources from the service perimeter that you want to allow toaccess data outside the perimeter. This attribute supports only projects.To specify a project, use the following format:projects/PROJECT_NUMBER.

    You can't use"*" in this attribute to allow all Google Cloud resources.

  • - accessLevel: - (Use this attribute or theresource attribute) Specify one or more access levels that permit resourcesinside the perimeter to access resources outside the perimeter. Ensure that these accesslevels are from the same access policy as the perimeter. If you set theaccessLevelattribute to"*", the egress policy allows access from any network origin.

  • sourceRestriction: - (Required if you use thesources attribute) This attributelets you enforce access restrictions based on the specifiedsources. To enforcethese access restrictions, set thesourceRestriction attribute toSOURCE_RESTRICTION_ENABLED.

    To disable these access restrictions, set thesourceRestriction attribute toSOURCE_RESTRICTION_DISABLED.

    If you don't set any value for thesourceRestriction attribute, VPC Service Controlsignores thesources attribute and enforces no access restrictions.

  • title: - (Optional) This attribute specifies the title of the egress rule. Thetitle must be unique within the perimeter and can't exceed 100 characters. Withinthe access policy, the combined length of all rule titles must not exceed 240,000characters.

Once you have finished configuring your egress policy file, seeUpdating ingress and egress policiesfor instructions on applying your egress policy file to your service perimeter.

If you configure multiple egress rules in a service perimeter, VPC Service Controlsallows a request if it satisfies the conditions of any one of the egress rules.

Using dry-run mode to test ingress/egress policies

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

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

Unsupported features

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

  1. Identifying Google Cloud resources by labels instead of projects.
  2. Not all services support per-method ingress/egress rules. SeeSupported service method restrictions.
  3. ANY_SERVICE_ACCOUNT andANY_USER_ACCOUNT identity types cannot be usedto allow the following operations:
  4. Understand thelimitationsof using identity groups in ingress and egress rules.

Limitations

For information about ingress and egress limits, seeQuotas and limits.

What's next

Except as otherwise noted, the content of this page is licensed under theCreative Commons Attribution 4.0 License, and code samples are licensed under theApache 2.0 License. For details, see theGoogle Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.

Last updated 2026-02-19 UTC.