Policy Analyzer for allow policies lets you find out which principals(for example, users, service accounts, groups, and domains) have what access towhich Google Cloud resources based on yourIAM allowpolicies.

Policy Analyzer for allow policies can help you answer questions likethese:

• Who can access this IAM service account?
• Who can read data in this BigQuery dataset that contains personallyidentifiable information (PII)?
• What roles and permissions does thedev-testers group have on anyresource in this project?
• What Compute Engine virtual machine (VM) instances can Tal delete in projectA?
• Who can access this Cloud Storage bucket at 7 PM?

How Policy Analyzer for allow policies works

To use Policy Analyzer for allow policies, you create an analysisquery, specify a scope for the analysis, and then run the query.

Analysis queries

To use Policy Analyzer, you create ananalysis query specifying oneor more of the following fields:

• Principals: The identities (for example, users, service accounts, groups,and domains) whose access you want to check
• Access: The permissions and roles that you want to check for
• Resources: The resources that you want to check for access to
• (API only) Condition context: The context—for example, time ofday—under which you want to check for access

Typically, you specify one or two of these fields in the analysis query, thenuse the query results to get more information about the fields that you didn'tspecify. For example, if you wanted to know who has a certain permission on acertain resource, you would specify the access and resource in the analysisquery, but you would not specify the principal.

For more examples of the kinds of queries you can create, seeCommon querytypes.

Analysis scope

To run an analysis query, you need to specify ascope toanalyze. The scope is an organization, a folder, or a project that you want torestrict your analysis to. Only IAM allow policies attached tothe resource used as the scope and to its descendants will be analyzed.

In the REST API and gcloud CLI, you specify the scope manually. Inthe Google Cloud console, the scope is automatically determined based on theproject, folder, or organization that you're managing.

After you create an analysis query and specify the scope, you canrun thequery to analyze policies in that scope.

Query results

When you run an analysis query, Policy Analyzer reports anyrolebindings that contain the principals, access, and resources thatyou specified in the query. For each role binding, it reports the principals inthe binding, the access (role and permissions) that the binding grants, andthe resource that the binding grants access to.

You can review these results to better understand access in your project,folder, or organization. For example, if you ran a query to find out whichprincipals have access to a specific resource, you would review the principalsin the query results.

You can adjust the information in your query results by enablingqueryoptions.

Supported policy types

Policy Analyzer for allow policies only supportsIAMallowpolicies.

Policy Analyzer for allow policies doesn't support the following forms of accesscontrol:

• IAM deny policies
• IAM principal access boundary policies
• Google Kubernetes Engine role-based access control
• Cloud Storage access control lists
• Cloud Storage public access prevention

Policy Analyzer query results don't account for unsupported policytypes. For example, imagine that a user has theiam.roles.get permission on aproject because of an allow policy, but a deny policy prevents them from usingthe permission. Policy Analyzer will report that they have theiam.roles.get permission, despite the deny policy.

Policy inheritance

To account forpolicy inheritance,Policy Analyzer automatically analyzes all relevant allow policieswithin the specified scope, regardless of where they are in theresourcehierarchy.

For example, imagine you're trying to find out who can access anIAM service account:

• If you scope the query to a project, Policy Analyzer analyzesthe allow policy of the service account and the allow policy of the project.
• If you scope the query to an organization, Policy Analyzer analyzesthe allow policy of the service account, the allow policy of the project thatowns the service account, the allow policies of any folders containing theproject, and the allow policy of the organization.

Conditional access

If a role binding has acondition, it only grants a principalaccess when that condition is met. Policy Analyzer always reportsconditions that are attached to relevant role bindings. Relevant role bindingsare role bindings that contain the principals, access, and resources that youspecified in the analysis query.

In some cases, Policy Analyzer can also analyze the condition, meaningthat it can report whether the condition would be met. Policy Analyzercan analyze the following types of conditions:

• Conditions based onresource attributes,for resource types that provide aresource name.
• Date/time conditions (API and gcloud CLIonly). For Policy Analyzer to analyze these conditions, you need toprovide the time of the access (accessTime) in your analysis query. To learnhow to provide this context, seeDetermine access at a specifictime.

If a relevant role binding contains a condition, Policy Analyzer doesone of the following:

• If Policy Analyzer can analyze the condition, it does one of thefollowing:

  • If the condition evaluates to true, Policy Analyzer includes therole binding in the query results and marks the condition evaluation asTRUE.
  • If the condition evaluates to false, Policy Analyzer does notinclude the role in the query results.

• If Policy Analyzer can't analyze a condition for a relevant rolebinding, it includes the role in the query results and marks the conditionevaluation asCONDITIONAL.

Data freshness

Policy Analyzer uses the Cloud Asset API, which offers best-effort data freshness.While almost all policy updates appear in Policy Analyzer in minutes, it'spossible that Policy Analyzer won't include the most recent policy updates.

Common query types

This section describes how to use analysis queries to answer commonaccess-related questions.

Which principals can access this resource?

To determine which principals can access a resource, create an analysis querythat specifies the resource and, optionally, the roles and permissions that youwant to check for.

These queries can help you answer questions like the following:

• Who has access to this IAM service account?
• Who has permission to impersonate this IAM serviceaccount?
• Who are the billing administrators on project A?
• (API and gcloud CLI only): Who can update project A byimpersonating a service account?

To learn how to create and send these queries, seeDetermine which principalscan access a resource.

Which principals have these roles and permissions?

