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 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:
In the Cloud Console, go to the Policy Troubleshooter page.
Enter an email, resource name, and permission to check.
Optional: To check multiple resources and permissions, select Add Another Pair and repeat the previous step.
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 thelogging.logs.view
permission onmy-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
.
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.
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 Cloud Console.
To troubleshoot conditional role bindings, do the following:
In the Cloud Console, go to the Logs Explorer page.
If the page title is Legacy Logs Viewer, click the Upgrade drop-down list and select Upgrade to the new Logs Explorer.
To view only Admin Activity and Data Access audit logs, enter the following query in the query builder, then click Run query:
logName=("RESOURCE_TYPE/RESOURCE_ID/logs/cloudaudit.googleapis.com%2Factivity" OR "RESOURCE_TYPE/RESOURCE_ID/logs/cloudaudit.googleapis.com%2Fdata_access")
Replace the following values:
RESOURCE_TYPE
: The resource type that you are listing audit logs for. Useprojects
,folders
, ororganizations
.RESOURCE_ID
: The ID of your resource.
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.
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.
Optional: To troubleshoot another request that involves conditional role bindings, return to the Logs Explorer page and repeat the previous steps.
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.