Auditing IAM Access with Policy Intelligence

IAM Recommender is a Policy Intelligence feature that helps enforce least privilege by finding role bindings that grant more permissions than a principal actually uses. The goal is to move principals from broad roles to tightly scoped roles that match real usage, which closes security gaps from excess permissions. Recommendations and insights provide the evidence for the change, including what was observed and what impact the change will have.

1.1How IAM Recommender Supports Least Privilege

IAM Recommender compares the permissions inside a granted role with the permissions a principal actually used during an observation period. When a principal consistently uses only a subset of the granted permissions, the recommender flags excess permission and suggests a less-privileged replacement role. The binding owner then reviews the observation evidence and impact metrics, applies the tighter role, and monitors for access failures. This review-then-apply order matters because removing a permission that is needed seasonally or for emergency break-glass work can disrupt production operations.

1.2Using Recommendations with Federated Identities

IAM Recommender has a strict boundary for federated identities that use Workforce Identity Federation (opens in a new tab). Workforce Identity Federation users cannot view recommendations in the federated console, and federated identities cannot call the Recommender API at recommender.googleapis.com. Data does not flow from the recommender to a federated caller through either path, so least-privilege review must be performed with a non-federated Google Cloud identity that has the required recommender permissions. Choose a non-federated auditor or administrator identity when the task is to list, review, or apply role recommendations.

1.3Related Policy Intelligence Limits That Affect Least-Privilege Work

Related Policy Intelligence limits affect least-privilege work because teams often need to validate effective access before reducing a role, and federated callers face parallel restrictions:

• Policy Troubleshooter cannot check Google group membership in allow and deny policies, or Cloud Identity domain membership in deny policies, for federated callers to iam.troubleshoot; affected bindings return an access result of Unknown unless the principal is also explicitly included.
• Policy Analyzer returns incomplete results for federated callers to analyzeIamPolicy and analyzeIamPolicyLongrunning because group-derived permissions are omitted and the expand-groups option cannot be enabled.
• Policy Analyzer move analysis is unavailable to federated identities because the analyzeMove method cannot be used.
• Policy Simulator is unavailable to federated identities because the Policy Simulator API at policysimulator.googleapis.com cannot be used.
• Activity Analyzer is unavailable to federated identities because the Policy Analyzer API at policyanalyzer.googleapis.com cannot be used.

These limits mean a federated reviewer may not see group-inherited access, may not be able to simulate a tighter policy, and may not be able to retrieve activity-based evidence through the API.

Policy Analyzer is a Policy Intelligence capability that audits who has access to what in Google Cloud. Policy Analyzer runs structured queries across the organization, folder, and project hierarchy to determine which principals have effective permissions on a specific asset. Effective access includes direct grants on the resource plus inherited grants from ancestors, so an audit must trace the full path from principal through roles and bindings to the target.

2.1Effective Access Across the Resource Hierarchy

Effective access in Google Cloud is the union of all Identity and Access Management (IAM) bindings that apply to a resource through inheritance. A principal can receive access at the same time from an organization-level binding, a folder-level binding, and a project-level binding, and Policy Analyzer resolves all three layers into one complete permission set. This hierarchy-aware view is required because a user with no direct binding on a bucket or dataset can still act through an inherited role granted higher in the tree. Auditing therefore starts from the target asset, expands upward through its ancestors, and maps each applicable binding back to the principal that holds it.

Operational control and data access are separated by design, which makes hierarchy-wide auditing essential. A cloud engineering group may provision the ability to run a Dataflow job or manage infrastructure as an environmental concern, while access to the underlying data is granted independently. Policy Analyzer bridges that separation by showing both the operational path and the data path that reach the same asset, so reviewers can detect when broad operational rights unintentionally create data access.

2.2Direct, Inherited, and Conditional Authorization Paths