To determine which principals have certain roles and permissions, createan analysis query that specifies a principal and a set of roles and permissionsthat you want to check for.

These queries can help you answer questions like the following:

• Who has permission to impersonate service accounts in my organization?
• Who are the billing administrators in my organization?
• Who can read data in this BigQuery dataset that containspersonally identifiable information (PII)?
• (API and gcloud CLI only): Who in my organization can read aBigQuery dataset by impersonating a service account?

To learn how to create and send these queries, seeDetermine which principalshave certain roles or permissions.

What roles and permissions does this principal have on this resource?

To determine what roles and permissions a principal has on a specific resource,create an analysis query that specifies a principal and a resource thatyou want to check for permissions on.

These queries can help you answer questions like the following:

• What roles and permissions does user Sasha have on thisBigQuery dataset?
• What roles and permissions does thedev-testers group have on anyresource in this project?
• (API and gcloud CLI only): What roles and permissions does theuser Dana have on this BigQuery dataset if Danaimpersonates a service account?

To learn how to create and send these queries, seeDetermine what access aprincipal has on a resource.

Which resources can this principal access?

To determine what resources a specific principal can access, create an analysisquery that specifies a principal and the roles and permissions that you want tocheck for.

These queries can help you answer questions like the following:

• Which BigQuery datasets does the user Mahan havepermission to read?
• Which BigQuery datasets is thedev-testers group thedata owner of?
• What VMs can Tal delete in project A?
• (API and gcloud CLI only): What VMs can the user John deleteby impersonating a service account?

To learn how to create and send these queries, seeDetermine which resources aprincipal can access.

Saved analysis queries

If you're using the REST API, you can save analysis queries to reuse or sharewith others. You can run a saved query just like you would run any other query.

To learn more about saving queries, seeManage saved queries.

Export query results

You can run queries asynchronously and export query results toBigQuery or Cloud Storage by usinganalyzeIamPolicyLongrunning.

To learn how to export query results to BigQuery, seeWritepolicy analysis to BigQuery.

To learn how to export query results to Cloud Storage, seeWritepolicy analysis to Cloud Storage.

Query options

Policy Analyzer offers several options that add more details to yourqueryresults.

To learn how to enable these options, seeEnable options.

Group expansion

If you enable group expansion, any groups in the query results areexpanded into individual members. This expansion is capped at1,000 members per group. If you havesufficient group permissions, nested groups will also be expanded. This optionis only effective if you don't specify a principal in your query.

For example, imagine you enable group expansion for the query "Who has thestorage.buckets.delete permission forproject-1?" IfPolicy Analyzer finds any groups that have thestorage.buckets.deletepermission, the query results will list not only the group identifier, but alsoall individual members in the group.

This option lets you understand individual users' access, even if that access isa result of their membership in a group.

Role expansion

If you enable role expansion, the query results list all permissions inside eachrole in addition to the role itself. This option is only available if you don'tspecify any permissions or roles in your query.

For example, imagine you enable role expansion for the query "What access doesmy-user@example.com have on the bucketbucket-1?" IfPolicy Analyzer finds any roles that givemy-user@example.com accesstobucket-1, the query results will list not only the role name, but also allpermissions included in the role.

This option lets you see exactly what permissions your principals have.

Resource expansion

If you enable resource expansion for a Policy Analyzer query, the queryresults list all relevantdescendant resources for anyparent resources (projects, folders, and organizations) in the query results.This expansion is capped at 1,000resources per parent resource for Policy Analyzer queries and100,000 resourcesper parent resource for longrunning Policy Analyzer queries.

For example, consider how resource expansion would affect the following queries:

• Who has thestorage.buckets.delete permission forproject-1?

  If you enable resource expansion for this query, the resources section of thequery results will list not only the project, but also all storage bucketsinside the project.

• Which resources doesmy-user@example.com have thecompute.instances.setIamPolicy permission on?

  If you enable resource expansion for this query and Policy Analyzerfinds thatmy-user@example.com has a project-level role that contains thatpermission, the resources section of the query results will list not only theproject, but also all Compute Engine instances inside the project.

This option lets you get a detailed understanding of the resources that yourprincipals can access.

Service account impersonation

If you are using the REST API or gcloud CLI you can enable analysisofservice account impersonation.

If this option is enabled, Policy Analyzer runs additional analysisqueries to determine who can impersonate the service accounts that have thespecified access to the specified resources. Policy Analyzer runs onequery for each service account in query results. These queries analyze who hasany of the following permissions on the service account:

• iam.serviceAccounts.actAs
• iam.serviceAccounts.getAccessToken
• iam.serviceAccounts.getOpenIdToken
• iam.serviceAccounts.implicitDelegation
• iam.serviceAccounts.signBlob
• iam.serviceAccounts.signJwt

Quotas and limits

Cloud Asset Inventory enforces the rate of incoming requests, including policyanalysis requests, based on the consumer project. Cloud Asset Inventory alsolimits group expansion within the group memberships and resource expansionwithin the resource hierarchy.

To see the default quotas and limits for Policy Analyzer, seeQuotasand limits in the Cloud Asset Inventory documentation.

Pricing

Each organization can execute up to 20analysis queries per day for no charge. This limit includes both allow policyanalysis and organization policy analysis.

If you want to execute more than 20 analysisqueries per day, you must have anorganization-level activation of the Premiumor Enterprise tier of Security Command Center. For more information, seeBilling questions.

What's next

• Learn how to use Policy Analyzer toanalyze an allowpolicy.
• See how you can use the REST API tosave Policy Analysisqueries.