Galem KAYO
on 9 October 2019
One of the key benefits of IoT is the ability to monitor and control connected devices remotely. This allows operators to interact with connected devices in a feedback loop, resulting in accelerated decisions. These interactions are mediated by a device management interface, which presents data in a user-friendly UI. The interface also serves as a client to remotely control devices in the field. Device management is, therefore, a key component of IoT solution stacks, with a significant impact on the ROI of such deployments.
However, there is no one size fits all when it comes to device management solutions. IoT solutions are deployed in various contexts. The purpose, the devices, and the users involved vary from one deployment to another, even within the same industry. It is, therefore, challenging to find a ready-made device management solution perfectly suitable to any given deployment.
Security is the critical requirement that these deployments invariably share, for it must be implemented in line with the best practices. Secure authentication and communication encryption are indispensable for the management of mission-critical device fleets.
The challenge
When it comes to IoT device management, the core challenge is the following: how to implement a solution that is both secure and perfectly suited to the intended use case? Our answer entails three main elements:
- Microservices implementing management functions
- A secured implementation of the MQTT protocol for communication
- Orchestration of the microservices with Kubernetes
Our device management solution exposes devices running Ubuntu Core over a simple UI. These devices are authenticated and communicate securely with an edge cloud hosting their digital twins. All the elements of this solution are open-source. We will elaborate on how these elements combine to deliver a comprehensive reference solution for IoT device management.
Building blocks
At the device level, our reference architecture builds on snaps, the universal application container format portable across multiple Linux distributions. Being strictly confined and transactionally upgraded, snaps offer security guarantees that are important for mission-critical applications. Ubuntu Core, the distribution of the Ubuntu open-source operating system dedicated to the internet of things, is fully built on snaps. In addition to the security benefits that Ubuntu Core brings, it runs a daemon that exposes a REST API. Devices are therefore accessible via an API; a key pre-requisite for remote management delivered out of the box with Ubuntu Core.
Hardware requirements
The multiple services that make up this solution are to be executed at the edge. Therefore, implementation requires hardware, suitable for usage conditions in fields of operations. Such hardware will need sufficient computational capabilities to perform as a worker or master node in an IoT cluster. The capabilities required will vary depending on the complexity of the intended deployment. However, computational power will have a direct effect on the CAPEX of the deployment, since it affects the number of IoT devices that can be served by a single gateway. The more devices supported by a single gateway, the lower the total investment cost.
Securing communication
Device management requires a server infrastructure to mediate communications between devices and the management interface clients. MQTT is the communication protocol implemented in our reference architecture. MQTT is an ISO standard pub-sub messaging transport protocol, which makes it adequate for constrained bandwidth.
In this implementation, a client application is installed devices as a snap. A broker service is installed on the server-side. Communications occur through an encrypted port. Messages are entirely encrypted over the wire. Furthermore, client-server authentication is carried out using certificates issued by a single authority. The private keys remain securely stored on-device, they are never communicated over the wire. This measure adds a layer of security to protect privacy and integrity of exchanged
messages.
Service orchestration at the edge
The device management solution is made of several components implemented as microservices hosted at the edge. Each service plays a key role in the overall solution. These roles are described in this section.
MQTT broker
This service implements a message broker based on the MQTT protocol. Devices connect to this service through a client. The broker receives and sends messages in channels subscribed to by devices in a publisher-subscriber pattern.
Identity service
To maintain security and integrity, access to channels hosted by the broker should only be granted to trusted devices. The identity service vets devices requesting access to these channels. This vetting is done by verification of devices public keys against a registry of pre-authorised devices. This verification is carried out upon the first connection. If successful, the service issues certificates and authentification details, which are cached into devices for subsequent requests.
Device twin
Once connected and authenticated, devices can post telemetry data to channels hosted by the broker. Telemetry data is transmitted in time-series to the broker and stored on the server. Digital ‘twins’ can thus be effectively created for each managed device.
Management UI
Graphical web interfaces are more practical to manage fleets of IoT devices. An open-source management user interface was created within the scope of the reference solution. It allows access to telemetry, remote management, as well as authentication.
Kubernetes
Kubernetes can be used to deploy the services described above at large scale, with availability levels adequate for mission-critical applications. The deployment can be carried out on edge gateways.
Conclusion
We have described how a simple and secure device management solution can be assembled from open-source components. Openness allows for customisation. A more detailed description of the implementation of each component will be provided in an upcoming Canonical whitepaper. Links to the source code of our implementation will also be shared in that whitepaper, for anyone to reuse and improve.
