Principal access boundary (PAB) policies let you define the resources thatprincipals can access.

For example, you can use principal access boundary policies to prevent your principalsfrom accessing resources in other organizations, which can help prevent phishingattacks or data exfiltration.

To learn about the other types of access control policies thatIdentity and Access Management (IAM) offers, seePolicy types.

How principal access boundary policies work

By default, principals are eligible to access any Google Cloud resource. Thismeans that if a principal has a permission on the resource and isn't deniedthat permission, then they can use that permission to access the resource.

With principal access boundary policies, you can define the resources that aprincipal is eligible to access. If a principal access boundary policy makes aprincipal ineligible to access a resource, then their access to thatresource is limited, regardless of the roles they've been granted.

When principals try to access resources that they aren't eligible toaccess, principal access boundary policies can block some, but not all,Identity and Access Management (IAM) permissions. To learn more about whichpermissions are blocked, seePermissions that principal access boundary canblock.

Principal access boundary policies are made up ofprincipal access boundaryrules. Each principal access boundary rule defines a set ofresources that the affected principals are eligible to access. You can create upto1000 principal access boundary policies in your organization.

After you create a principal access boundary policy, you create apolicybinding to apply the policy to a set of principals.

A principal can be subject to one or more principal access boundary policies. Each principalis only eligible to access the resources listed in those policies. For all otherresources, the principal's access to that resource is limited, even if you grantroles to the principal on that resource.

Because principal access boundary policies are associated with principals and not withresources, you can use them to prevent principals from accessing resources thatyou don't own. For example, consider the following scenario:

• The principal Tal (tal@example.com) is part of theGoogle Workspace organizationexample.com.
• Tal is granted the Storage Admin (roles/storage.admin) role on aCloud Storage bucket in a different organization,cymbalgroup.com. Thisrole contains thestorage.objects.get permission, which is required toview objects in the bucket.
• There are no deny policies incymbalgroup.com that prevent Tal fromusing thestorage.objects.get permission.

With just allow and deny policies,example.com can't prevent Tal fromviewing objects in this external bucket. Noexample.com principals havepermission to edit the bucket's allow policy, so they can't revoke Tal'srole. They also don't have permission to create any deny policies incymbalgroup.com, so they can't use a deny policy to prevent Tal from accessingthe bucket.

However, with principal access boundary policies,example.com administrators canensure that Tal can't view objects in thecymbalgroup.com bucket, or anybucket outside ofexample.com. To do this, the administrators can create aprincipal access boundary policy saying thatexample.com principals are onlyeligible to access resources inexample.com. Then, they can create a policybinding to attach this policy to all principals in the organizationexample.com. With such a policy in place, Tal won't be able to view objectsin thecymbalgroup.com bucket, even though they're granted the Storage Adminrole on the bucket.

Fail-closed evaluation

Principal access boundary policies fail closed. This means that, ifIAM can't evaluate a principal access boundary policy whenevaluating aprincipal's access, then IAM prevents theprincipal from accessing the resource.

The most common reason that IAM isn't able to evaluateprincipal access boundary policies is that a principal's details are still propagatingthrough the system. This is most likely to occur for newly created users. Toresolve this issue, have the new principal wait and try to access the resourceagain later.

Permissions that principal access boundary policies block

When principals try to access a resource that they aren't eligible to access,principal access boundary policies prevent them from using some, but not all,Identity and Access Management (IAM) permissions to access the resource.

If a principal access boundary policy blocks a permission, then IAMenforces principal access boundary policies for that permission. In other words, itprevents any principals that aren't eligible to access a resource from usingthat permission to access the resource.

If a principal access boundary policy doesn't block a permission, thenprincipal access boundary policies have no effect on whether principals can use thepermission.

For example, imagine that a principal, Lee (lee@example.com), is granted theDataflow Developer role (roles/dataflow.developer). This role includes thedataflow.jobs.snapshot permission, which lets Lee take snapshots ofDataflow jobs. Lee is also subject to a principal access boundary policy thatmakes them ineligible to access resources outside ofexample.com. However, ifprincipal access boundary policies don't block thedataflow.jobs.snapshotpermission, then Lee can still take snapshots of Dataflow jobs inorganizations outside ofexample.com.

The permissions that a principal access boundary policy blocks depends on theprincipal access boundary enforcement version.

Principal access boundary enforcement versions

