Frequently asked questions

Note: You can now use deny policies, available in Preview, to prevent principals from using some permissions. Using deny policies might cause the features described on this page to work differently.

Learn about common issues you may face while using Identity and Access Management (IAM).

About IAM

What is IAM?

IAM enables you to create and manage permissions for Google Cloud resources. It unifies access control for Google Cloud services into a single system and presents a consistent set of operations. For an overview of concepts, read IAM Overview.

Why do I need IAM?

IAM lets you adopt the security principle of least privilege, so you grant only the necessary access to your resources and prevent unwanted access to other resources. IAM allows you to meet compliance clauses around the separation of duty.

Which of the Google Cloud services support IAM?

All Google Cloud services use IAM to make sure that only authorized identities can access them. In addition, some services provide IAM roles specific to their services, or support granting access at the resource level. For more information on IAM support, see the overview.

How do I get started with using IAM?

To get started with IAM, read IAM Quickstart.

Can I use IAM policies to manage both authentication and authorization for my applications?

Use IAM to manage authorization to Google Cloud resources. To manage user authentication, use whatever methods you use to manage them today, for example, LDAP, Google groups, etc. Using IAM, you can grant access to a Google account, a service account, a Google group, a Cloud Identity domain, or a Google Workspace domain.

Roles and Policies

What is the relationship between a role and an allow policy?

Permissions determine what operations are allowed on a resource. In the IAM world, permissions are represented in the form of <service>.<resource>.<verb>, for example compute.instances.get. A role is a collection of permissions. You cannot assign a permission to the user directly; instead you grant them a role. When you grant a role to a user, you grant them all the permissions that the role contains.

IAM lets you control who (users) has what (roles) permission to which resources by setting allow policies. An allow policy on a resource is the full list of roles granted to principals on the resource.

For more information on permissions, roles, and policies, read IAM Overview.

What is the difference between basic roles and predefined roles?

Basic roles are the legacy Owner, Editor, and Viewer roles. IAM provides predefined roles, which enable more granular access than the basic roles.

Caution: Basic roles include thousands of permissions across all Google Cloud services. In production environments, do not grant basic roles unless there is no alternative. Instead, grant the most limited predefined roles or custom roles that meet your needs.

When would I use basic roles?

You can use basic roles in development and test environments, where it might be appropriate for some principals to have wide-ranging permissions. Avoid basic roles in production environments.

Can I define my own (custom) roles?

Yes, see the article on Custom Roles.

How can I find out what roles are granted on a resource?

You can find out what roles are granted on a resource by using the Google Cloud console , the getIamPolicy() method, or the Google Cloud CLI. Learn how.

What does an allow policy look like?

An allow policy is represented by a policy object that consists of a list of bindings. A binding binds a list of principals to a role. This can be represented in code as shown in this example code snippet:

{
  "bindings": [
   {
     "role": "roles/owner",
     "members": [
       "user:[e-mail]",
       "group:[e-mail]",
       "domain:google.com",
       "serviceAccount:[e-mail]"]
      },
      {
        "role": "roles/compute.networkViewer",
        "members": ["user:[e-mail]"]
      }
    ]
}

The example allow policy above grants the owner role to [e-mail], [e-mail], google.com, and [e-mail], and the Network Viewer role to [e-mail].

How can I create and manage my allow policies?

You can create and manage allow policies using the Google Cloud console, the gcloud CLI, and the IAM methods. Learn how.

How can I view my project's allow policy?

You can view the role bindings in a project's allow policy by using the Google Cloud console, the project.getIamPolicy() method, or the gcloud CLI. Learn how.

How can I view my organization's allow policy?

You can view the role bindings in an organization's policy using the Google Cloud console, the organization.getIamPolicy() method, or the gcloud CLI. For instructions, see Access control for organizations.

How do I update an allow policy?

You can update an allow policy by using the Google Cloud console, the REST API, or the gcloud CLI. Learn how.

Are there limits on how many principals I can include in an allow policy?

Yes, the number of principals in an allow policy is limited. For details, see the quotas and limits for IAM.

How do I troubleshoot my allow policies?

You can use Policy Troubleshooter to check if a principal has a certain permission on a resource.

Alternatively, you can use Policy Analyzer to better understand what principals have access to which Google Cloud resources. Policy Analyzer helps you answer questions like "Which users have this permission?" or "What permissions does this user have on this resource?"

Why do I get an error about "concurrent policy changes" when I try to update an allow policy?

To prevent concurrent changes to an allow policy from overwriting each other, each allow policy includes an etag field, which changes each time you update the allow policy. If you try to write an updated allow policy, and the etag in your request does not match the existing allow policy, you receive the following error message:

There were concurrent policy changes. Please retry the whole read-modify-write with exponential backoff.

To learn more about this issue, see Using etags in an allow policy. To learn how to implement retries with exponential backoff, see Retry failed requests.

Identities

To what identities can I grant IAM roles?

IAM enables you to grant access to the following types of identities:

• Google account
• Service account
• Google group
• Google Workspace domain
• Cloud Identity domain

Can I use Google groups with IAM?

Usually. One exception is the owner role. A group can only be assigned the owner role for a project if they are both part of the same organization. Projects without an organization cannot have groups as owners, nor can groups be assigned as owners for projects in different organizations.

Otherwise, grant roles to Google groups instead of to individual users when possible. It is easier to add members to and remove members from a Google group instead of updating multiple allow policies to add or remove users. If you need to grant multiple roles to allow a particular task, create a Google group, grant the roles to that group, and then add users or other groups to that group.

Each allow policy can contain up to 250 Google groups.

