Skip to main content
Skip table of contents

Identity and Access Management (IAM)


In IAM, you grant access to principals. Principals can be of the following types:

  • Users

  • Service accounts


If a principal needs access to a specific resource, you can grant the principal a role for that resource. Some examples of resources are projects and registries.

When an authenticated principal attempts to access a resource, IAM checks the resource's allow policy to determine whether the action is allowed.


Permissions determine what operations are allowed on a resource. In the IAM world, permissions are represented as service.resource.verb (e.g.,cloudiot.registries.create).

Permissions often correspond one-to-one with REST API methods. Most IoT Core services have an associated set of permissions for each REST API method they expose. The method’s caller needs those permissions to call it. For example, if you need to call the getIamPolicy method, you must have the cloudiot.registries.getIamPolicy permission.

You don't grant permissions to users directly. Instead, you identify roles with the appropriate permissions and grant them to the user.


A role is a collection of permissions. You cannot grant permissions to users directly. Instead, you grant them a role, which grants them all its permissions.

These are each role’s permissions:

Role name



Cloud IoT Viewer


  • cloudiot.registries.get

  • cloudiot.registries.list

  • cloudiot.devices.get

  • cloudiot.devices.list

Cloud IoT Device Controller


  • All permissions from Cloud IoT Viewer

  • cloudiot.devices.updateConfig

  • cloudiot.devices.sendCommand

Cloud IoT Provisioner


  • All permissions from Cloud IoT Device Controller

  • cloudiot.devices.create

  • cloudiot.devices.delete

  • cloudiot.devices.update

Cloud IoT Editor


  • All permissions from Cloud IoT Provisioner

  • cloudiot.registries.create

  • cloudiot.registries.delete

  • cloudiot.registries.update

  • cloudiot.registries.migrate

Cloud IoT Admin


  • All permissions from Cloud IoT Editor

  • cloudiot.registries.getIamPolicy

  • cloudiot.registries.setIamPolicy

  • cloudiot.projects.update

  • cloudiot.projects.delete

  • cloudiot.projects.updateUsers

  • cloudiot.projects.updateServiceAccounts

  • cloudiot.projects.listPrincipals

  • cloudiot.projects.deleteServiceAccounts

  • cloudiot.projects.createServiceAccounts

Cloud IoT Project Admin


  • All permissions from Cloud IoT Admin

You can grant roles to users by creating an allow policy, which is a collection of statements that define who has what type of access. An allow policy is attached to a resource and is used to enforce access control whenever that resource is accessed. An allow policy consists of a list of role bindings. A role binding binds a list of principals to a role.

The following code snippet shows an allow policy’s structure.

      "role": "roles/cloudiot.viewer",
      "members": [
      "role": "roles/cloudiot.editor",
      "members": [
JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.