Frequently Asked Questions

About Cloud IAM

What is Google Cloud Identity and Access Management (Cloud IAM)?

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

Why do I need Cloud IAM?

Cloud 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 Platform services support Cloud IAM?

All Cloud Platform services use Cloud 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 IAM Overview.

How do I get started with using Cloud IAM?

To get started with IAM, read IAM Quickstart.

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

Use IAM to manage authorization to Cloud platform 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, or a G Suite domain.

Roles and Policies

What is the relationship between a role and a 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 IAM policies. An IAM policy on a resource is the full list of roles granted to members on the resource.

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

What is the difference between primitive roles and predefined roles?

Primitive roles are the legacy Owner, Editor, and Viewer roles. IAM provides predefined roles, which enable more granular access than the primitive roles. Grant predefined roles to identities when possible, so you only give the least amount of access necessary to access your resources.

When would I use primitive roles?

Use primitive roles in the following scenarios:

• When the Cloud Platform service does not provide a predefined role. See the predefined roles table for a list of all available predefined roles.

• When you want to grant broader permissions for a project. This often happens when you’re granting permissions in development or test environments.

• When you need to allow a member to modify permissions for a project, you’ll want to grant them the owner role because only owners have the permission to grant access to other users for for projects.

• When you work in a small team where the team members don’t need granular permissions.

Can I define my own (custom) roles?

IAM Custom Roles are currently available as an Alpha release.

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 Cloud Platform Console, the getIamPolicy() method, or the gcloud command-line tool. For instructions see Granting, Changing, Revoking Access to Project Members.

What does an Cloud IAM policy look like?

An IAM policy is represented by a policy object that consists of a list of bindings. A Binding binds a list of members 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 policy above assigns 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 Cloud IAM policies?

You can create and manage IAM policies using the Google Cloud Platform Console, the gcloud tool, and the IAM methods. For instructions on how to do this, see Granting, Changing, Revoking Access to Project Members.

How can I find out my project’s IAM policy?

You can find out a project's IAM policy by using the Cloud Platform Console, the project.getIamPolicy() method, or the gcloud tool. For instructions see Granting, Changing, Revoking Access to Project Members.

How can I find out my organization-level policy?

You can find the organization-level policy using the Cloud Platform Console, the organization.getIamPolicy() method, or the gcloud tool. For instructions on finding out organization-level policies, see Access Control for Organizations.

How do I update a policy?

You can update a policy by using the Developer Console, the API and the gcloud tool. For instructions see Granting, Changing, Revoking Access to Project Members..

What is the size limit of a policy?

Each policy may only contain 1500 members.

How many IAM policies can I have?

Every resource that supports an IAM policy at its level (for example, organization level, project level, or resource level) can have a single policy. A single policy however, can contain any number of role bindings, and these bindings can contain any number of members.

How do I troubleshoot my policies?

You can use the testIamPermissions() method to check which of the given permissions the caller has for the given resource. This method takes a resource name and a set of permissions as parameters, and returns the subset of permissions that the caller has.

You can validate what the effect of an IAM role is. For example a user cannot access the Cloud Platform Console page for which they have not been granted access. For example, if you granted a user only the Logs Viewer role, they will see the following error message if they try to access the App Engine page:

You don't have permissions to perform the action on the selected resource.

Identities

To what identities can I grant IAM roles?

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

• Google account
• Service account
• Google group
• G Suite or Cloud Identity domain

How do I use Google groups with IAM?

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 Cloud IAM 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.

Note that group accounts are not permitted as owners on projects.

Can I use IAM to create and manage my users?

No. You can use Cloud Identity or G Suite 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, preferrably using Google Groups, to a role in an IAM policy to allow them to access resources.

How can I disable a user's access to Cloud Platform 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 policies to identify where you've granted access to the individual user, then remove them from the policy and update the policy. Using Google groups to grant access is easier because you won't have to update all of your policies to revoke an individual user's access rights. To learn more, see Granting, Changing, and Revoking Access to Project Members

How do I grant permissions to resources in my project to someone who is not a member 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 IAM policy even if they are not a part of your organization. However, check with your administrator if this is compliant with your company's policy.

How can I restrict who can access my instances?

To restrict who has access to your instances, use Google groups to bind identities to roles. This binding will be surfaced as part of a policy which is applied at the project level where the instances will be launched. If a user (identified by their google account, for example, [e-mail]) is not a member of the group that is bound in the IAM policy they will not have access to the resource where the 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 for Work accounts, this needs to be enabled by the user themselves. For Google for Work managed credentials, MFA can be enabled with Google for Work 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?

You can create 100 service accounts in a project. Contact your account manager if you need to create more than 100 service accounts in a project.

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

The GCP-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 and then deleting old key. Use the serviceAccount.keys().create() method and serviceAccount.keys().delete() method together to automate the rotation.

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?

Grant the Compute Network Admin role at the organization or the project level to your network administrators and the Compute Instance Admin role to your developers so that they can carry out any actions on instances while 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 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?

No you cannot change the service account for a running Compute Engine instance . You can only associate a Service account with an instance at creation time. You can however change the permissions granted to a service account associated with a running instance and the changes will take effect immediately.

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

Using the Service Account Actor role allows you to restrict who can access a specific instance with the same access rights as the service account that instance has been started with. An example scenario is where you have a project that has two instances each running a single service. Each service uses a different service account to access the Cloud Platform resources it requires. Each service is owned by a different developer. You can then grant to each developer the Service Account Actor role on their specific service account so they can manage their services but not other users' services.

Auditing

How can I audit my IAM Policies?

You can use Cloud audit logs to regularly audit changes to your IAM policy. Audit logs are only kept around for 30 days and users need to explicitly export logs to keep them for longer.

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 restrict access to logs using Stackdriver 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. Stackdriver Logging Quota Policy explains how long log entries are retained. To persist your log entries beyond the Quota policy limits, export your logs from Stackdriver Logging to a Google Cloud Storage bucket or to BigQuery.

Billing

Is there a cost associated with using Cloud IAM?

IAM is offered at no additional charge for all Cloud Platform customers. You will be charged only for use of other Cloud Platform services. For information about the pricing of other Cloud Platform services, see the Google Cloud Platform Pricing Calculator.