Can I use IAM to create and manage my users?

No. You can use Cloud Identity or Google Workspace to create and manage users. You can also manage your users by your current methods such as LDAP or Google Groups. If you use LDAP to manage your users, you'll need to use Google Cloud Directory Sync to synchronize the data in your Google domain. However you manage your users, you'll need to bind them, preferably using Google Groups, to a role in an allow policy to allow them to access resources.

How can I disable a user's access to IAM resources?

If you granted the user the IAM role via a Google group, you can remove the user from the group and they'll no longer have the access you granted to the group. If you didn't use a group, you'll need to review your allow policies to identify where you've granted access to the individual user, then remove them from the allow policy. Using Google groups to grant access is easier because you won't have to update all of your allow policies to revoke an individual user's access rights. Learn more.

Note: In general, it takes fewer than 2 minutes for a principal's access to be fully revoked, but sometimes it can take longer. For more information, see the FAQ entry below.

Why can a user not access resources shortly after permission is granted, or continue to access resources after permission is removed?

Changes to a principal's access are eventually consistent. This means that it takes time for access changes to propagate through the system. To learn how long it takes, on average, for access changes to propagate, see Access change propagation.

How do I grant permissions to resources in my project to someone who is not part of my organization?

Using Google groups, you can add a user outside of your organization to a group and bind that group to the role. Note that Google groups don't have login credentials, and you cannot use Google groups to establish identity to make a request to access a resource.

You can also directly add the user to the allow policy even if they are not a part of your organization. However, check with your administrator if this is compliant with your company's requirements.

How can I manage who can access my instances?

To manage who has access to your instances, use Google groups to grant roles to principals. Granting a role creates a role binding in an allow policy; you can grant the role on the project where the instances will be launched, or on individual instances. If a user (identified by their Google Account, for example, [e-mail]) is not a member of the group that is bound to a role, they will not have access to the resource where the allow policy is applied.

How can I use Multi Factor Authentication (MFA) with IAM?

When individual users use MFA, the methods they authenticate with will be honored. This means that your own identity system needs to support MFA. For Google Workspace accounts, this needs to be enabled by the user themselves. For Google Workspace-managed credentials, MFA can be enabled with Google Workspace tools.

How does a service account differ from a user who uses IAM?

A service account is a special Google account that can be used by applications to access Google services programmatically. This account belongs to your application or a virtual machine (VM), instead of to an individual end user. Your application uses the service account to call the Google API of a service, so that the users aren't directly involved.

Service Accounts

What is the maximum number of service accounts I can have in a project?

By default, you can create up to 100 service accounts in a project. If you need to create additional service accounts in a project, you can request a quota increase.

How can I rotate the service account keys when using IAM?

The Google Cloud-managed keys are rotated daily. To rotate the user-managed keys, use the IAM service account API to automatically rotate your service account keys. You can rotate a key by creating a new key, switching applications to use the new key, disabling the old key, and deleting the old key when you are sure that it is no longer needed.

How do I control who can create a service account in my project?

Owner and editor roles have permissions to create service accounts in a project. If you wish to grant a user the permission to create a service account, grant them the owner or the editor role.

Can I create a service account under an organization?

Currently you can create service accounts only under a project; you cannot create a service account directly under an organization. But if you grant IAM permissions at an organization level, the permissions will be inherited by projects under that organization, and in turn by service accounts under the projects.

I have a dedicated team that manages network and firewall rules. How can I maintain this separation of duty so that my development teams can manage instances but not make any network or firewall changes?

First, grant the Compute Network Admin role at the organization or the project level to your network administrators. Then, grant the Compute Instance Admin role to your developers. This separation of duty allows developers to carry out actions on instances while also preventing the developers from making any changes to the network resources associated with the project.

I need to ensure that the teams in my organization cannot access each other's instances. How can I do this?

Create two projects one for each team. Then create separate allow policies for each project to control which teams can access what project and the instances contained within the project. An alternative approach is to use service accounts with different roles.

Can I change the service account that I use to launch my instance?

Yes, however you cannot change the service account for a running Compute Engine instance. The instance must be temporarily stopped. After the instance is stopped, assign a new service account, and then restart the instance. For more information, see the Compute Engine documentation.

In what scenarios would I use the Service Account Actor role?

The Service Account Actor role has been deprecated. If you need to run operations as the service account, use the Service Account User role.

In what scenarios would I use the Service Account User role?

The Service Account User gives permissions to run operations as the service account. When granted together with the compute.instanceAdmin role, the iam.serviceAccountUser role gives users the ability to create and manage Compute Engine instances that use a service account. Users who are serviceAccountUsers for a service account can access all the resources for which the service account has access.

Auditing

How can I audit my allow policies?

You can use Cloud Audit Logs to regularly audit changes to your allow policies. For details about how long audit logs are retained, see Logs retention periods.

What is recorded in the audit logs?

Admin Activity audit logs contain an entry for every API call or administrative action that modifies the configuration or metadata of a service or project. Data Access audit logs contain an entry for the following events:

• API calls or administrative actions that read the configuration or metadata of a service or project.

• API calls or administrative actions that create, modify, or read user-provided data managed by a service, such as data stored in a database service.

• Project-level setIamPolicy() method is recorded.

• Service accounts and service account keys are logged.

How can I control who has access to my audit logs?

You can control access to logs using Cloud Logging roles.

How do I persist my audit logs?

Individual audit log entries are kept for a specified length of time and are then deleted. Logs retention periods control how long log entries are retained. To persist your log entries beyond the quota policy limits, route your logs from Cloud Logging to a Cloud Storage bucket or to BigQuery.