Identity and Access Management (IAM)
- Sasa Pettyjohn
- Jeff Slavin (Unlicensed)
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 |
|---|---|---|
Cloud IoT Viewer | roles/cloudiot.viewer |
|
Cloud IoT Device Controller | roles/cloudiot.deviceController |
|
Cloud IoT Provisioner | roles/cloudiot.provisioner |
|
Cloud IoT Editor | roles/cloudiot.editor |
|
Cloud IoT Admin | roles/cloudiot.admin |
|
Cloud IoT Project Admin | roles/project.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"
]
}
]