An authorization path in Policy Analyzer is the chain that connects a principal to a permission on an asset through a role binding at a specific hierarchy level. Direct paths originate from bindings placed on the asset itself, such as an IAM policy on a Cloud Storage bucket or managed folder or on a BigQuery dataset. Inherited paths originate from bindings on a parent organization, folder, or project and flow downward to every child resource, which means revoking access often requires changing the ancestor binding rather than the resource binding.

Conditions and boundaries further shape whether a path is usable. IAM policies with conditions restrict granular access to data, models, and configurations such as code, resource settings, and hyperparameters based on attributes like tags or request context. Principal access boundary (PAB) policies limit which resources a principal can reach even when a role would otherwise allow broader access. A complete audit must therefore report the role and resource, the level where the binding exists, any condition attached to the binding, and any boundary policy that constrains the principal.

2.3Complex Paths with Custom Roles, Service Accounts, and Google Groups

Complex authorization paths in Policy Analyzer arise when access flows through custom roles, service accounts, and Google Groups instead of a single direct user binding. Custom roles provide flexibility beyond predefined roles by bundling only the permissions a job needs, while BigQuery (opens in a new tab) row-level security, column-level security, and column data masking create application-level paths that control access inside tables. Policy Analyzer must expand group membership, resolve the permission set inside each custom role, and evaluate table-level and finer-grained controls together to determine what a principal can actually read or modify.

Service accounts create machine-mediated paths where workloads authenticate with the credentials of the service account attached to the compute resource, such as a Compute Engine virtual machine (VM) instance. The service account receives project access through a role binding, and a human reaches the workload by holding permission to use or impersonate that service account, so the full path flows from the user to the service account to the target resource. Google Groups adds another indirection because the binding names the group while the effective principal is each member, including nested groups used for employee, contractor, or support-team access.

The creation of a service account path follows an ordered sequence that Policy Analyzer later reverses during an audit:

1. Create identity: Create the service account with the Google Cloud CLI, which establishes a distinct serviceAccount: member identity.
2. Grant resource access: Bind a predefined role or custom role to the service account on the project or resource, which defines what the workload itself can access.
3. Delegate use: Grant the roles/iam.serviceAccountUser role to the human or group allowed to attach the service account to other resources, which defines who can act through the identity.
4. Attach to compute: Attach the service account when creating the resource that runs the code, which activates the path from the compute resource to the target APIs and data.

2.4Enforcing Least Privilege and Detecting Security Risk

Role-based access control with least privilege requires that every principal hold only the minimum permissions needed for its role, expressed as no-access, read-only, or write. Policy Analyzer supports least-privilege reviews by exposing over-broad paths, such as production service accounts holding Owner, Editor, or Viewer roles instead of narrowly scoped predefined roles or custom roles. Finding those paths allows teams to replace broad grants with granular mappings based on project needs, access patterns, or tags, which helps prevent data theft, preserve model integrity, and limit the surface for accidents or attacks.

Granular implementation options give auditors concrete alternatives to broad grants:

• Map IAM roles for different products to a user, group, or service account based on project needs, access patterns, or tags.
• Set IAM policies with conditions to control access to data, models, and model configurations.
• Apply application-level controls, including IAM policies on Cloud Storage buckets and managed folders and IAM roles plus row-level and column-level controls in BigQuery.

When a risky path is found, remediation follows the binding that created it: remove the member from the group, replace the custom role definition, add a condition, or apply a PAB policy to constrain the principal. Approved access requests and administrative activity are recorded in Cloud Audit Logs and, for Google personnel support, in Access Transparency logs, so the audit trail validates whether the effective permissions shown by Policy Analyzer match actual usage and business justification.

Simulating policy changes and troubleshooting access discrepancies are two complementary Policy Intelligence controls for enforcing least privilege. Policy Simulator replays recent access activity against a proposed allow policy before deployment, while Policy Troubleshooter evaluates why a specific principal does or does not have a permission on a resource under current allow and deny policies.

3.1Policy Simulator Function and Scope

