Troubleshooting access

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 will examine all Identity and Access Management (IAM) policies that apply to the resource. It then reveals whether the member's roles include the permission on that resource and, if so, which policies bind the member to those roles.

You can access Policy Troubleshooter using the Cloud Console, the gcloud command-line tool, or the REST API. For simple queries, using the Cloud Console is typically fastest. For more complex scenarios, consider the gcloud tool or the REST 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 fully troubleshoot a principal's access, you need a role that includes the following permissions:

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

To gain these permissions while following the principle of least privilege, ask your administrator to grant you the Security Reviewer role (roles/iam.securityReviewer) at the organization level.

Alternatively, your administrator can grant you a different role with the required permissions, such as a custom role or a more permissive predefined role.

Troubleshooting access

To troubleshoot access, you'll need the following information:

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

Console

Troubleshooting access

To troubleshoot access, do the following:

  1. In the Cloud 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:

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

  • Relevant policies and role bindings: A list of the IAM 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.

gcloud

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

Enable the Policy Troubleshooter API:

gcloud services enable policytroubleshooter.googleapis.com --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 \
    --permission=permission

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

gcloud policy-troubleshoot iam //cloudresourcemanager.googleapis.com/projects/my-project \
    --permission=resourcemanager.projects.getIamPolicy --principal-email=foo@example.com

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

access: GRANTED
explainedPolicies:
- access: GRANTED
  bindingExplanations:
  - access: NOT_GRANTED
    memberships:
      serviceAccount:service-123@compute-system.iam.gserviceaccount.com: MEMBERSHIP_NOT_INCLUDED
    role: roles/compute.serviceAgent
    rolePermission: ROLE_PERMISSION_NOT_INCLUDED
  - access: GRANTED
    memberships:
      serviceAccount:service@my-project.iam.gserviceaccount.com: MEMBERSHIP_NOT_INCLUDED
      user:foo@example.com: MEMBERSHIP_INCLUDED
    role: roles/owner
    rolePermission: ROLE_PERMISSION_INCLUDED
  fullResourceName: //cloudresourcemanager.googleapis.com/projects/my-project
  policy:
    bindings:
    - members:
      - serviceAccount:service-123@compute-system.iam.gserviceaccount.com
      role: roles/compute.serviceAgent
    - members:
      - serviceAccount:foo@my-project.iam.gserviceaccount.com
      - user:foo@example.com
      role: roles/owner
    etag: BwWAOWEaIEg=
    version: 1
- access: UNKNOWN_INFO_DENIED
policy: {}

REST API

The iam.troubleshoot method tells you why a member has, or does not have, an IAM permission.

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

  • email: The email address of the member 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:

POST https://policytroubleshooter.googleapis.com/v1/iam:troubleshoot

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": "//cloudresourcemanager.googleapis.com/projects/my-project",
      "policy": {
        "version": 1,
        "etag": "BwWBUZjK9YQ=",
        "bindings": [
          {
            "role": "roles/owner",
            "members": [
              "user:foo@example.com"
            ]
          }
        ]
      },
      "bindingExplanations": [
        {
          "access": "GRANTED",
          "role": "roles/owner",
          "rolePermission": "ROLE_PERMISSION_INCLUDED",
          "rolePermissionRelevance": "HIGH",
          "memberships": {
            "key": "user:foo@example.com",
            "value": {
              "membership": "MEMBERSHIP_INCLUDED",
              "relevance": "HIGH",
            }
          },
        "relevance: HIGH",
        }
      ]
    },
    {
      "access": "UNKNOWN_INFO_DENIED",
      "policy": {}
    }
  ]
}

Troubleshooting group membership

You can only troubleshoot access to a resource given by a Google group if you have permission to view its members.

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

Troubleshooting group membership

Google Workspace Super Admins and Group Admins typically have access to view group membership. To allow a user who is not a Super or Group admin to troubleshoot access, create a custom Google Workspace administrator role that contains the groups.read privilege (located under Admin API Privileges) and grant it to the user. This allows them to view the membership of all groups within your domain, and more effectively troubleshoot access.

What's next

Use the permissions reference or the predefined roles reference to determine which role to grant to a user who is missing permissions.