Edge device onboarding: What architects need to consider

Device onboarding is the practice of bringing a new device into your established IT and operational technology (OT) architecture. Onboarding includes configuring individual devices to be trusted and integrating them with your running systems so that you can start using them.

Architects have different considerations when designing solutions for onboarding devices for edge environments compared to devices used locally.

For example, the technical requirements for an edge onboarding architecture must include:

• Works in environments suitable for small hardware
• Works at large scale
• Tolerates network disruption or being disconnected
• Fully automated with a central point of management and observability
• Secures data at rest and in transit (even against physical threats)
• Integrates with external IT and OT systems and protocols

Scale, security, and automation are the three points that are particularly relevant for edge and Internet of Things (IoT) device onboarding.

[ You might also be interested in 5 reference architecture designs for edge computing. ]

Scaling device deployment for the edge

Think about the most common way devices are deployed in non-edge-computing architectures: You send the device to the place where it will be used, then you send (or give remote access to) a specialist who performs the installation, configures the device, and deploys the required applications on top of it.

This model is valid if you don't have a lot of devices to install. However, consider the scale of a typical edge computing solution, where you could have hundreds or thousands of devices to deploy. Sending specialized people to all locations could be slow, expensive (think about edge locations like windmills in a mountain range), and even insecure. You need new ways of deploying and performing the initial device configuration. What are the alternatives?

You can minimize costs by preparing the devices in a central place before shipping them. You could deploy and install the device, probably using images you can flash to the device and then send the preinstalled device to where it is needed.

[ Learn more about automation at the edge with seven informative industry examples in this enriched eBook. ]

If you want to take this approach, you have a couple of options. You could build specific images for each device. Or you might create an image template that can be easily customized by a nontechnical person or automatically using zero-touch provisioning. Customizations might include specific variables for the site, device purpose, and so forth.

If you don't want to end up with a sea of device images, which could be complex to manage at scale, you will probably use an image template. You must still figure out how to automate the customizations that must be made at boot time.

You could embed all the intelligence and options in the image template. Or you could build something more flexible and scalable by including the intelligence and options in a remote, centralized piece of the solution that will decide, depending on the device type, which components and configurations to apply.

An additional concern: Device security

Your solution must also take device security into account. As part of every deployment, you will probably need to include sensitive data, such as passwords, certificates, tokens, or keys. How do you plan to distribute them?

If you decide to inject those items into the images or templates, you create risk, since someone could access the image and extract that sensitive information. It's better to have the device download them at installation time using a secure channel.

This means the edge device has to download these secrets from your central server. But how will you set up that secure channel? You could use encrypted communications or a virtual private network (VPN) tunnel, but that's not enough. How can you be sure that the device is what it says it is and not a possible attacker trying to steal information or gain access to your network? You have another concern: authentication and authorization.

[ Learn how to build a flexible foundation for your organization. Download An architect's guide to multicloud infrastructure. ]

Authentication is even more important, especially for companies that use third-party providers to create the device images or add other value to the supply chain. You need to determine whether the device asking to be introduced into your network can be trusted or not, depending in part upon who provides the image.

How FDO addresses these challenges

It's expensive to send specialized people out to deploy edge devices, so you need to automate device onboarding (system deployment and first configuration) as much as possible.

You could deploy an architecture where you provision template images (to avoid having one image per system) and store the configurations in an external system. When the device boots up, it starts an automation process that finishes provisioning it, including the specific settings and software it needs to do its job.

This approach provides zero-touch provisioning that doesn't need a specialized person at the edge location, but you still need to solve sensitive information provisioning and other security concerns. You need a system that creates secure channels and downloads the secrets from an external system after being authenticated and trusted by that system.

[ A complimentary guide from Red Hat: The automation architect's handbook. ] 

This is too much to do on your own, and the market has addressed these challenges with several solutions. Yet many of these solutions are proprietary and not based on an industry standard, which could lead to vendor lock-in issues.

It's not their fault, as there wasn't a clear industry standard for device onboarding until 2020, when the FIDO Device Onboard (FDO) specification was released. FDO is an industry standard that solves the problem of trust and chain of ownership with the automation needed to onboard a device securely at scale.

In my next article, I will explain FDO, its benefits, and the main components it uses in device onboarding. Then, in an article for Enable Sysadmin, I demonstrate how to onboard devices with the FDO specification with an example implementation using Red Hat Enterprise Linux.

This article is based on Edge computing device onboarding — Part I— Introducing the challenge, which was published on Medium, and is republished with the author's permission.