Identity and Access Management (IAM) offers several types of policies to help youcontrol which resources principals can access. This page helps youunderstand the differences between how you use and manage these policy types.

Types of IAM policies in Google Cloud

IAM offers the following types of policies:

• Allow policies
• Deny policies
• Principal access boundary (PAB) policies
• Access policies

The following table summarizes the differences between these policy types:

Policy	Policy function	API used to manage the policy	Relationship between policies and targets	Method of attaching policies to target	Policy's parent resource
Allow policies	Grant principals access to resources	The API for the resource that you want to manage allow policies for	One-to-one relationship Each allow policy is attached to one resource; each resource can only have one allow policy	Specify resource when creating the policy	Same as the resource that the allow policy is attached to
Deny policies	Ensure that principals can't use specific permissions	TheIAM v2 API	One-to-many relationship Each deny policy is attached to one resource; each resource can have up to 500 deny policies	Specify resource when creating the deny policy	Same as the resource that the deny policy is attached to
PAB policies	Restrict the resources a principal is eligible to access	TheIAM v3 API	Many-to-many relationship Each PAB policy can be attached to an unlimited number of principal sets; each principal set can have up to 10 PAB policies bound to it	Create a policy binding that attaches the PAB policy to a principal set	The organization
Access policies	Grant or deny principals access to resources for supported services	TheIAM v3 API	Many-to-many relationship Each access policy can be attached to up to 5 resources; each resource can have up to 5 access policies bound to it	Create an access policy binding that attaches the access policy to the resource	The project, folder, or organization where the access policy is created

The following sections provide details about each policy type.

Policies to grant access to principals

To grant principals access to resources, use one of the following policies:

• Use allow policies to grant access to any resource type.
• Use access policies to grant access to Eventarc resources.

Allow policies let you grant access to resources in Google Cloud. Allowpolicies are made up of role bindings and metadata. Role bindings specify whichprincipals should have a certain role on the resource.

Allow policies are always attached to a single resource. After you attach anallow policy to a resource, the policy isinherited by thatresource's descendants.

To create and apply an allow policy, you identify a resource thataccepts allowpolicies, then use that resource'ssetIamPolicy method to create the allow policy. All principals in the allowpolicy are granted the specified roles on the resource and all of the resource'sdescendants. Each resource can have only one allow policy attached to it.

For more information about allow policies, seeUnderstanding allowpolicies.

Access policies let you control access to Eventarc resources. Accesspolicies can both allow and deny access to resources. To create and apply anaccess policy, you create an access policy, and then create a policy binding toconnect that policy to a project with Eventarc resources.

Each policy binding binds one access policy to one resource. An access policycan be bound to up to 5 resources. Each resourcecan have up to 5 access policiesbound to it. When an access policy is deleted, all of the policy bindingsrelated to that policy are also deleted.

To learn more about using access policies to control access to Eventarcresources, see theEventarc documentation.

Policies to deny access to principals

To deny principals access to resources, use one of the following:

• Use deny policies to deny access for any resource type.
• Use access policies to deny access for Eventarc resources.

Deny policies, like allow policies, are always attached to a single resource.You can attach a deny policy to a project, folder, or organization. Thisproject, folder, or organization also acts as the policy's parent in theresource hierarchy. After you attach a deny policy to a resource, the policyisinherited by that resource's descendants.

To create and apply deny policies, you use the IAM v2 API. Whenyou create a deny policy, you specify the resource that the deny policy isattached to. All principals in the deny policy are prevented from using thespecified permissions to access that resource and any of that resource'sdescendants. Each resource can have up to500 deny policies attached to it.

For more information about deny policies, seeDeny policies.

Access policies let you control access to Eventarc resources. Accesspolicies can both allow and deny access to resources. To create and apply anaccess policy, you create an access policy, and then create a policy binding toconnect that policy to a project with Eventarc resources.

Each policy binding binds one access policy to one resource. An access policycan be bound to up to 5 resources. Each resourcecan have up to 5 access policiesbound to it. When an access policy is deleted, all of the policy bindingsrelated to that policy are also deleted.

To learn more about using access policies to control access to Eventarcresources, see theEventarc documentation.

Policies to restrict the resources a principal can access

To restrict the resources that a principal is eligible to access, use aprincipal access boundary policy. Principal access boundary policies are available in theIAM v3 API.

To create and apply a principal access boundary policy, you create a principal access boundarypolicy, and then create a policy binding to connect that policy to a principalset.

Principal access boundary policies are always children of your organization.Policy bindings for principal access boundary policies are children of the project,folder, or organization that is closest to the principal set referenced in thepolicy binding.

Each policy binding binds one principal access boundary policy to one principal set. Aprincipal access boundary policy can be bound to any number of principal sets. Eachprincipal set can have up to 10 principal access boundarypolicies bound to it. When a principal access boundary policy is deleted, all of thepolicy bindings related to that policy are also deleted.

For more information about principal access boundary policies, seePrincipal access boundarypolicies.

Policy evaluation

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

In reality, IAM evaluates all policy types simultaneously, thencompiles the results to determine whether the principal can access the resource.However, it can be helpful to think of this policy evaluation taking place inthe following stages:

1. IAM checks all relevant principal access boundary policies to see if the principal is eligible to access the resource. A principal access boundary policy is relevant if the following are true:

   • The policy is bound to a principal set that includes the principal
   • The principal access boundary policy blocks the permission that the principal is trying to use. The permissions that a principal access boundary policy blocks depends on the principal access boundary policy version. You specify the policy version when you create the principal access boundary policy. For more information, seePrincipal access boundary policy versions.

   After checking the relevant principal access boundary policies, IAM does one of the following:

   • If the relevant principal access boundary policies don't include the resource that the principal is trying to access, or if IAMcan't evaluate the relevant principal access boundary policies, then IAM prevents them from accessing the resource.
   • If the relevant principal access boundary policies include the resource that the principal is trying to access, then IAM continues to the next step.
   • If there are no relevant principal access boundary policies, then IAM continues to the next step.

2. IAM checks all relevant deny policies to see if the principal has been denied the permission. Relevant deny policies are the deny policies attached to the resource, as well as anyinherited deny policies.

   For Eventarc resources, IAM also evaluates any access policies with theDENY action. If IAM fails to evaluate access policies, then it ignores them and continues with the evaluation.
   • Ifany of these deny policies prevent the principal from using a required permission, then IAM prevents them from accessing the resource.
   • If no deny policies prevent the principal from using a required permission, then IAM continues to the next step.

3. IAM checks all relevant allow policies to see if the principal has the required permissions. Relevant allow policies are the allow policies attached to the resource, as well as anyinherited allow policies.

   For Eventarc resources, IAM also evaluates any access policies with theALLOW action. If IAM fails to evaluate access policies, then it ignores them and continues with the evaluation.
   • If the principal does not have the required permissions, then IAM prevents them from accessing the resource.
   • If the principal has the required permissions, then IAM lets them access the resource.

The following diagram shows this policy evaluation flow:

What's next

• Learn more aboutallow policies.
• Learn more aboutdeny policies.
• Learn more aboutprincipal access boundary policies.