This document describes the different methods administrators can use to identifyand resolve permission errors for users in their organization.

Resolve permission errors from access requests

If you're an administrator, then you might receive access requests from userswho have encountered permission errors in the Google Cloud console. Theserequests are typically sent to the following people:

• Your organization'stechnical EssentialContact. If your organization has enabledEssential Contacts and allows auto-generated access request emails,then users who encounter permission errors in theGoogle Cloud console have the option to send an auto-generated accessrequest to their organization's technical Essential Contact.

• Contacts configured through your preferred request management system.Users who encounter permission errors in the Google Cloud console have theoption to copy an access request message and then send it using theirpreferred request management system.

These messages typically have the following format:

user@example.com is requesting a role on the resource example.com:example-project.Requestor's message:"I need access to example-project to complete my work."You may be able to resolve this request by granting access directly at:ACCESS_REQUEST_PANEL_URLOr use the Policy Troubleshooter to determine what's preventing access for user@example.com:POLICY_TROUBLESHOOTER_URL

You can address these requests in the following ways:

• Resolve access directly: Access requests contain a link to an accessrequest panel in the Google Cloud console. If the permission error is causedby an allow policy, then you can resolve access directly from that panel.

  In the access request panel, you can review the request details and choose howyou want to respond to the request. You can respond in the following ways:

  • Grant the requested role
  • Add the user to an existing group that already has the required access
  • Deny the request

• View additional details in Policy Troubleshooter: Accessrequests contain a link to Policy Troubleshooter, whichlets you see which policies are blocking the user's access. You can use thisinformation to decide how to resolve the user's access issue. For moreinformation, seeIdentify policies causing permissionerrors on this page.

• Remediate access issues with Policy Troubleshooter(Preview):Access requests also contain a link to a policy remediation summary, whichdescribes the request details, including the requesting principal, resource,and permission. From the policy remediation summary, you can directly resolveaccess requests involving allow policies, and get more information about thepolicies that are blocking user access.

  For more information about resolving access requests using the policyremediation summary, seeRemediate access issues.

Manually resolve permission errors

If you're an administrator with permission to modify the access-relatedpolicies in your organization, then you can use these strategies to resolvepermission errors, regardless of the policy type causing the error.

To resolve permission errors, you first need to determine which policies (allow,deny, or principal access boundary) are causing the error. Then, you can resolve theerror.

Identify policies causing permission errors

To determine which policies are causing a permission error, usePolicy Troubleshooter.

To learn how to troubleshoot access and interpretPolicy Troubleshooter results, seeTroubleshootIAM permissions.

Error messages in the Google Cloud console contain a link to aPolicy Troubleshooter remediation page(Preview) for theprincipal, permissions, and resource involved in the request. To view this link,clickView troubleshooting details, and then clickPolicy Troubleshooter. For more information, seeRemediate access requests.

Update access to resolve permission errors

After you know which policies are causing a permission error, you can take stepsto resolve the error.

Often, resolving an error involves creating or updating allow, deny, orprincipal access boundary policies.

However, there are other options for resolving errors that don't involveupdating policies. For example, you can add the user to a group that has therequired permissions or add tags to exempt a resource from a policy.

To learn the different ways that you can resolve permission errors caused byeach of the different policy types, see the following:

• Resolve allow policy permission errors
• Resolve deny policy permission errors

• Resolve principal access boundary permission errors

Resolve allow policy permission errors

To resolve permission errors caused by allow policies, do one of the following.

Grant a role with the required permissions

To find and grant a role with the required permissions, do the following:

1. Identify an IAM role that contains the missing permissions.

   To see all of the roles that a given permission is included in, search forthe permission in theIAM roles and permissionsindex, then click the permission name.

   If no predefined roles match your use case, then you cancreate a customrole instead.

2. Identify a principal to grant the role to:

   • If the user is the only individual who needs the permission, then grantthe role directly to the user.
   • If the user is part of a Google group containing users that all needsimilar permissions, then consider granting the role to the group instead.If you grant the role to the group, then all members of that group can usethat permission, unless they have beenexplicitly deniedfrom using it.

3. Grant the role to the principal.

Approve a grant against a Privileged Access Manager entitlement

Privileged Access Manager entitlements let users request to be grantedspecific IAM roles. If you approve a user's request for agrant, then they're granted the requested roles temporarily.

If the user already has a Privileged Access Manager entitlement with a role thatcontains the required permissions, then they can request a grant against thatentitlement. After they request the grant, you canapprove thegrant to resolve their permission error.

If a user doesn't have an entitlement, then you cancreate a newentitlement for them to request grants against.

Add the user to a Google group

If a Google group is granted a role on a resource, then all members of thatgroup can use the permissions in that role to access the resource.

