Provisioning Access Control

Have you guys considered making it possible to restrict the provisioning of new devices?

Specifically I was thinking an IP address based restriction, or requiring a key to be available.

This is a tie in to our secure boot work where we would love to be able to restrict provisioning to the IP address of the factory, or require a key (which could be provided via USB for example).

Once provisioned of course the device key is all that is required. No changes there.


I am not aware of any ideas/plans to do this; but it’s an interesting idea. I am wondering if it’s possible for you to build a custom balenaOS image which has an encrypted config.json blob and an agent to decrypt it on startup using a remote service. This way your provisioning routing would be:

  • boot with encrypted config.txt (the same on all devices)
  • decrypt the blob, containing the real provisioning API key, and overwrite the encrypted file with the cleartext one.
  • provision as normal.

This way you could control which IPs could decrypt the blob.

Or… thinking more about it. You can actually register an device out-of-band via the balena CLI tools - then build a config.json for that device specifically and inject it in the warehouse/factory.

Also, small typo above, I meant config.json all along - config.txt is something different :grin:


Option 1. isn’t a bad idea, although it still involves exporting a key we (fleet operator) can’t change or manage. Since the device needs that key for provisioning, it has be able to decrypt it.

Also putting on my (unlikely) dedicated bad actor hat this is a potential exploitable behavior. For example if I wanted to mess with a company I’m betting firing off constant device provisioning requests (each costing the fleet operator $1+) would be very annoying to deal with.

This could possibly be extended by having resin supervisor clear the provisioning key in config.json when writing the device id and related post provisioning fields. Thoughts? Is this the only time the balena API key is used?

Option 2.

Nice idea, simpler than option 1 (basically I’d have the flasher do the provisioning). Like option 1 is this the only time the balena API key for the application used?



Yes the provisioning key that is embedded into an OS image when you download it from the dashboard is only used once to register a new device in that application. So if you change your provisioning process to have the cli register a device and inject the config.json with the appropriate device api key, that should work fine.

@afitzek thanks for that confirmation. Out of band provisioning (via the flasher) sounds like the best (and easiest) implementation.

Just finishing the second scope of works now, I’ll have a shot at this in the third probably next week.