Each principal access boundary policy specifies anenforcement version, whichidentifies a predefined list of IAM permissions that theprincipal access boundary policy can block. You specify the enforcement version whenyou create or update a principal access boundary policy. If you don't specify anenforcement version, IAM uses the latest enforcement version, andwill continue to use that version until you update it.

Periodically, IAM adds new principal access boundary enforcementversions that can block additional permissions. Each new version can also blockall of the permissions in the previous version.

To block the permissions in a new enforcement version, you must update yourprincipal access boundary policies to use the new version. If you want the enforcementversion to update automatically as new versions are released, you can use thevaluelatest when creating the policy. However, we don't recommend using thisvalue, because it might cause principals to lose access to resourcesunexpectedly.

For a full list of the permissions that each enforcement version blocks, seePermissions that principal access boundary policies block.

Bind principal access boundary policies to principal sets

To bind a principal access boundary policy to a principal set, you create apolicybinding that specifies both the principal access boundary policy that you want toenforce and the principal set that you want to enforce it for. After you bindthe policy to a principal set, the principals in that principal set can accessonly the resources that are included in the principal access boundary policy's rules.

You can bind a principal access boundary policy to any number of principal sets. Eachprincipal set can have up to 10 principal access boundarypolicies bound to it.

You can only create bindings for existing principal access boundary policies. Trying tocreate a binding for a deleted principal access boundary policy will fail. If yourecently deleted a principal access boundary policy, you can sometimes successfullycreate a binding, but the binding won't have any effect. IAMcleans up these bindings automatically.

To learn how to manage principal access boundary policies, seeCreate and applyprincipal access boundary policies.

Supported principal sets

The following table lists the types of principal sets that you can bindprincipal access boundary policies to. Each row contains the following:

• The type of principal set
• The principals in that type of principal set
• The format of IDs for that type of principal set
• The Resource Manager resource (project, folder, or organization) thatparents policy bindings for that type of principal set

Conditional policy bindings for principal access boundary policies

You can use condition expressions in policy bindings for principal access boundarypolicies to further refine which principals the policy applies to.

Condition expressions for policy bindings consist of one or more statementsjoined by up to 10 logicaloperators (&&,||, or!). Each statement expresses an attribute-basedcontrol rule that applies to the policy binding, and ultimately determineswhether the policy applies.

You can use theprincipal.type andprincipal.subject attributes inconditions for policy bindings. No other attributes are supported in conditionsfor policy bindings.

• Theprincipal.type attribute indicates what type of principal is in therequest—for example, service accounts, or identities in a workloadidentity pool. You can use conditions with this attribute to control whichtypes of principals a principal access boundary policy applies to.

  For example, if you add the following condition expression to a binding fora principal access boundary policy, then the policy only applies to serviceaccounts:

  principal.type == 'iam.googleapis.com/ServiceAccount'

• Theprincipal.subject attribute indicates the identity of the principal inthe request—for example,cruz@example.com. You can use conditions withthis attribute to control exactly which principals are subject to aprincipal access boundary policy.

  For example, if you add the following condition expression to a binding fora principal access boundary policy, then the policy won't apply for the userspecial-admin@example.com:

  principal.subject != 'special-admin@example.com'

To learn more about the values that you can use for these conditions, seetheconditions attribute reference.

Example: Use conditions to reduce the resources that a principal is eligible to access

One of the ways that you can use conditions in principal access boundary policybindings is to reduce the resources that a single principal is eligible toaccess.

Imagine that you have a service account,dev-project-service-account, with theemail addressdev-project-service-account@dev-project.iam.gserviceaccount.com. This service account is subject to aprincipal access boundary policy that makes principals eligible to access all resourcesin the organizationexample.com. This policy is attached to theexample.com organization's principal set.

You decide that you don't wantdev-project-service-account to be eligible toaccess all resources inexample.com—you only want it to be eligible toaccess resources indev-project. However, you don't want to change theresources that other principals in theexample.com principal set are eligibleto access.

To make this change, you follow the procedure toreduce the resources thatprincipals are eligible to access, but you add a conditionto the policy binding instead of deleting it:

1. You confirm that the only principal access boundary policy thatdev-project-service-account is subject to is the policy that makesprincipals eligible to access all resources inexample.com.

2. Youcreate a new principal access boundary policy that makesprincipals eligible to access resources indev-project and attach it to theprincipal set fordev-project. You use the followingcondition in the policy binding to ensure that the policy isonly enforced fordev-project-service-account:

   "condition": {  "title": "Only dev-project-service-account",  "expression": "principal.type == 'iam.googleapis.com/ServiceAccount' && principal.subject == 'dev-project-service-account@dev-project.iam.gserviceaccount.com'"}