If an existing group has already been granted a role with the requiredpermissions, then you can give a user the required permissions by adding them tothat group:

1. Identify a group that has a role with the required permissions. If youalready used Policy Troubleshooter to troubleshoot therequest, then you can review the Policy Troubleshooter resultsto identify a group with the required permissions.

   Alternatively, you can usePolicy Analyzer toidentify a group with the required permissions.

2. Add the user to the group.

Resolve deny policy permission errors

To resolve permission errors related to deny policies, do one of the following.

Exempt yourself from a deny policy

If a deny rule is blocking a user's access to a resource, you can do one of thefollowing to exempt the user from the rule:

• Add the user as an exception principal in the deny rule. Exceptionprincipals are principals who are not affected by the deny rule, even ifthey're part of a group that's included in the deny rule.

  To add an exception principal to a deny rule, follow the steps toupdatethe deny policy. When updating the deny policy, find the denyrule that blocks access, then add the user's principal identifier as anexception principal.

• Add the user to a group that's exempt from the rule. If a group is listedas an exception principal, then all members of that group are exempt from thedeny rule.

  To add the user to an exempt group, do the following:

  1. UsePolicy Troubleshooter to identify the denypolicies that are blocking access to the resource.
  2. View the deny policy.
  3. Check the list of exception principals for groups.
  4. If you identify an exempt group,add the user to the group.

Remove the permission from the deny policy

Deny rules prevent the listed principals from using specific permissions. If adeny rule is blocking a user's access to a resource, then you can remove thepermissions that they need from the deny rule.

To remove permissions from a deny rule, follow the steps toupdate thedeny policy. When updating the deny policy, find the deny rulethat blocks access, then do one of the following:

• If the deny policy lists the required permissions individually, then find therequired permissions and remove them from the deny rule.
• If the deny rule usespermission groups, then addthe required permissions as exception permissions. Exception permissions arepermissions that aren't blocked by the deny rule, even if they're part of apermission group that's included in the rule.

Exclude the resource from the deny policy

You can useconditions in deny policies to apply a denyrule based on a resource's tags. If the resource's tags don't meet the conditionin the deny rule, then the deny rule doesn't apply.

If a deny rule is blocking access to a resource, then you can edit theconditions in the deny rule or the tags on the resource to ensure that thedeny rule doesn't apply to the resource.

• To learn how to use conditions in a deny rule, seeConditions in denypolicies.

• To learn how to update deny policies, seeUpdate a deny policy.

• To learn how to edit a resource's tags, seeCreating and managingtags.

Resolve principal access boundary policy permission errors

By default, principals are eligible to access any Google Cloud resource.However, if they're subject to any principal access boundary policy, then they'reonly eligible to access the resources listed in the principal access boundary policiesthat they're subject to. In these cases, a principal access boundary policy mightprevent a principal from accessing a resource.

To resolve errors related to principal access boundarypolicies, do one of the following.

Add the resource to a principal access boundary policy

If a resource is included in a principal access boundary policy that a user is subjectto, then they're eligible to access that resource.

To add a resource to a principal access boundary policy, do one of the following:

• Create a new principal access boundary policy:

  1. Create a new principal access boundary policy that includes theresource.

  2. Bind the policy to a principal set that the user is includedin.

     To learn more about principal sets, seeSupported principalsets.

• Update an existing principal access boundary policy:

  1. List the principal access boundary policy bindings for aprincipal set that the user is included in. Each binding represents aprincipal access boundary policy that's bound to the principal set.
  2. From the list of bindings, identify a principal access boundary policy tomodify.
  3. Optional:List the principal access boundary policy bindingsfor the policy to see which principal sets the policy is bound to. Updatingthe policy will impact access for all principal sets that the policy isbound to.
  4. Edit the principal access boundary policy so that it includes theresource.

Add a condition to exempt specific principals

You can useconditions in principal access boundary policy bindingsto refine which principals the principal access boundary policy is enforced for.

If you don't want a user to be subject to principal access boundary policies, then useconditions in principal access boundary policy bindings to exempt the user fromprincipal access boundary policies.

For this approach to resolve errors, you must exempt the user fromeveryprincipal access boundary policy that they're subject to. Doing so will make the usereligible to access any Google Cloud resource.

We don't recommend this approach. Instead, consideradding the resource to aprincipal access boundary policy.

To view the principal access boundary policies that a user is subject to,list thepolicy bindings for the principal sets that they're includedin. Each binding represents a principal access boundary policy that's bound to theprincipal set.

To learn how to add conditions to principal access boundary policy bindings, seeEditexisting policy bindings for principal access boundarypolicies.

What's next

• Test role changes with Policy Simulator
• Test deny policy changes with Policy Simulator
• Test principal access boundary policy changes