Identity and Access Management (IAM)

Identity

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

  • Users

  • Service accounts

Resource

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

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.

Roles

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

ID

Permissions

Role name

ID

Permissions

Cloud IoT Viewer

roles/cloudiot.viewer

  • cloudiot.registries.get

  • cloudiot.registries.list

  • cloudiot.devices.get

  • cloudiot.devices.list

Cloud IoT Device Controller

roles/cloudiot.deviceController

  • All permissions from Cloud IoT Viewer

  • cloudiot.devices.updateConfig

  • cloudiot.devices.sendCommand

Cloud IoT Provisioner

roles/cloudiot.provisioner

  • All permissions from Cloud IoT Device Controller

  • cloudiot.devices.create

  • cloudiot.devices.delete

  • cloudiot.devices.update

Cloud IoT Editor

roles/cloudiot.editor

  • All permissions from Cloud IoT Provisioner

  • cloudiot.registries.create

  • cloudiot.registries.delete

  • cloudiot.registries.update

  • cloudiot.registries.migrate

Cloud IoT Admin

roles/cloudiot.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

roles/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": [ "user@example.com", "serviceAccount-12345@example.com", ] }, { "role": "roles/cloudiot.editor", "members": [ "anotherUser@example.com" ] } ]