3. You exemptdev-project-service-account from the principal access boundary policythat makes principals eligible to access all resources inexample.com. Todo this, you add the following condition to the policy binding that attachesthat principal access boundary policy to the organization's principal set:

   "condition": {  "title": "Exempt dev-project-service-account",  "expression": "principal.subject != 'dev-project-service-account@dev-project.iam.gserviceaccount.com' || principal.type != 'iam.googleapis.com/ServiceAccount'"}

   To learn how to update existing principal access boundary policies, seeEditprincipal access boundary policies.

After you add this condition to the policy binding,dev-project-service-account is no longer eligible to access all resources inexample.com—instead, it's only eligible to access resources indev-project.

Cross-organization policy bindings

You can't create across-organization policy binding for a principal access boundarypolicy. A cross-organization policy binding is a policy binding that binds apolicy in one organization to a principal set in another organization.

IAM periodically deletes any existing cross-organization policybindings. Cross-organization policy bindings can occur when youmove aproject from one organization to another. For example, considerthe following situation:

• You have a project,example-project, in the organizationexample.com.
• You want principals inexample-project to be eligible to access resources inexample.com. To do this, you create a principal access boundary policy inexample.com that makes principals eligible to access resources inexample.com and bind that policy to the principal set forexample-project.
• You moveexample-project fromexample.com tocymbalgroup.com.

In this situation, moving the project would create a cross-organization policybinding. This is because the principal access boundary policy inexample.com would bebound to a principal set incymbalgroup.com. If you don't delete the bindingmanually, IAM would eventually delete it automatically. Deletingthis binding helps ensure thatcymbalgroup.com administrators have access toall principal access boundary policies bound to their principals.

Policy interactions

IAM evaluates each principal access boundary policy in combination withyour allow and deny policies, and with your other principal access boundary policies.All of these policies are used to determine whether a principal can access aresource.

Interaction with other policy types

When a principal tries to access a resource, IAM evaluates allrelevant principal access boundary, allow, and deny policies to see if the principal isallowed to access the resource. If any one of these policies indicates that theprincipal shouldn't be able to access the resource, IAM preventsaccess.

As a result, if a principal access boundary policy would prevent a principal fromaccessing a resource, then IAM prevents them from accessing thatresource, regardless of the allow and deny policies attached to the resource.

Additionally, principal access boundary policies alone don't give principals access toresources. While principal access boundary policies can make a principaleligibleto access a resource, only allow policies can actually grant the principalaccess to the resource.

To learn more about IAM policy evaluation, seePolicyevaluation.

Interaction between principal access boundary policies

If any principal access boundary policy makes a principal eligible to access aresource, then the principal is eligible to access that resource, regardless ofthe other principal access boundary policies the principal is subject to. As a result,if a principal is already subject to a principal access boundary policy, then you can'tadd principal access boundary policies to reduce a principal's access.

For example, imagine that a principal, Dana (dana@example.com), is subject toa single principal access boundary policy,prod-projects-policy. This policymakes principals eligible to access resources inprod-project. Dana is subjectto this policy because it's bound to their organization's principal set.

You create a new principal access boundary policy,dev-staging-projects-policy, thatmakes principals eligible to access resources indev-project andstaging-project, and then bind it to the organization's principal set.

As a result of these principal access boundary policies, Dana is eligible to accessresources indev-project,staging-project, andprod-project.

If you want to reduce the resources that Dana is eligible to access, you need tomodify or remove the principal access boundary policies that Dana is subject to.

For example, you could editdev-staging-projects-policy so that it doesn'tmake principals eligible to access resources indev-project. Then, Dana wouldonly be eligible to access resources instaging-project andprod-project.

Alternatively, you could removeprod-projects-policy by deleting the policybinding that binds it to the organization's principal set. Then, Dana would onlybe eligible to access resources indev-project andstaging-project.

However, these changes don't just affect Dana—they also affect the otherprincipals that are subject to the modified principal access boundary policies andbindings. If you want to reduce the resources that a single principal iseligible to access, useconditional policybindings.

Policy inheritance

Principal access boundary policies are attached to principal sets, notResource Manager resources. As a result, they aren't inherited through theresource hierarchy in the same way that allow and denypolicies are.

However, principal sets for Resource Manager parent resources—that is,folders and organizations—always include all of the principals in theirdescendants' principal sets. So, for example, if a principal is included ina project's principal set, it is also included in the principal sets of anyparent folders or organizations.

