Internet of Things(IoT) is today’s one of the most used technologies to establish the network between physical devices. In the case of the Cloud IoT, the cloud technology has added extra value by providing massive support to the modern IoT automation to make it more secure, managed, scalable and so forth without any doubt, this Cloud IoT is now the new definition of IoT mass-operations especially for remote access & management.
In terms of the Google Cloud IoT Core is a fully managed service that can connect securely & can easily ingest data from millions of devices around the world. This assures that you don’t need to do auto-scaling, database partitioning, pre-provisioning of resources. There are more advantages like:
- The Cloud administrator doesn’t need to determine the location of devices,
- No need for replications of IoT configuration for each area, instead the data will be published to the Cloud Pub/Sub and easily accessible from anywhere.
- The Device Manager will allow controlling & updating the system from time to time for maintaining the data security.
Google Cloud IoT Core with Identity & Access Management
Device Connecting registration to Google Cloud IoT:
Registration of Devices to connect with IoT Cloud needs to be registered in the Device Manager first. The Device Manager helps users to build and configure Device Registries. According to Google’s Cloud (GCP) Documentations, the Device Registry means “A container of devices with shared properties. You register a device with a service (like Cloud IoT Core) so that you can manage it”. You can get access to the app manager via Google Cloud Platform Console, the Google cloud shell commands, or the REST-style API.
Device Registry:
As previously mentioned, Device Registry is a container where multiple devices can be connected via Cloud IoT core or via any managing services in which we can choose the protocols such as HTTP (Hypertext Transfer Protocol) or MQTT (Message Queuing Telemetry Transport). At the time when we build a Device Registry, we can add those protocols in it as per our requirement of proceeding. The onlyEach Device Registry is usually built in a specific cloud-region & belongs to the ongoing cloud project. For example, in the Google Cloud’s cloudiot.googleapis.com service, the Registry is defined as its full name (below):
projects/{project-id}/locations/{cloud-region}/registry-id}
Therefore, the system registry can be configured by adding more Cloud Pub / Sub topics to which telemetry events for all the devices in that system registry are released. But in the case of a single topic, it may be used for data collection in all regions. For every registry, the stack driver monitoring is activated automatically.
Identity and Access Management (IAM) for Cloud IoT Core:
Now IAM is used here to monitor all the access permissions as well as allows the users to display, receive, or manage devices in full. For each project, Cloud IoT Core automatically grants the position of cloudiot.serviceAgent to the corresponding service account to allow publishing to Pub / Subtopics.
IAM can grant access at the registry level without the necessity of individual access control. The table below consists of the Google Cloud IoT Core IAM Roles and their permissions accordingly.
IAM Roles Permission Table
| IAM Roles | Descriptions | Permissions |
|---|---|---|
| roles/cloudiot.viewer | Read-only |
|
| roles/cloudiot.deviceController | Only access to update the requirements for devices in the registry but not to create or delete. |
All the above commands + the below points:
|
| roles/cloudiot.provisioner | Access to the registry to create or delete the devices from it but not for any kind of modification. |
All the above commands + the below points:
|
| roles/cloudiot.editor | Both Read and Write access to all the cloud resources, |
All the above commands + the points below:
|
| roles/cloudiot.admin | Full access & control of all Cloud IoT resources and permissions |
All the above commands + the points below:
|
Device Registry Permission Table
| Device registry permission name | Description |
|---|---|
| cloudiot.registries.create | It creates a new registry in a project. |
| cloudiot.registries.delete | It deletes a registry. |
| cloudiot.registries.get | It reads registry details, excluding ACLs. |
| cloudiot.registries.getIAMPolicy | It reads registry ACLs. |
| cloudiot.registries.list | It lists the registries in a project. |
| cloudiot.registries.setIAMPolicy | It updates registry ACLs. |
| cloudiot.registries.update | It updates registry details, excluding ACLs. |
| cloudiot.devices.sendCommand | It sends the commands (per registry, not per device). |
Device Permissions Table
| Device Permission name | Description |
|---|---|
| cloudiot.devices.create | It adds a new device to a registry. |
| cloudiot.devices.delete | It deletes a device. |
| cloudiot.devices.get | It reads device details, excluding ACLs. |
| cloudiot.devices.list | It lists devices in a registry. |
| cloudiot.devices.update | It updates device details, excluding ACLs. |
| cloudiot.devices.updateConfig | It updates the device configuration. |
| cloudiot.devices.bindGateway | It binds a device to a gateway. |
| cloudiot.devices.unbindGateway | It unbinds a device from a gateway. |
Table Data/Commands Sources: Google Cloud Documentation
Through the above permission modules, you can set up your all initial level privileges to access the storage of received IoT sensor signal’s data and then to the advanced level of remote access to manage and secure your Cloud IoT Core database from anywhere including the control over Google Big Query, BI Solutions, Google Machine Learning etc. And this is the way about how you can manage and control Google Cloud IoT Core with the help of Identity and Access Management (IAM) for any kind of security risk assessment or for disaster avoidance.
References:
