Ingress and egress rules Stay organized with collections Save and categorize content based on your preferences.
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
- Ingress and egress rules allow you to privately and efficiently exchange datawithin and across organizations using Google Cloud service APIs.
- Ingress and egress rules allow you to grant access to Google Cloudresources in a perimeter based on the context of the API request:
- Constrain identity types or identities that can be used given a sourcenetwork, IP address, or device.
- Constrain Google Cloud APIs and methods that can be accessed giventhe source network, IP address, device, and identity type.
- Minimize exfiltration risk by constraining the exact service, methods,Google Cloud projects, VPC networks, and identities used to execute the data exchange.
- Grant read-only access to external datasets and images that arenotmanaged by you.
- Ensure that clients in less privileged segments do not have access toGoogle Cloud resources in more privileged segments; while allowingaccess in the other direction.
- 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 Engine
createoperation where the image resource is outside theperimeter. - A Cloud Storage client – within or outside the perimeter – that calls a
copycommand where one bucket is within the perimeter and the other bucketis outside it.
- A Compute Engine client within a service perimeter calling aCompute Engine
gcr.io/cloud-dataflow repository irrespectiveof any restrictions enforced by the service perimeter.Policy model
An ingress or egress rule consists offrom andto blocks where:
fromreferences the attributes of the API client.toreferences 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 the
gcloud storage cpcommand). - 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 the
bq querycommand). - 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 the
gcloud storage cpcommand).
- 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 the
bq querycommand).
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 the
gcloud storage cpcommand). - 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 the
bq querycommand). - A Compute Engine client outside the perimeter creating a Compute Enginedisk outside the perimeter using a Cloud KMS key inside theperimeter.
compute.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 perimeter
Ato allow access to the Cloud Storagebucketb, - an egress rule in perimeter
Bto allow access to the Cloud Storagebucketa, - an ingress rule in perimeter
Bto 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 thefromblock which lists allowedsources and identities outside the perimeter.identityType:- (This attribute or theidentitiesattribute 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_IDENTITYallows requests from allidentities, including unauthenticated requests.ANY_USER_ACCOUNTallows all humanusers, andANY_SERVICE_ACCOUNTallows all service accounts, but bothANY_USER_ACCOUNTandANY_SERVICE_ACCOUNTdon't allow unauthenticated requests.This attribute doesn't restrict the identities based on organization. Forexample,
ANY_SERVICE_ACCOUNTallows a service account from any organization.identities:- (This attribute or theidentityTypeattribute 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 theIAMv1API Principal identifiers:For user accounts and service accounts, use the
user:USER_EMAIL_ADDRESSandserviceAccount:SA_EMAIL_ADDRESSformats 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 theaccessLevelattribute 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 theaccessLevelattribute)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 theresourceattribute must be used) Specifiesthe access level from outside the perimeter to which access is given. If you settheaccessLevelattribute to"*", the ingress policy allows access from any network origin.ingressTo:- (Required) Starts thetoblock which lists allowed serviceoperations on specified Google Cloud resources within the perimeter.operations:- (This attribute or therolesattribute must be used) Marks the beginning of the list of accessibleservices and actions/methods that a client satisfying thefromblockconditions 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.comis a validserviceName. For a list of availableservices, seeSupported products.methodSelectors:- (Required ifserviceNameis not"*") The beginningof a list of methods that a client satisfying thefromblock 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 thepermissionattribute 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 themethodattribute 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 requiresthe
bigquery.jobs.createandbigquery.tables.createpermissions, 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 theoperationsattribute 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:
sourcesattribute. You must specify anaccessLevelor aresource(Google Cloud project or VPC network),or setaccessLevelattribute to"*".
sourcesandidentityType 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.identityTypeoridentitiesattributeresourcesattributeserviceNameattribute
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 thetoblock which lists allowed serviceoperations on Google Cloud resources in specified projects outside theperimeter.operations:- (This attribute or therolesattribute must be used) Marks the beginning of the list of accessibleservices and actions/methods that a client satisfying thefromblockconditions 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 ifserviceNameis not"*") The beginningof a list of methods that a client satisfying thefromblock 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 thepermissionattribute 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 themethodattribute 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 requiresthe
bigquery.jobs.createandbigquery.tables.createpermissions, 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 theoperationsattribute 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 thefromblock that lists allowedsources and identities within the perimeter.identityType:- (This attribute or theidentitiesattribute 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_IDENTITYallows requests from allidentities, including unauthenticated requests.ANY_USER_ACCOUNTallows all humanusers, andANY_SERVICE_ACCOUNTallows all service accounts, but bothANY_USER_ACCOUNTandANY_SERVICE_ACCOUNTdon't allow unauthenticated requests.This attribute doesn't restrict the identities based on organization. Forexample,
ANY_SERVICE_ACCOUNTallows a service account from any organization.identities:- (This attribute or theidentityTypeattribute 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 theIAMv1API Principal identifiers:For user accounts and service accounts, use the
user:USER_EMAIL_ADDRESSandserviceAccount:SA_EMAIL_ADDRESSformats 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 thesourceRestrictionattribute toSOURCE_RESTRICTION_ENABLED.VPC Service Controls evaluates
accessLevelandresourceattributes of thesourcesattribute as an OR condition.- resource:- (Use this attribute or theaccessLevelattribute) 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 theresourceattribute) 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 thesourcesattribute) This attributelets you enforce access restrictions based on the specifiedsources. To enforcethese access restrictions, set thesourceRestrictionattribute toSOURCE_RESTRICTION_ENABLED.To disable these access restrictions, set the
sourceRestrictionattribute toSOURCE_RESTRICTION_DISABLED.If you don't set any value for the
sourceRestrictionattribute, VPC Service Controlsignores thesourcesattribute 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:
- Identifying Google Cloud resources by labels instead of projects.
- Not all services support per-method ingress/egress rules. SeeSupported service method restrictions.
ANY_SERVICE_ACCOUNTandANY_USER_ACCOUNTidentity types cannot be usedto allow the following operations:- AllContainer Registry operations.
- Allnotebooks.googleapis.com service operations.
- Cloud Storage operations usingSigned URLs.
- WithCloud Run functions, deployment of a Cloud Function fromthelocal machine.
- Export logs from aCloud Logging sink to aCloud Storage resource.
- AllApache Airflow web interface operations in Cloud Composer.
- Understand thelimitationsof using identity groups in ingress and egress rules.
Limitations
For information about ingress and egress limits, seeQuotas and limits.
What's next
- Complete thiscodelabto learn how to fix ingress and egress violations.
- Learn how toset up and view the violation dashboard.
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.