For example, consider an organization,example.com. This organization isassociated with the domainexample.com, and has the following Resource Managerresources:

• An organization,example.com
• A project,project-1, that's a child of the organization
• A folder,folder-a, that's a child of the organization
• Two projects,project-2 andproject-3, that are children offolder-a

These resources' principal sets contain the following identities:

As a result, the following principals are affected by the followingprincipal access boundary policies:

• A Google Workspace identity in theexample.com domain is in theprincipal set forexample.com and will be affected by principal access boundarypolicies bound to that principal set.

• A service account inproject-1 is in the principal sets forproject-1 andexample.com and will be affected by principal access boundarypolicies bound to either of those principal sets.

• A service account inproject-3 is in the principal sets forproject-3,folder-a, andexample.com, and will be affected byprincipal access boundary policies bound to any of those principal sets.

Principal access boundary policies and cached resources

Certain Google Cloud services cache publicly visible resources. For example,Cloud Storagecaches objects that are publiclyreadable.

Whether principal access boundary can prevent ineligible principals from viewing apublicly visible resource depends on whether the resource is cached:

• If the resource is cached, then principal access boundary can't prevent principalsfrom viewing the resource
• If the resource isn't cached, then principal access boundary prevents ineligibleprincipals from viewing the resource

In all cases, principal access boundary policies prevent ineligible principals frommodifying or deleting publicly visible resources.

Structure of a principal access boundary policy

A principal access boundary policy is a collection of metadata andprincipal access boundary policy details. The metadata provides information like thepolicy name and when the policy was created. The policy details define what thepolicy does—for example, the resources that affected principals areeligible to access.

For example, the following principal access boundary policy makes the principals whoare subject to the policy eligible to access the resources in the organizationwith the ID0123456789012.

{"name":"organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-policy","uid":"puid_0123456789012345678","etag":"W/\"Gh/PcTdJD/AWHUhPW45kdw==\"","displayName":"Example policy","annotations":{"example-key":"example-value"},"createTime":"2024-01-02T15:01:23Z","updateTime":"2024-01-02T15:01:23Z","details":{"rules":[{"description":"Example principal access boundary policy rule","resources":["//cloudresourcemanager.googleapis.com/organizations/0123456789012"],"effect":"ALLOW"}],"enforcementVersion":"1"}}

The following sections describe the fields in a principal access boundary policy'smetadata and details.

Metadata

Principal access boundary policies contain the following metadata:

• name: The name of the principal access boundary policy. This name has the formatorganizations/ORGANIZATION_ID/locations/global/principalAccessBoundaryPolicies/PAB_POLICY_ID,whereORGANIZATION_ID is the numeric ID of theorganization where the principal access boundary policy was created andPAB_POLICY_ID is the principal access boundary policy'salphanumeric ID.
• uid: A unique ID assigned to the principal access boundary policy.
• etag: An identifier for the policy's current state. This value changes whenyou update the policy. To prevent conflicting updates, theetag value mustmatch the value that is stored in IAM. If theetag valuesdon't match, the request fails.
• displayName: A human-readable name for the principal access boundary policy.
• annotations: Optional. A list of user-defined key-value pairs. You can usethese annotations to add extra metadata to the policy—for example, whocreated the policy, or whether the policy was deployed by an automatedpipeline. For more information about annotations, seeAnnotations.
• createTime: The time when the principal access boundary policy was created.
• updateTime: The time when the principal access boundary policy was last updated.

Details

Each principal access boundary policy contains adetails field. This field containsthe principal access boundary rules and enforcement version:

• rules: A list of principal access boundary rules, which define the resources thataffected principals are eligible to access. Each rulecontains the following fields:

  • description: A human-readable description for the rule.

  • resources: A list of Resource Manager resources (projects, folders, andorganizations) that you want principals to be eligible to access. Anyprincipal that is subject to this policy is eligible to access theseresources.

    Each principal access boundary policy can reference a maximum of500 resources across all rules in thepolicy.

  • effect: The relationship that principals have with the resources listedin theresources field. The only effect that you can specify inprincipal access boundary rules is"ALLOW". This relationship makes theprincipals eligible to access the resources listed in the rule.

• enforcementVersion: The enforcement version that IAM useswhen enforcing the policy. The principal access boundary policy version determineswhich permissions the principal access boundary policy can block.

  For more information about principal access boundary policy versions, seePrincipal access boundary enforcement versions on this page.

