What happens if balena image tied to application gets out?

What is the security model around the provisioning key that is embedded in the Balena image I download from the cloud interface for my application?

This article seems to indicate that the “provisioning key” is good for any activations.

  1. Are their ways to limit the number of times a balena image downloaded from the cloud portal can be used?
  2. Are their ways to rotate the provisioning key in the balena image if we suspect a leak?
  3. Is there a way to remove all “Secrets” from the balena images? And use a more manual workflow to register devices?
1 Like

With regards to number 3, yes. You can do that from the CLI using a combination of balena os download and balena os configure. balena config generate might also be interesting. You can also preregister devices and skip the whole provisioning key part.

Hi, there is currently no perform the actions you describe in points 1 and 2 as a regular platform user, however, we have a few planed features that go in that direction.

In the meantime, as @ereski mentioned, it is possible to use the preloading and preregistering worflow for production devices (more info here as well).

Do you have any particular provisioning flow or use case in mind that might require that feature? We are always interested in feedback that might help us shape our planed features.

We are considering using Balena for an Intel x86-64 1U computer.

We currently use a PXE boot process to install the base os, customizations, and software.
Currently when plugged into a “special network” and powered on devices get a DHCP option which includes a TFTP Boot location which begins the installation process.

In an ideal world all “secrets” would be stored on the server serving the TFTP and PXE files to ensure that the “secrets” are not accidentally left on the device when shipped to customer premises.

I’m thinking there might be a way we can use the preloading and preregistering workflow to dynamically generate an image each time it is requested over the network whereby meeting the desire to ensure “secrets” do not end up on devices going to customers.

Hi again, thanks for the info.

For the process you describe, using a x86 image might be enough, since device register is already performed on first boot and the provisioning key is removed once registering is done.

If you still want to perform the register before the first boot, the preloading workflow using the balena CLI resource cited before should help you, as well as the Balena Node SDK

And please, let us know how does work for you. We are always interested in different provisioning workflows