Troubleshoot IAM permissions
Stay organized with collections
Save and categorize content based on your preferences.
Policy Troubleshooter helps you understand whether a principal
can access a resource. Given a principal, a resource, and a permission,
Policy Troubleshooter examines the allow policies, deny policies,
and principal access boundary (PAB) policies that impact the principal's access.
Then, it tells you whether, based on those policies, the principal can use
the specified permission to access the resource. It also lists the relevant
policies and explains how they affect the principal's access.
You can access Policy Troubleshooter using the
Google Cloud console, the Google Cloud CLI, or the REST API. For basic
queries, using the Google Cloud console is typically fastest. For more complex
scenarios, consider the gcloud CLI or the REST API.
Before you begin
Enable the Policy Troubleshooter API.
Roles required to enable APIs
To enable APIs, you need the serviceusage.services.enable permission. If you
created the project, then you likely already have this permission through the
Owner role (roles/owner). Otherwise, you can get this permission through the
Service Usage Admin role (roles/serviceusage.serviceUsageAdmin).
Learn how to grant roles.
To fully troubleshoot your principals' access, you need the following
permissions.
Permissions to troubleshoot access for individual principals
Policy Troubleshooter analyzes a principal's access to a resource
based on the allow policies, deny policies, principal access boundary 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.
Permissions to troubleshoot allow and deny policies
To troubleshoot allow and deny policies, you need permissions on the
organization that contains the resource that you want to troubleshoot. These
permissions let you view the allow and deny policies that control access to the
resource.
To get the permissions that
you need to troubleshoot a principal's access,
ask your administrator to grant you the
following IAM roles on the organization that contains the resource that you want to troubleshoot access for:
If you don't have permission to view the allow and deny policies for a resource,
the access results for those allow and deny policies are Unknown.
Permissions to troubleshoot principal access boundary policies
To troubleshoot principal access boundary policies, you need permissions on the
organization whose principal set includes the principal. The way you identify
this organization depends on the principal type:
Google Accounts and Google groups: The organization associated with the
Google Workspace domain that includes the principal
Federated identities (identities in workforce identity pools or workload
identity pools): The organization that contains the identity pool that
includes the principal
Service accounts: The organization that contains the project where the
service account was created
These permissions let you view the principal access boundary policies that control what
the principal can access.
To get the permissions that
you need to troubleshoot a principal's access,
ask your administrator to grant you the
following IAM roles on the appropriate organization:
Troubleshoot principal access boundary policies bound to a project's, folder's, or organization's principal set:
Organization Administrator (roles/resourcemanager.organizationAdmin)
Troubleshoot principal access boundary policies bound to Google Workspace domains:
Workspace Pool IAM Admin (roles/iam.workspacePoolAdmin)
Troubleshoot principal access boundary policies bound to workforce identity pools:
IAM Workforce Pool Admin (roles/iam.workforcePoolAdmin)
Troubleshoot principal access boundary policies bound to workload identity pools:
IAM Workload Identity Pool Admin (roles/iam.workloadIdentityPoolAdmin)
If you don't have permission to view the principal access boundary policies that apply
to a principal, the access results for principal access boundary policies are
Unknown.
Permissions to troubleshoot access for group members
If your allow and deny policies include groups, you need the Google Workspace
Admin API permission groups.read to troubleshoot access for individual group
members. 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
groups.read privilege (located under Admin API Privileges) and grant it to
the user.
If you don't have these permissions, role bindings and deny rules that contain
groups or domains have an access result of Unknown, unless the role binding
or deny rule also explicitly includes the principal.
Permissions to troubleshoot access for domain members
If your allow and deny policies include a Google Workspace account or
Cloud Identity domain, you must be a domain administrator to troubleshoot
access for individual domain members.
If you don't have these permissions, role bindings and deny rules that contain
groups or domains have an access result of Unknown, unless the role binding
or deny rule also explicitly includes the principal.
Troubleshoot access
To troubleshoot access, you need the principal, resource, and permission you
want to check. This information can be provided by an error ID:
Error ID: A unique identifier for a
permission error message. The error ID provides context
for the error, including the principal, resource, permission, and supported
IAM conditions.
Supported IAM conditions include principal.type and
principal.subject.
If you don't have an error ID, you can troubleshoot access with the following
information:
Principal: The email address to check. The email address must refer to
a user, a single service account, or a service account principal
set.
Other types of principals, including groups, domains, workforce identities,
and workload identities, are not supported.
Resource: The full name of the resource
that you want to troubleshoot access to. For example, to troubleshoot access
to 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
Google Cloud console, it presents a list of suggestions as you type.
To troubleshoot a permission, the permission must be applicable for the
resource in the request. In other words, it must be possible to use that
permission to access the resource in some way. If the permission isn't
applicable for the resource, then the request fails. For example, if you try
to troubleshoot the compute.instances.get permission for a
Google Kubernetes Engine cluster, then the request fails because the
compute.instance.get permission can't be used to access
Google Kubernetes Engine clusters.
Before using any of the command data below,
make the following replacements:
VERSION: Optional. The version of the command to use. To troubleshoot
access based on allow and deny policies only, don't specify a version. To troubleshoot access
based on allow, deny, and principal access boundary policies, use the version beta.
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.
To find out why a principal has, or doesn't have, an IAM permission, use the Policy Troubleshooter API's
iam.troubleshoot
method.
Before using any of the request data,
make the following replacements:
VERSION: The API version to use for this request. To troubleshoot
access based on allow and deny policies only, use v3. To troubleshoot access based
on allow, deny, and principal access boundary policies, use v3beta.
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.
PROJECT_ID: The ID of the project that you want to use to make the request.
Project IDs are alphanumeric strings, like my-project.
HTTP method and URL:
POST https://policytroubleshooter.googleapis.com/VERSION/iam:troubleshoot
Copy the request body and open the
method reference page.
The APIs Explorer panel opens on the right side of the page.
You can interact with this tool to send requests.
Paste the request body in this tool, complete any other required fields, and click Execute.
You should receive a JSON response similar to the following:
The Evaluation details section contains a summary of the access you're
troubleshooting, including the specified principal, resource, and permission. If
you're troubleshooting multiple resource permission pairs, you can use the
Access Evaluation list to switch between them.
Policy details
The Policy details section contains details about how the relevant allow,
deny, and principal access boundary policies affect the principal's access.
Relevant principal access boundary policies include all principal access boundary policies
that are bound
to a principal set that includes the principal.
Relevant allow and deny policies include the following:
The resource's allow policy
The resource's deny policies, if any
The allow policies of the resource's parent project, folder, and
organization, if any
The deny policies of the resource's parent project, folder, and organization,
if any
The allow and deny policies of parent projects, folders, and organizations
are relevant
because of policy inheritance.
When you attach an allow or deny policy to a project, folder, or organization,
that policy also applies for all resources inside that project, folder, or
organization.
For example, if a deny policy for an organization says that a principal can't
use a specific permission, then the principal can't use that permission for any
resource within the organization. This rule applies even if the folders and
projects within that organization have more permissive deny policies, or allow
policies that give the principal the permission.
Similarly, if an allow policy for a project gives a principal a specific
permission, then the principal has that permission for any resource within the
project, provided that they aren't denied that permission.
The Policy details section contains the following sections:
The Access state section summarizes the results for each policy type
(principal access boundary policies, deny policies, and allow policies), and states the
overall outcome. The outcome indicates whether the principal is able to use the
permission to access the resource, according to the relevant policies.
For a user to be able to use the permission to access the resource, all policy
types must permit access. For more information, see Policy
evaluation.
Principal access boundary policy
In the Principal access boundary policy section, you can view all
principal access boundary policies that the principal is subject to, and the policy
bindings that bind these policies to the principal.
The Policies pane lists all policies that are bound to a principal set that
includes the principal. Next to each policy is an icon indicating how that
policy affects the principal's access.
Principal access boundary policies can affect a principal's access in the
following ways:
check_circlePrincipal is eligible to
access the resource: The principal access boundary policy applies to the principal,
and one of its rules contains the queried resource.
errorPrincipal is ineligible to access
the resource: The principal access boundary policy applies to the principal, but
the queried resource isn't in that policy's rules.
do_not_disturb_onNot enforced:
Principal access boundary policies aren't enforced in the following situations:
IAM doesn't enforce the specified permission at the
principal access boundary policy's enforcement
version. As a result, the principal access boundary policy can't block
access.
If a principal access boundary policy isn't enforced, then it can't affect whether
the principal can access the resource.
To view the rules and bindings associated with a principal access boundary policy,
click the policy name. The pane adjacent to the Policies pane displays the
policy's details.
To view the rules in the policy, click the Boundary rules tab. This tab
displays a table of the relevant principal access boundary policy rules.
A principal access boundary rule is relevant if the rule impacts the overall outcome of
the Policy Troubleshooter query. As a result, the relevant rules
vary depending on the Policy Troubleshooter results. For example,
consider the following situations:
Policy Troubleshooter indicates that the principal can access
the resource. As a result, the relevant rules are those that make the
principal eligible to access the resource.
Policy Troubleshooter indicates that the principal can't access
the resource. However, according to the relevant principal access boundary policies,
the principal is eligible to access the resource. As a result, no rules are
relevant, because the principal access boundary policies aren't the reason that the
principal can't access the resource.
Policy Troubleshooter indicates that the principal can't access
the resource. Additionally, according to the relevant principal access boundary
policies, the principal isn't eligible to access the resource. As a result,
the relevant rules are those that don't make the principal eligible to access
the resource.
To view all principal access boundary rules in a policy, clear the Show only relevant
rules and bindings checkbox.
The Findings column in the boundary rules table indicates whether the
principal access boundary rule contains the queried resource. To see more details about
the rule, click See rule details.
To view the policy bindings for the policy, click the Bindings tab. This tab
displays a table of the relevant policy bindings for the selected
principal access boundary policy.
A policy binding is relevant if it effectively applies the principal access boundary
policy to the queried principal. For a policy binding to apply a
principal access boundary policy to a principal, the following must be true:
The principal set in the policy binding must include the queried principal
Any conditions in the policy binding must evaluate to true for the queried
principal.
To view all policy bindings with principal sets that include the queried
principal, regardless of whether the queried principal meets the condition in
the binding, clear the Show only relevant rules and bindings checkbox.
The Findings column in the bindings table indicates whether the binding is
enforced for the queried principal. To see more details about the policy
binding, click See binding details.
Deny policy
In the Deny policy section, you can view all relevant deny policies,
identify deny rules that deny access to the principal, and understand why a deny
rule denies or doesn't deny the principal the permission.
The Resources with deny policies pane lists all relevant deny policies,
organized by the resources they're attached to. Next to each deny policy is an
access evaluation. This evaluation only applies to that deny policy—it
doesn't reflect any access from inherited policies. If you
don't have permission to view a resource's deny policy, the resource list does
not include that resource or its deny policies.
To view the relevant deny rules in these deny policies, click a deny policy. To
view all deny rules in a resource's deny policies, click a resource. The deny
rules appear in the Deny rules pane. This pane contains a table of all deny
rules with the queried principal or permission for the resource or deny policy
you've selected.
The Access column indicates whether the deny rule denies the principal the
permission. To see more details about the deny rule, click See deny rule in
that rule's row.
Allow policy
In the Allow policy section, you can navigate through all relevant allow
policies, identify role bindings that grant access to the principal, and
understand why a role binding gives or doesn't give the principal the
permission.
The Resources pane lists the specified resource and its ancestors. Next to
each resource is an access evaluation. This evaluation only applies to that
resource's allow policy—it doesn't reflect any access from inherited
policies. If you don't have permission to view a resource's
allow policy, the resource list does not include that resource.
To view the relevant role bindings in a resource's allow policy and see
how they do or don't give the principal the permission, click the
resource. The allow policy's role bindings appear in the Role bindings
pane.
The Role bindings pane contains a table of role bindings in the
selected resource's allow policy. By default, the table only contains role
bindings that include a role with the specified permission. If the
principal doesn't have access, the table also shows role bindings with
editable custom roles. To see all role bindings, clear the Show only
relevant bindings checkbox.
The Access column indicates whether the role binding gives the principal the
permission. To see more details about the role binding, click See binding
details in that role binding's row.
gcloud
The response contains four main sections: a description of the access tuple in
the request, the results of the allow policy evaluation, the results of
the deny policy evaluation, and the overall access state.
accessTuple: A description of the access tuple in the request,
including any condition context that you provided. This section also contains
a summary of the tags that
apply to the resource.
allowPolicyExplanation: A summary of whether the relevant allow
policies grant the principal the permission, followed by a list of allow
policies and their role bindings.
For each allow policy, the response lists all role bindings in the policy
and evaluates them based on the following criteria:
Whether the role binding includes the permission.
Whether the role binding includes the principal.
Whether the conditions in the role binding, if any, are met.
Then, the response prints the full JSON text of the allow policy.
denyPolicyExplanation: A summary of whether the relevant deny
policies deny the principal the permission, followed by a list of resources
with deny policies. For each resource, the response lists all deny policies
attached to the resource.
For each deny policy, the response prints the policy's metadata, lists the
deny rules in the policy, then evaluates each rule based on the following
criteria:
Whether the deny rule includes the permission.
Whether the permission is listed as an exception in the deny rule.
Whether the deny rule includes the principal.
Whether the principal is listed as an exception in the deny rule.
Whether the conditions in the deny rule, if any, are met.
overallAccessState: Whether the principal is able to use the
specified permission to access the specified resource based on the relevant
allow policies, deny policies, and principal access boundary policies.
Relevant principal access boundary policies include all principal access boundary policies
that are bound
to a principal set that includes the principal.
Relevant allow and deny policies include the following:
The resource's allow policy
The resource's deny policies, if any
The allow policies of the resource's parent project, folder, and
organization, if any
The deny policies of the resource's parent project, folder, and organization,
if any
The allow and deny policies of parent projects, folders, and organizations
are relevant
because of policy inheritance.
When you attach an allow or deny policy to a project, folder, or organization,
that policy also applies for all resources inside that project, folder, or
organization.
For example, if a deny policy for an organization says that a principal can't
use a specific permission, then the principal can't use that permission for any
resource within the organization. This rule applies even if the folders and
projects within that organization have more permissive deny policies, or allow
policies that give the principal the permission.
Similarly, if an allow policy for a project gives a principal a specific
permission, then the principal has that permission for any resource within the
project, provided that they aren't denied that permission.
For a user to be able to use the permission to access the resource, all
policy types must permit access. For more information, see Policy evaluation.
pabPolicyExplanation: A summary of whether the relevant
principal access boundary policies permit the principal to access the
resource, followed by the relevant principal access boundary policy bindings and
principal access boundary policies.
Principal access boundary policies can either allow access, not allow access,
or not be enforced. Principal access boundary policies aren't enforced in the
following situations:
IAM doesn't enforce the specified permission at the
principal access boundary policy's enforcement
version. As a result, the principal access boundary policy can't block
access.
If a principal access boundary policy isn't enforced, then it can't affect whether
the principal can access the resource.
The response also lists all policy bindings that include the principal, and
the details of the principal access boundary policy in each of those policy
bindings:
For each principal access boundary policy binding, the response prints whether
the policy binding is enforced for the principal, then prints the text of
the policy binding. A policy binding is enforced if the principal set in
the binding includes the queried principal, and if the condition in the
policy binding evaluates to true for the queried principal.
If the policy binding isn't enforced, then the policy can't affect whether
the principal can access the resource.
For each principal access boundary policy, the response prints the following:
Whether the policy allows access, doesn't allow access, or isn't
enforced.
The enforcement version of the policy. This version number
determines whether IAM enforces this
principal access boundary policy for the queried permission. If the
permission isn't enforced, then the policy can't affect whether the
principal can access the resource.
The rules in the principal access boundary policy and whether each rule
allows access. For each rule, the response indicates whether the
queried resource is included in the rule.
A resource is included in a rule if one of the following is true:
The resource is listed in the rule. Only Resource Manager
resources (projects, folders, and organizations) can be directly
listed in principal access boundary rules.
One of the resource's ancestors (that is, a project, folder, or
organization above the resource in the resource
hierarchy) is listed in the rule.
Many objects in the response also have a relevance field. The value in this
field indicates how much that object contributes to the overall access state.
The relevance field can have the following values:
HEURISTIC_RELEVANCE_HIGH: Indicates that the object has a strong impact on
the result. In other words, removing the object will likely change the overall
access state. For example, a role binding that grants the principal the
specified permission would have this relevance value.
HEURISTIC_RELEVANCE_NORMAL: Indicates that the object has a limited impact
on the result. In other words, removing the object is unlikely to change the
overall access state. For example, a deny rule that doesn't contain the
permission or the principal would have this relevance value.
REST
The response contains four main sections: the overall access state, a
description of the access tuple in the request, the results of the allow policy
evaluation, and the results of the deny policy evaluation.
overallAccessState: Whether the principal is able to use the
specified permission to access the specified resource based on the relevant
allow policies, deny policies, and principal access boundary policies.
Relevant principal access boundary policies include all principal access boundary policies
that are bound
to a principal set that includes the principal.
Relevant allow and deny policies include the following:
The resource's allow policy
The resource's deny policies, if any
The allow policies of the resource's parent project, folder, and
organization, if any
The deny policies of the resource's parent project, folder, and organization,
if any
The allow and deny policies of parent projects, folders, and organizations
are relevant
because of policy inheritance.
When you attach an allow or deny policy to a project, folder, or organization,
that policy also applies for all resources inside that project, folder, or
organization.
For example, if a deny policy for an organization says that a principal can't
use a specific permission, then the principal can't use that permission for any
resource within the organization. This rule applies even if the folders and
projects within that organization have more permissive deny policies, or allow
policies that give the principal the permission.
Similarly, if an allow policy for a project gives a principal a specific
permission, then the principal has that permission for any resource within the
project, provided that they aren't denied that permission.
For a user to be able to use the permission to access the resource, all
policy types must permit access. For more information, see Policy evaluation.
accessTuple: A description of the access tuple in the request,
including any condition context that you provided. This section also contains
a summary of the tags that
apply to the resource.
allowPolicyExplanation: A summary of whether the relevant allow
policies grant the principal the permission, followed by a list of allow
policies and their role bindings.
For each allow policy, the response lists all role bindings in the policy
and evaluates them based on the following criteria:
Whether the role binding includes the permission.
Whether the role binding includes the principal.
Whether the conditions in the role binding, if any, are met.
Then, the response prints the full JSON text of the allow policy.
denyPolicyExplanation: A summary of whether the relevant deny
policies deny the principal the permission, followed by a list of resources
with deny policies. For each resource, the response lists all deny policies
attached to the resource.
For each deny policy, the response prints the policy's metadata, lists the
deny rules in the policy, then evaluates each rule based on the following
criteria:
Whether the deny rule includes the permission.
Whether the permission is listed as an exception in the deny rule.
Whether the deny rule includes the principal.
Whether the principal is listed as an exception in the deny rule.
Whether the conditions in the deny rule, if any, are met.
pabPolicyExplanation: A summary of whether the relevant
principal access boundary policies permit the principal to access the
resource, followed by the relevant principal access boundary policy bindings and
principal access boundary policies.
Principal access boundary policies can either allow access, not allow access,
or not be enforced. Principal access boundary policies aren't enforced in the
following situations:
IAM doesn't enforce the specified permission at the
principal access boundary policy's enforcement
version. As a result, the principal access boundary policy can't block
access.
If a principal access boundary policy isn't enforced, then it can't affect whether
the principal can access the resource.
The response also lists all policy bindings that include the principal, and
the details of the principal access boundary policy in each of those policy
bindings:
For each principal access boundary policy binding, the response prints whether
the policy binding is enforced for the principal, then prints the text of
the policy binding. A policy binding is enforced if the principal set in
the binding includes the queried principal, and if the condition in the
policy binding evaluates to true for the queried principal.
If the policy binding isn't enforced, then the policy can't affect whether
the principal can access the resource.
For each principal access boundary policy, the response prints the following:
Whether the policy allows access, doesn't allow access, or isn't
enforced.
The enforcement version of the policy. This version number
determines whether IAM enforces this
principal access boundary policy for the queried permission. If the
permission isn't enforced, then the policy can't affect whether the
principal can access the resource.
The rules in the principal access boundary policy and whether each rule
allows access. For each rule, the response indicates whether the
queried resource is included in the rule.
A resource is included in a rule if one of the following is true:
The resource is listed in the rule. Only Resource Manager
resources (projects, folders, and organizations) can be directly
listed in principal access boundary rules.
One of the resource's ancestors (that is, a project, folder, or
organization above the resource in the resource
hierarchy) is listed in the rule.
Many objects in the response also have a relevance field. The value in this
field indicates how much that object contributes to the overall access state.
The relevance field can have the following values:
HEURISTIC_RELEVANCE_HIGH: Indicates that the object has a strong impact on
the result. In other words, removing the object will likely change the overall
access state. For example, a role binding that grants the principal the
specified permission would have this relevance value.
HEURISTIC_RELEVANCE_NORMAL: Indicates that the object has a limited impact
on the result. In other words, removing the object is unlikely to change the
overall access state. For example, a deny rule that doesn't contain the
permission or the principal would have this relevance value.
Troubleshooting conditional role bindings
Policy Troubleshooter automatically troubleshoots conditional
role bindings and deny rules based on tags. It also
automatically troubleshoots principal access boundary policy bindings with conditions
based on principals.
To troubleshoot other kinds of conditional role bindings or
conditional deny rules, 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.
In the gcloud CLI and REST API, you provide this additional context
manually.
In the Google Cloud console, you can provide this additional context by
troubleshooting 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 and
deny rules.
Console
To troubleshoot conditional role bindings and deny rules, do the following:
In the Google 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. Use projects, folders, or organizations.
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 in the evaluation details under Condition context. To view the
context details, click View condition context. To learn more about the
Policy Troubleshooter results page, see Understand
Troubleshooter results on this page.
Optional: To troubleshoot another request that involves conditional role
bindings and deny rules, return to the Logs Explorer page and repeat the
previous steps.
Before using any of the command data below,
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.
DESTINATION_IP: Optional. The request destination IP
address to use when checking conditional role bindings. For example,
198.1.1.1.
DESTINATION_PORT: Optional. The request destination
port to use when checking conditional role bindings. For example, `8080`.
REQUEST_TIME: Optional. The request timestamp to use
when checking conditional role bindings. Use a timestamp in RFC
3339format—for example, 2099-02-01T00:00:00Z.
RESOURCE_NAME: Optional. The resource name value to
use when checking conditional role bindings. For a list of accepted resource
name formats, see Resource name
format.
RESOURCE_SERVICE: Optional. The resource service
value to use when checking conditional role bindings. For a list of accepted
service names, see Resource
service values.
RESOURCE_TYPE: Optional. For a list of accepted
resource types, see Resource type
values.
The response contains an explanation of the principal's access. For each role
binding and deny rule with a condition, the response includes a
conditionExplanation field describing whether the condition
evaluates to true or false based on the condition context that you provided.
For example, the following is an evaluation of a role binding with a condition specifying the
resource type and resource service:
To troubleshoot conditional role bindings and deny rules, 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.
DESTINATION_IP: Optional. The request destination IP
address to use when checking conditional role bindings. For example,
198.1.1.1.
DESTINATION_PORT: Optional. The request destination
port to use when checking conditional role bindings. For example, `8080`.
REQUEST_TIME: Optional. The request timestamp to use
when checking conditional role bindings. Use a timestamp in RFC
3339format—for example, 2099-02-01T00:00:00Z.
RESOURCE_NAME: Optional. The resource name value to
use when checking conditional role bindings. For a list of accepted resource
name formats, see Resource name
format.
RESOURCE_SERVICE: Optional. The resource service
value to use when checking conditional role bindings. For a list of accepted
service names, see Resource
service values.
RESOURCE_TYPE: Optional. For a list of accepted
resource types, see Resource type
values.
HTTP method and URL:
POST https://policytroubleshooter.googleapis.com/v3/iam:troubleshoot
Copy the request body and open the
method reference page.
The APIs Explorer panel opens on the right side of the page.
You can interact with this tool to send requests.
Paste the request body in this tool, complete any other required fields, and click Execute.
The response contains an explanation of the principal's access. For each role
binding and deny rule with a condition, the response includes a
conditionExplanation field describing whether the condition
evaluates to true or false based on the condition context that you provided.
For example, the following is an evaluation of a role binding with a condition specifying the
resource type and resource service:
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2026-07-17 UTC."],[],[]]