Structure of a policy binding

A policy binding for a principal access boundary policy contains the name of a policy,the name of the principal set to bind the policy to, and metadata describing thepolicy binding. It can also contain conditions that modify the exact principalsthat the policy applies to.

For example, the following policy binding binds the policyexample-policy toall principals in theexample.com organization, which has the ID0123456789012. The policy binding also contains a condition that prevents thepolicy from being enforced for the principalsuper-admin@example.com.

{"name":"organizations/0123456789012/locations/global/policyBindings/example-policy-binding","uid":"buid_01234567890123456789","etag":"W/\"cRMdDXbT82aLuZlvoL9Gqg==\"","displayName":"Example policy binding","annotations":{"example-key":"example-value"},"target":{"principalSet":"//cloudresourcemanager.googleapis.com/organizations/0123456789012"},"policyKind":"PRINCIPAL_ACCESS_BOUNDARY","policy":"organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-policy","policyUid":"puid_0123456789012345678","condition":{"title":"Exempt principal","description":"Don't enforce the policy for super-admin@example.com","expression":"principal.subject != 'super-admin@example.com'"},"createTime":"2024-01-02T17:00:16Z","updateTime":"2024-01-02T17:00:16Z"}

Each policy binding contains the following fields:

• name: The name of the policy binding. This name has the formatRESOURCE_TYPE/RESOURCE_ID/locations/global/policyBindings/BINDING_ID,whereRESOURCE_TYPE/RESOURCE_ID is the type andID of the policy binding's parent resource andBINDING_ID is the policy binding's alphanumeric ID.
• uid: A unique ID assigned to the policy binding.
• etag: An identifier for the policy's current state. This value changes whenyou update the policy. To prevent conflicting updates, theetag value mustmatch the value that is stored in IAM. If theetag valuesdon't match, the request fails.
• displayName: A human-readable name for the policy binding.
• annotations: Optional. A list of user-defined key-value pairs. You can usethese annotations to add extra metadata to the policy binding—forexample, who created the policy binding, or whether the policy binding wasdeployed by an automated pipeline. For more information about annotations, seeAnnotations.

• target: The principal set to bind the policy to. The value has the format{"principalSet":PRINCIPAL_SET}, wherePRINCIPAL_SET is the ID of the principal set that youwant to bind the policy to.

  Each target can have up to 10 policies boundto it.

• policyKind: The type of policy that the policy binding references. Forpolicy bindings for principal access boundary policies, this value is alwaysPRINCIPAL_ACCESS_BOUNDARY.

• policy: The principal access boundary policy to bind to the target principal set.

• policyUid: A unique ID assigned to the principal access boundary policyreferenced in thepolicy field.

• condition: Optional. A logic expression that affects which principalsIAM enforces the policy for. If the condition evaluates to trueor cannot be evaluated, Identity and Access Management enforces the policy for the principalmaking the request. If the condition evaluates to false, Identity and Access Managementdoesn't enforce the policy for the principal. For more information, seePrincipal access boundary and conditions on this page.

• createTime: The time when the policy binding was created.

• updateTime: The time when the policy binding was last updated.

Use cases

The following are common situations where you might want to useprincipal access boundary policies, and examples of the principal access boundary policies andpolicy bindings that you might create in each situation. To learn how to createprincipal access boundary policies and bind them to principal sets, seeCreate andapply principal access boundary policies.

Make principals eligible to access to resources in your organization

You can use a principal access boundary policy to make principals in your organizationeligible to access resources within your organization. If this is the onlyprincipal access boundary policy that the principals in your organization are subjectto, then the principal access boundary policy will also make the principals in yourorganization ineligible to access resources outside of your organization.

For example, imagine that you want to make all principals in the organizationexample.com eligible to access resources withinexample.com and ineligibleto access resources in other organizations. The principals that are inexample.com include all identities in theexample.com domain, all workforceidentity pools inexample.com, and all service accounts and workload identitypools in any project inexample.com.

You don't have any principal access boundary policies that apply to any of theprincipals in your organization. As a result, all principals are eligible toaccess all resources.

To make principals eligible to access resources inexample.com and ineligibleto access resources outside ofexample.com, you create a principal access boundarypolicy that makes principals eligible to access resources inexample.com:

{"name":"organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-org-only","displayName":"Boundary for principals in example.org","details":{"rules":[{"description":"Principals are only eligible to access resources in example.org","resources":["//cloudresourcemanager.googleapis.com/organizations/0123456789012"],"effect":"ALLOW"}],"enforcementVersion":"1"}}

