Troubleshoot IAM permissions

Policy Troubleshooter makes it easier to understand why a user has access to a resource or doesn't have permission to call an API. Given an email, resource, and permission, Policy Troubleshooter examines all Identity and Access Management (IAM) policies that apply to the resource. It then reveals whether the principal's roles include the permission on that resource and, if so, which policies bind the principal to those roles.

You can access Policy Troubleshooter using the console, the Google Cloud CLI, or the REST API. For simple queries, using the console is typically fastest. For more complex scenarios, consider the gcloud CLI or the REST API.

The console also alerts you if there are any deny policies that could impact the principal's access. The gcloud CLI and the REST API don't provide information about deny policies.

Before you begin

  • Enable the Policy Troubleshooter API.

    Enable the API

Required permissions

Policy Troubleshooter analyzes a principal's access to a resource based on the IAM policies and roles that you have permission to view. If you don't have permission to view a policy that applies to a resource, or if you don't have permission to view a custom role, then you might not be able to tell whether a principal has access.

To get the permissions that you need to troubleshoot a principal's access, ask your administrator to grant you the Security Reviewer (roles/iam.securityReviewer) IAM role on the organization. For more information about granting roles, see Manage access.

This predefined role contains the permissions required to troubleshoot a principal's access. To see the exact permissions that are required, expand the Required permissions section:

Required permissions

  • iam.roles.get
  • iam.roles.list
  • resourcemanager.folders.getIamPolicy
  • resourcemanager.organizations.getIamPolicy
  • resourcemanager.projects.getIamPolicy

You might also be able to get these permissions with custom roles or other predefined roles.

Troubleshooting access

To troubleshoot access, you need the following information:

  • Principal: The email address to check. The email address must refer to a user or service account. Other types of principals are not supported.
  • Resource: The full name of the resource. For example, to check the project my-project, enter // For other types of resources, see the examples of full resource names.
  • Permission: The permission to check. If you use the console, it presents a list of suggestions as you type. For a complete list of permissions, see the permissions reference.


Troubleshooting access

To troubleshoot access, do the following:

  1. In the console, go to the Policy Troubleshooter page.

    Go to Policy Troubleshooter

  2. Enter an email, resource name, and permission to check.

  3. Optional: To check multiple resources and permissions, select Add Another Pair and repeat the previous step.

  4. Click Check API Call.

Understanding Policy Troubleshooter results

Policy Troubleshooter results tell you if the principal has the specified permission on the given resource. They also list the IAM policies that apply to the resource, and the role bindings in those policies.

By default, the results are displayed in Compact view, which only shows role bindings for roles that contain the specified permission. If you are troubleshooting multiple permissions, use the View by drop-down list to switch between them.

You can disable Compact view by clicking the Compact view toggle. Disabling Compact view displays all role bindings in policies that apply to the resource.

The results page contains the following information:

  • Deny policy notice: If a deny policy could impact the access that you're troubleshooting, Policy Troubleshooter displays a notice.

    This notice appears in the following cases:

    • You're troubleshooting a permission that is supported in deny policies, and an existing deny policy affects the resource you're troubleshooting
    • You're troubleshooting a permission that is supported in deny policies, and you don't have permission to view deny policies

    If you don't see this notice, then there are no deny policies affecting the principal's access.

  • Summary of access: A brief summary of the principal's access, based on the relevant IAM allow policies. This information allows you to see whether the principal has the permission on the resource. In the following example, has the logging.logs.view permission on my-project:

  • Relevant policies and role bindings: A list of the IAM allow policies that apply to the given resource, and the role bindings in each policy. Next to each role binding is an icon indicating whether that role binding grants the specified permission to the principal. Click the role binding to see its raw text.

    In the following example, the Logs Viewer role binding grants the permission:

  • Raw text of relevant role bindings: The raw text of each role binding in the list of relevant role bindings. To learn more about the structure of role bindings, see Understanding policies.

    In each role binding, lines are highlighted as follows:

    • Green: Lines are highlighted in green if they contain a role that includes the specified permission, if they refer to the specified principal, or if they refer to a group that contains the specified principal.
    • Red: Lines are highlighted in red if they contain another role, refer to another principal, or refer to a group that does not contain the specified principal.
    • Yellow: Lines are highlighted yellow if they contain a role whose details you don't have permission to view, or a group whose membership you don't have permission to view.


First, ensure your environment is set up to use Policy Troubleshooter.

Enable the Policy Troubleshooter API:

gcloud services enable --project=project-id