Policy Simulator is the Policy Intelligence tool that validates the impact of a proposed change to an allow policy before the change is applied. The simulator compares the current allow policy as the baseline against the simulated proposed policy, and reports only access attempts from the last 90 days that would have a different outcome. This comparison prevents unintended permission grants and service disruptions by showing which historical accesses would be granted, revoked, or left unchanged.

A simulation is scoped to one resource whose allow policy is being changed. The Policy Simulator results page identifies that resource and separates the proposal into roles proposed to be added and roles proposed to be removed. The result set then shows the access differences caused by that specific addition and removal, not the full effective access of the principal.

3.2Policy Troubleshooter Function and Scope

Policy Troubleshooter is the Policy Intelligence tool that diagnoses access denials and unexpected allowances for a specific principal, permission, and resource. The troubleshooter evaluates effective access by checking role bindings in allow policies and deny rules in deny policies, including whether the principal gains access directly or through membership in a Google group or Cloud Identity domain. When called through the API, the evaluation runs through the iam.troubleshoot method and returns a per-binding or per-rule access result.

A result of Unknown means the troubleshooter could not resolve membership, not that access was granted or denied. For federated identities, role bindings and deny rules that contain groups or domains return Unknown unless the role binding or deny rule also explicitly includes the principal. An explicit principal entry therefore remains evaluable even when group and domain expansion is unavailable.

3.3Understanding Policy Simulator Output

Policy Simulator output is a list of access changes plus a separate list of simulation errors. Each access change centers on an access tuple that names the principal, the permission, and the full resource name, such as //cloudresourcemanager.googleapis.com/projects/my-project with permission resourcemanager.projects.update for my-user@example.com. The tuple is accompanied by a lastSeenDate for when that access was last observed and a diff object that contrasts the baseline access state with the simulated access state.

The diff object makes the direction of change explicit through the source state and the destination state. For example, an accessChange of ACCESS_REVOKED means access flows from a baseline state of GRANTED under the current policy to a simulated state of NOT_GRANTED under the proposed policy. Large result sets are paginated with a nextPageToken, and if there was no change in access between the existing and simulated policies, the request returns an empty list ({}).

Errors identify gaps where the simulation could not evaluate part of the proposal. A common error is code 12 with reason UNSUPPORTED_RESOURCE from domain policysimulator.googleapis.com, meaning the simulator does not yet support all resource types for the listed permissions. Documented examples include storage.objects.create, storage.objects.get, storage.objects.list, storage.objects.update, storage.objects.delete, storage.objects.getIamPolicy, storage.objects.setIamPolicy, and pubsub.topics.publish.

3.4Federated Identity Limitations for Simulation and Troubleshooting

Federated identity limitations for simulation and troubleshooting differ between the Workforce Identity Federation (opens in a new tab) console and the Google Cloud API. Workforce Identity Federation users face full blocks in the federated console, while federated identities calling the APIs face partial evaluation or full blocks depending on the tool.

Because of these boundaries, a federated operator must perform simulation and full troubleshooting from a non-federated identity with access to the standard console or API. The restriction sits between the federated caller on one side and the group, domain, and simulator services on the other side, so troubleshooting from a federated context can confirm direct grants but cannot reliably rule out access granted through groups or domains.

Key Facts

• IAM Recommender supports least privilege by identifying principals that use only a subset of granted permissions and recommending a tighter replacement role.
• Federated identities cannot call the Recommender API at recommender.googleapis.com and cannot view recommendations in the federated console.
• Policy Analyzer determines effective access on an asset by resolving direct bindings plus permissions inherited from organization, folder, and project ancestors.
• Policy Simulator compares a current allow policy against a proposed policy and reports only access attempts from the last 90 days with a different outcome.
• Policy Troubleshooter returns Unknown when it cannot resolve group or domain membership, including for federated callers to iam.troubleshoot unless the principal is explicitly included.