Then, you create a policy binding to bind this policy to the organizationprincipal set:

{"name":"organizations/0123456789012/locations/global/policyBindings/example-org-only-binding","displayName":"Bind policy to all principals in example.com","target":{"principalSet":"//cloudresourcemanager.googleapis.com/organizations/0123456789012"},"policyKind":"PRINCIPAL_ACCESS_BOUNDARY","policy":"organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-org-only"}

When bound to the organization principal set, this policy makes all principalsinexample.com eligible to access resources inexample.com. Because thisis the only principal access boundary policy that these principals are subject to, thepolicy also makes the principals inexample.com ineligible to access resourcesoutside of your organization. This means that they can't use permissions thatareblocked by the principal access boundary policy to accessresources outside ofexample.com, even if they have those permissions on thoseresources.

Make service accounts eligible to resources in a single project

You can create a principal access boundary policy to make the service accounts in aspecific project eligible to access resources within that project.

If this is the only principal access boundary policy that the service accounts aresubject to, then the service accounts willonly be eligible to accessresources within that project.

For example, imagine that you have a project,example-dev, with the projectnumber901234567890. You want to ensure that the service accounts inexample-dev are only eligible to access resources inexample-dev.

You have a principal access boundary policy that makes all principals in yourorganization, including the service accounts inexample-dev, eligible toaccess resources inexample.com. To see what this type of policy looks like,seeMake principals eligible to access to resources in yourorganization.

To make the service accounts inexample-dev ineligible to access resourcesoutside ofexample-dev, you first create a principal access boundary policy thatmakes principals eligible to access resources inexample-dev

{"name":"organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-dev-only","displayName":"Boundary for principals in example-dev","details":{"rules":[{"description":"Principals are only eligible to access resources in example-dev","resources":["//cloudresourcemanager.googleapis.com/projects/example-dev"],"effect":"ALLOW"}],"enforcementVersion":"1"}}

Then, you create a policy binding to bind this policy to all principals inexample-dev, and add a condition so that the policy binding only applies forservice accounts:

{"name":"organizations/0123456789012/locations/global/policyBindings/example-dev-only-binding","displayName":"Bind policy to all service accounts in example-dev","target":{"principalSet":"//cloudresourcemanager.googleapis.com/projects/example-dev"},"policyKind":"PRINCIPAL_ACCESS_BOUNDARY","policy":"organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-dev-only","condition":{"title":"Only service accounts","description":"Only enforce the policy if the principal in the request is a service account","expression":"principal.type == 'iam.googleapis.com/ServiceAccount'"}}

However, this policy on its own doesn't change the resources that the serviceaccounts are eligible to access. This is because there's an existingprincipal access boundary policy that makes all principals inexample.com eligible toaccess all resources inexample.com. Principal access boundary policies areadditive, so the service accounts inexample-dev arestill eligible to access all resources inexample.com.

To ensure that service accounts inexample-dev areonly eligible to accessresources inexample-dev, you need to add a condition to the policy bindingfor the existing principal access boundary policy that prevents it from being enforcedfor the service accounts, including thedefault service accounts,inexample-dev:

{"name":"organizations/0123456789012/locations/global/policyBindings/example-org-only-binding","displayName":"Bind policy to all principals in example.com","target":{"principalSet":"//cloudresourcemanager.googleapis.com/organizations/0123456789012"},"policyKind":"PRINCIPAL_ACCESS_BOUNDARY","policy":"organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-org-only","condition":{"title":"Exempt example-dev service accounts","description":"Don't enforce the policy for service accounts in the example-dev project","expression":"principal.type != 'iam.googleapis.com/ServiceAccount' || !principal.subject.endsWith('@example-dev.iam.gserviceaccount.com') || !principal.subject == 'example-dev@appspot.gserviceaccount.com || !principal.subject == '901234567890-compute@developer.gserviceaccount.com'"}}

Now, the service accounts inexample-dev are only eligible to access resourcesinexample-dev. They're prevented from using permissions that areblocked bythe principal access boundary policy to access resources outsideofexample-dev, even if they have those permission on those resources.

Later, if you want to increase the resources that these service accounts areeligible to access, you can add additional resources to theexample-dev-onlypolicy or create an additional principal access boundary policy and bind it to theservice accounts.

What's next

• Learn how tocreate and apply principal access boundary policies.
• Review thepermission each principal access boundary policy enforcement versionblocks.