Then, set your project:

gcloud config set project project-id

After you complete the setup, you can use Policy Troubleshooter to check whether a user has a permission on a resource. Run the following command:

gcloud policy-troubleshoot iam resource --principal-email=email \

For example, the following command checks if has the resourcemanager.projects.getIamPolicy permission on the project my- project.

gcloud policy-troubleshoot iam // \

The output is YAML indicating whether the user has the permission, and an explanation of why. It should look something like this:

access: GRANTED
- access: GRANTED
  - access: NOT_GRANTED
    role: roles/compute.serviceAgent
  - access: GRANTED
    role: roles/owner
  fullResourceName: //
    - members:
      role: roles/compute.serviceAgent
    - members:
      role: roles/owner
    etag: BwWAOWEaIEg=
    version: 1
policy: {}


To find out why a principal has, or does not have, an IAM permission, use the Policy Troubleshooter API's iam.troubleshoot method.

Before using any of the request data, make the following replacements:

  • email: The email address of the principal whose permissions you want to troubleshoot.
  • resource: The resource on which the permission is granted.
  • permission: The permission that you want to troubleshoot.

HTTP method and URL:


Request JSON body:

  "accessTuple": {
    "principal": "email",
    "fullResourceName": "resource",
    "permission": "permission"

To send your request, expand one of these options:

You should receive a JSON response similar to the following:

  "access": "GRANTED",
  "explainedPolicies": [
      "access": "GRANTED",
      "fullResourceName": "//",
      "policy": {
        "version": 1,
        "etag": "BwWBUZjK9YQ=",
        "bindings": [
            "role": "roles/owner",
            "members": [
      "bindingExplanations": [
          "access": "GRANTED",
          "role": "roles/owner",
          "rolePermission": "ROLE_PERMISSION_INCLUDED",
          "rolePermissionRelevance": "HIGH",
          "memberships": {
            "key": "",
            "value": {
              "membership": "MEMBERSHIP_INCLUDED",
              "relevance": "HIGH",
        "relevance: HIGH",
      "access": "UNKNOWN_INFO_DENIED",
      "policy": {}

Troubleshooting group membership

If your IAM policy contains groups, you can only troubleshoot access for individual group members if you have the Google Workspace Admin API permission Super Admins and Group Admins automatically have this permission. To give a user who is not a Super or Group admin this permission, create a custom Google Workspace administrator role that contains the privilege (located under Admin API Privileges) and grant it to the user.

If you don't have permission, the group is highlighted yellow in the console, and a warning indicates that you don't know whether the group includes the principal. If you're using the gcloud CLI or the REST API, the response contains UNKNOWN_INFO_DENIED or ACCESS_TO_INFO_DENIED.

Troubleshooting group membership

Troubleshooting conditional role bindings

To troubleshoot conditional role bindings, Policy Troubleshooter needs additional context about the request. For example, to troubleshoot conditions based on date/time attributes, Policy Troubleshooter needs the time of the request.

To provide this additional context, you can troubleshoot directly from any Admin Activity audit log or Data Access audit log. Each audit log entry corresponds to a request to a Google Cloud API, or an action that Google Cloud takes on your behalf. When you troubleshoot from an audit log, Policy Troubleshooter automatically gets additional information about the request, such as its date and time, which allows Policy Troubleshooter to analyze conditional role bindings.

This feature is only available in the console.

To troubleshoot conditional role bindings, do the following:

  1. In the console, go to the Logs Explorer page.

    Go to the Logs Explorer

  2. If the page title is Legacy Logs Viewer, click the Upgrade drop-down list and select Upgrade to the new Logs Explorer.

  3. To view only Admin Activity and Data Access audit logs, enter the following query in the query builder, then click Run query:


    Replace the following values:

    • RESOURCE_TYPE: The resource type that you are listing audit logs for. Use projects, folders, or organizations.
    • RESOURCE_ID: The ID of your resource.
  4. Locate the audit log entry that corresponds to the request that you want to troubleshoot. To learn how to use the Logs Explorer to find specific log entries, see Using the Logs Explorer.

  5. In the Summary column of the log entry, click IAM, then click Troubleshoot access issue.

    Policy Troubleshooter uses the information in the log entry to troubleshoot access, then shows you the results. The additional context is listed directly below the summary of access. To learn more about the Policy Troubleshooter results page, see Troubleshooting access on this page.

  6. Optional: To troubleshoot another request that involves conditional role bindings, return to the Logs Explorer page and repeat the previous steps.

What's next