Policy troubleshooter in GCP - Step-by-Step Execution

Process Flow - Policy troubleshooter

Start: User requests access check

↓

Input: User, Resource, Permission

↓

Policy Troubleshooter evaluates policies

↓

Check IAM policies on resource

↓

Check inherited policies

↓

Determine if access is allowed or denied

↓

Output: Access decision and explanation

The Policy Troubleshooter takes a user, resource, and permission as input, checks all relevant IAM policies including inherited ones, and outputs whether access is allowed or denied with reasons.

Execution Sample

GCP

gcloud policy-troubleshooter iam troubleshoot \
  --principal=user:[e-mail] \
  --permission=storage.buckets.get \
  --resource=//storage.googleapis.com/projects/_/buckets/my-bucket

This command checks if user Alice has permission to get the bucket 'my-bucket' and explains the access decision.

Process Table

Step	Action	Input	Evaluation	Result
1	Receive request	User=[e-mail], Permission=storage.buckets.get, Resource=my-bucket	Parse inputs	Inputs validated
2	Check direct IAM policies	Policies on my-bucket	Is user granted permission directly?	No direct grant found
3	Check inherited policies	Policies on project and organization	Is permission granted via inheritance?	Permission granted via project-level role
4	Evaluate deny policies	Any deny policies applicable?	No deny policies found	No denies
5	Make access decision	Based on grants and denies	Access allowed	Access allowed
6	Output result	Access allowed with explanation	Generate explanation	User has permission via project role

💡 Access decision made after evaluating all relevant policies and inheritance

Status Tracker

Variable	Start	After Step 2	After Step 3	After Step 4	Final
access_granted	false	false	true	true	true
deny_found	false	false	false	false	false
explanation	""	""	"Permission granted via project role"	"Permission granted via project role"	"Permission granted via project role"

Key Moments - 2 Insights

Why does the troubleshooter check inherited policies after direct policies?

Because permissions can be granted not only directly on the resource but also inherited from higher-level resources like projects or organizations, as shown in execution_table rows 2 and 3.

What happens if a deny policy is found during evaluation?

If a deny policy applies, it overrides any grants and access is denied. In this example, no deny policies were found (row 4), so access was allowed.

Visual Quiz - 3 Questions

Look at the execution table, at which step is the access decision made?

A Step 5

B Step 3

C Step 2

D Step 6

💡 Hint

Check the 'Action' and 'Result' columns in the execution_table for when 'Access allowed' is determined.

According to the variable tracker, what is the value of 'deny_found' after step 4?

A true

B undefined

C false

D null

💡 Hint

Look at the 'deny_found' row under 'After Step 4' in variable_tracker.

If a deny policy was found at step 4, how would 'access_granted' change?

A It would remain true

B It would change to false

C It would become undefined

D It would toggle between true and false

💡 Hint

Refer to key_moments explanation about deny policies overriding grants.

Concept Snapshot

Policy Troubleshooter checks if a user has permission on a resource.
Input: user, resource, permission.
Checks direct and inherited IAM policies.
Considers deny policies that override grants.
Outputs access allowed or denied with explanation.

Full Transcript

The Policy Troubleshooter in Google Cloud takes a user, a resource, and a permission as input. It first checks if the user has the permission directly on the resource. If not found, it checks inherited policies from higher-level resources like projects or organizations. It also looks for any deny policies that would block access. After evaluating all policies, it decides if access is allowed or denied and provides an explanation. This process helps understand why a user can or cannot access a resource.